Re: potential break or real break?

The theory behind this does not care what type of message is
encrypted. It applies equally to image files, plain text files,
database files, spreadsheets, readings from scientific instruments and
so forth. The theory applies to any sequence of bits.

Many image files have standard headers where only specific formats are
allowed. Decoding enough to check if you have a valid header will be
enough rather than having to decrypt the entire file.

a jpeg has a standard header, but just because the standard header decodes
correctly, that does not necessarily mean the rest of the data is decoded
successfully, one can not know until the file is fully decoded and tested.
and that there in lays my point that is it far harder to brute force an
encoded image than it is to brute force a plain text file because every
keystream must be tested. a plain text file can be monitored and the
attacker can brute force any given length of text within that file and say
hey this block is correctly brute forced because a plain text file will not
contain anything other than a-z, A-Z, 0-9 and spaces. if it does, then even
though the format may be a .txt file, the contents thereof are no longer a
plain text file.

Brute forcing an OTP will give you every possible image file in every
possible format that is the same length as the cyphertext. Borges'
Library of Babel is the thing to bear in mind here:
http://jubal.westnet.com/hyperdiscordia/library_of_babel.html

a jpeg for example, even if it is an OTP, and assuming the header is decoded
correctly, will produce an almost infinite variation of content. so will
shannons perfect secrecy theorem, and that is not an OTP. but even so, only
1 will be correct, but they are all still valid jpegs because the header was
decoded successfuly. an incorrect decoding of the header may decode into a
bitmap instead of a jpeg, but when opened an error results or a garbled
bitmap results. so while an OTP and shannons perfect secrecy theorem will
produce every possible plaintext, still only 1 will be correct but many will
be valid. since it is an image, the only way to know if it is correct is to
try every variation of every header format (and everything in between), and
every variation of data after the header. a plain text file only needs to
test for a-z, A-Z, 0-9 and spaces and has no header making it far easier to
brute force in my opinion.

For a stream cypher, and providing the image file is long enough,
trying every possible key will only produce one valid image file. Try
it if you like, pick a five byte key and try brute forcing an image
file encrypted with that short key. You will only get one single
valid decryption out of it.

again, assuming the header is decoded successfully, there is still an almost
inifinite number of variations due to the amount of variation grows
exponentially with the size of the jpeg. but still only 1 will be correct
even though they are all recognised as jpegs because of the header. i've
tested this many times. even though the header that allows a computer to
recognise a file as a jpeg decodes correctly, if the rest of the data is not
decoded correctly it will either throw up an error, or be garbled on some
level. also keep in mind that bitmaps and jpegs and various other image
formats have 'flavors'. that is, even if the header decodes as a jpeg, some
image software packages will not allow the opening viewing or editing of an
image with a particular header even though the pc recognizes both as being
jpegs. so still only 1 is correct although all are recognised as valid
jpegs.

Remember that for a stream cypher the number of possible keystreams is
equal to the number of possible keys. This is much smaller than the
number of possible keystreams available to an OTP. You have a much
smaller haystack to search with a stream cypher, and there is only one
needle in it. An OTP has a very much larger haystack with every
possible needle hidden in it and no way to tell which is the right
needle.

again, according to shannons perfect secrecy theorem, the keystream is as
long as the file, and will use every possibility available within that
length, just like an OTP, so the hay stack is the same size and still only
looking for 1 needle which is the correct keystream that will decode the
entire file to it's original state, although many states will be valid. the
difference between an OTP and a keystream defined using perfect secrecy, is
the way they are derived, one uses an algorithm, the other does not.


.