one time pad breakable debate

This is a discussion on one time pad breakable debate within the General Discussions forums, part of the Community Boards category; no not freq analysis. rolling the same char over the entire file. a roll up like you would do with ...

  1. #211
    Registered User kryptkat's Avatar
    Join Date
    Dec 2002
    Posts
    638
    no not freq analysis. rolling the same char over the entire file. a roll up like you would do with caesar . do each char then put together the ones that stand out as the char rolled with the rest to make text. brute force of a single letter at a time. by the xor logic.

  2. #212
    Anti-Poster
    Join Date
    Feb 2002
    Posts
    1,399
    Quote Originally Posted by kryptkat View Post
    the ones that stand out
    If you can provided a working definition of how to determine which pieces of data 'stand out' and are correct, then this method is valid.
    If I did your homework for you, then you might pass your class without learning how to write a program like this. Then you might graduate and get your degree without learning how to write a program like this. You might become a professional programmer without knowing how to write a program like this. Someday you might work on a project with me without knowing how to write a program like this. Then I would have to do you serious bodily harm. - Jack Klein

  3. #213
    Registered User kryptkat's Avatar
    Join Date
    Dec 2002
    Posts
    638
    i have been thinking about what you have said. i am not so sure the user or one brute forcing the one time pad file actually has to recognize 100% of everything.

    here is why.

    example. attacker has no knowledge of what the one time pad contains. brute forces file. by the same token that when you look in the temporary files folder everything has a .tmp extension. when you open one of those files after copying the entire contents to another folder with notepad you will see a few characters that specify what type of file it is 99% of the time. eighter by bmp or avi or mpeg or jpg or wpc or mz whatever. one of them is backwards i think it is swf so you might see fws. that would be part of the files header. you may not recognize any of the rest of the ascii characters as instructions or data but by seeing the header specifyier you would know exactly what type of file it is. all that is left is to change the extension and load it in to a program that uses that file format. a bit map viewer if .bmp or mpeg player if .mpg etc. with the brute force a program to run through say .bmp if had header of bmp flip through all the files and "see which one comes in to focus" or is clear image. like before it was encrypted with a one time pad. a program made to flip through each file at one .bmp per second and stop when user hits button. ideally stopping at correct image. or if a video stream or mpeg file let run to see which is played properly. with mz extension changed to .exe as executable and run on a machine not connected to anything or have anything of value on it to see what it does. again attacker just finds correct file with out recognizing 100% of contents. by just going for a header attack. may end up trying many different file types and will if any type of file format <see any rfc pertaining to file formats> had been encrypted with a one time pad. except for solely raw data <no header> i would like to remind you that most text programs or text editors such as .wpd or .doc use a file formatted data containing a header file type specifier.

  4. #214
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    22,271
    There are two reasons why your idea does not work against a one time pad:
    • Brute force is insufficient to determine the header as the portion of ciphertext corresponding to the header, like the rest of the ciphertext, depends entirely on the key.
    • Even if you know the header by some other means, brute force is insufficient to determine the contents, for the same reason. Recall that the key used for the header and the key used for the contents are different, so obtaining the key used for the header is no help. Granted, the attacker has some idea of what the contents would look like, but he/she still is unable to determine the correct contents from among all the possible contents of the same length.


    On the other hand, for ciphers that are not equivalent to a one time pad, your idea is a good one as it means that the cryptanalyst has useful information about plaintext and corresponding ciphertext.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  5. #215
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,579
    Kryptkat, but you are still confronted with the real problem of decrypting the BMP contents. You may even know a priori the cipher hides a BMP file. Let's assume that. But each byte in a one-time pad is entirely independent of the other bytes. So, you will have an infinite number of possible matches in which a BMP header will be revealed but which data blocks will show all sorts of images. From a rather intense bitmaped version of a nude Mona Lisa, to 2428 different bitmaps showing possible plans for a nuclear bomb.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  6. #216
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,825
    I can't believe this thread is still going.

    Or that kk is still spouting nonsense.

    > blah blah ... with the brute force a program to run through say .bmp if had header of bmp flip ... blah blah
    So you "brute force" "d!" into "BM" and you latch onto that it might be a BMP file.

    So how are you going to validate the next 4 bytes (the length). That's every combination from zero to 4GB. Some of those combinations will be printable characters in themselves.
    So one such permutation will be "X BI"

    Do you now revise your guessing that it is a text file beginning with "BMX BI" and then try and take a shot at the next few characters being "KES FOR SALE".

    By the same token, it may still be a very large BMP file. So how are you going to choose?


    All that blather about files in the tmp directory is irrelevant. If the attacker has your disk, there's no need to brute force a damn thing.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  7. #217
    Registered User kryptkat's Avatar
    Join Date
    Dec 2002
    Posts
    638
    but you are still confronted with the real problem of decrypting the BMP contents.
    ....

    Brute force is insufficient to determine the header as the portion of ciphertext corresponding to the header, like the rest of the ciphertext, depends entirely on the key.
    ....
    So how are you going to validate the next 4 bytes (the length). That's every combination from zero to 4GB. Some of those combinations will be printable characters in themselves.
    So one such permutation will be "X BI"

    i am saying look at the data files that the brute force program made. it tried every possible key from 0 0 0 0 0 0 0 0 ==> too end length of file too 256 256 256 256 256 256 256 256 ==> too end length of file. a file corresponding to each key. i am saying look for something that looks like a header and try a program that would use that type of file. with the few exceptions ie mz or raw data etc. find the image or video stream that comes in to focus.... plays or displays with out any data corruption. this is a weakness in the vernam encryption. <xor rand() run>

    So, you will have an infinite number of possible matches in which a BMP header will be revealed but which data blocks will show all sorts of images. From a rather intense bitmaped version of a nude Mona Lisa, to 2428 different bitmaps showing possible plans for a nuclear bomb.
    i likie the porn generator idea better. woohoo free kitty porn.

  8. #218
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    22,271
    Quote Originally Posted by kryptkat
    i am saying look for something that looks like a header and try a program that would use that type of file. with the few exceptions ie mz or raw data etc. find the image or video stream that comes in to focus.... plays or displays with out any data corruption. this is a weakness in the vernam encryption.
    You are still missing the point: you can find many images or video streams that come into focus. They all play or display perfectly well without any data corruption, and they all seem equally likely to be the plaintext. Therefore, this weakness that you speak of does not exist when a one time pad is correctly used.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  9. #219
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,579
    This is hopeless kryptkat. You aren't making any effort to understand the arguments being produced here and still have no idea what a One-Time pad is. Since you insist it is breakable, it clearly reveals you have no idea what you are talking about.

    But that would be ok, if it didn't take 15 f*** pages to teach you and you still didn't get it. Go cure your idiocy somewhere else.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  10. #220
    Guest Sebastiani's Avatar
    Join Date
    Aug 2001
    Location
    Waterloo, Texas
    Posts
    5,708
    Quote Originally Posted by kryptkat View Post
    i am saying look at the data files that the brute force program made. it tried every possible key from 0 0 0 0 0 0 0 0 ==> too end length of file too 256 256 256 256 256 256 256 256 ==> too end length of file. a file corresponding to each key. i am saying look for something that looks like a header and try a program that would use that type of file. with the few exceptions ie mz or raw data etc. find the image or video stream that comes in to focus.... plays or displays with out any data corruption. this is a weakness in the vernam encryption. <xor rand() run>
    i likie the porn generator idea better. woohoo free kitty porn.
    The "One Time Pad" scheme does have one weakness, actually - the number 11. The reason why this is so is because it corresponds closest to the number 2, and since it comes after 10 (which *is* the number 2 in base 2, btw), representing the decimal system that we use today. Decimal is used because the metric system doesn't work with other number bases. Anyway, the number 11 always has it's lowest bit set (always), and that's the key to cracking this OTP® thing. If you XOR every byte with 11 you get a value that, when XOR'ed with the original value, yields...you guessed it - 11! This suprising property can be used to reveal the Legendre symbol (I think). Even though you can't factor the OTP®, you can inspect it's symbols for "flak". These are extra bits that represent anomolies in the data. This is where the number 11 comes in to play. Hth.

  11. #221
    Registered User
    Join Date
    Oct 2008
    Posts
    1,262
    Quote Originally Posted by Sebastiani View Post
    The "One Time Pad" scheme does have one weakness, actually - the number 11. The reason why this is so is because it corresponds closest to the number 2, and since it comes after 10 (which *is* the number 2 in base 2, btw), representing the decimal system that we use today. Decimal is used because the metric system doesn't work with other number bases. Anyway, the number 11 always has it's lowest bit set (always), and that's the key to cracking this OTP® thing. If you XOR every byte with 11 you get a value that, when XOR'ed with the original value, yields...you guessed it - 11! This suprising property can be used to reveal the Legendre symbol (I think). Even though you can't factor the OTP®, you can inspect it's symbols for "flak". These are extra bits that represent anomolies in the data. This is where the number 11 comes in to play. Hth.
    You're 100% correct! Great explanation.
    (I bet you were right laserlight :P)


    Quote Originally Posted by kryptkat View Post
    i am saying look at the data files that the brute force program made. it tried every possible key from 0 0 0 0 0 0 0 0 ==> too end length of file too 256 256 256 256 256 256 256 256 ==> too end length of file. a file corresponding to each key. i am saying look for something that looks like a header and try a program that would use that type of file. with the few exceptions ie mz or raw data etc. find the image or video stream that comes in to focus.... plays or displays with out any data corruption. this is a weakness in the vernam encryption. <xor rand() run>
    Please tell me this is a joke, because otherwise you STILL don't get it.
    If you try every combination from 0 0 0 0 0 ... 0 to 255 255 255 255 ... 255 in the length of the file, then ANY FILE of the same length will be a decrypted version of that string using the proper key. That is, let's say we have an encrypted text "00 00 00", then if you get to key "79 65 73", the output is "yes". Is this correct? Maybe. But when you get to key "41 53 53", the output is "ASS". Is this correct? Who knows!
    And so on. For any three letter word there will be a key so that it decrypts to that word. And using an actual one time pad (and not MK27's algorithm :P), there is no way of which key was the right one without knowing the key.
    Last edited by EVOEx; 03-22-2010 at 10:20 AM.

  12. #222
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,579
    Sebastiani was obviously joking. There's only one person here who still doesn't understand the properties of a One-Time pad, not because it hasn't been explained to them, but because they don't make an effort trying to understand what has been told to them for the last 15 pages. Which does make them rather dense... or a troll... or both. And that person is not Sebastiani. Trust me.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  13. #223
    Registered User kryptkat's Avatar
    Join Date
    Dec 2002
    Posts
    638
    Let's make your scenario harder: not only has the user lost the key, but the user has lost the encrypted file as well. It is obvious that using your idea, the user can still recover the message, simply by brute force. In other words, it is not even necessary to have the ciphertext to retrieve the plaintext. Therefore, there is no cryptanalysis involved; you're only testing the user's ability to recognise the message when it is shown to him/her.
    if what would be done in red were done all you would end up with is key files. i would call that a standard key file. only good for a file of that length. if no xor was done there would be less likely chances of recovering the data. the question becomes "is data analysis part of cryptanalysis ?" by looking through each xored file. each one file increment by one <last byte> in the key. until the last key.

    i insist that for video or pictures and most formatted file types
    that ONE of those files from a brute force using every key will be the correct one. unless you can prove that the "porn generator" would really happen. there would be only one "focused" image or video stream. as for text that would be harder to say which one is correct. going to external intel if you have that. i do understand and believe it is a matter of trying every data file the question becomes "is data analysis part of cryptanalysis ?"
    Last edited by kryptkat; 03-22-2010 at 12:06 PM.

  14. #224
    Registered User
    Join Date
    Oct 2008
    Posts
    1,262
    Quote Originally Posted by kryptkat View Post
    if what would be done in red were done all you would end up with is key files. i would call that a standard key file. only good for a file of that length. if no xor was done there would be less likely chances of recovering the data. the question becomes "is data analysis part of cryptanalysis ?" by looking through each xored file. each one file increment by one <last byte> in the key. until the last key.

    i insist that for video or pictures and most formatted file types
    that ONE of those files from a brute force using every key will be the correct one. unless you can prove that the "porn generator" would really happen. there would be only one "focused" image or video stream. as for text that would be harder to say which one is correct. going to external intel if you have that. i do understand and believe it is a matter of trying every data file the question becomes "is data analysis part of cryptanalysis ?"
    I didn't read the entire thread, but damn, are you a troll? I think you must be. I've seen others say it but now I've seen it for myself. Otherwise, re-read my last message.
    And the part you quoted is WRONG. Where did that come from? Well, you can find out the key if you remember the plaintext EXACTLY.

  15. #225
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    22,271
    Quote Originally Posted by kryptkat
    if what would be done in red were done all you would end up with is key files. i would call that a standard key file. only good for a file of that length.
    Err... the key of a one time pad cipher is indeed only good for a file (or whatever plaintext) of that length.

    Quote Originally Posted by kryptkat
    i insist that for video or pictures and most formatted file types
    that ONE of those files from a brute force using every key will be the correct one.
    I insist, and know for sure, that for all kinds of plaintext, one of the possible plaintexts obtained by brute force will be the correct one. That as much is self-evident.

    Quote Originally Posted by kryptkat
    there would be only one "focused" image or video stream.
    But this is wrong. There will be many "focused" images or video streams, all of which are equally likely to be the correct one.

    Quote Originally Posted by kryptkat
    i do understand and believe it is a matter of trying every data file the question becomes "is data analysis part of cryptanalysis ?"
    There is no data to analyse since all that you are doing is pure guesswork, not intelligent guesswork, because there is no information about the plaintext to be obtained from the ciphertext, other than perhaps the length of the plaintext.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 26
    Last Post: 07-05-2010, 11:43 AM
  2. Replies: 11
    Last Post: 03-29-2009, 01:27 PM
  3. calculating user time and time elapsed
    By Neildadon in forum C++ Programming
    Replies: 0
    Last Post: 02-10-2003, 06:00 PM
  4. relating date....
    By Prakash in forum C Programming
    Replies: 3
    Last Post: 09-19-2001, 10:08 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21