Slashdot Mirror


Debunking a Bogus Encryption Statement?

deviantphil asks: "Recently, a coworker tried to assert that encrypting a file twice with a 64 bit algorithm is equivalent to encrypting it once with a 128 bit algorithm. I know enough about encryption to know that isn't true, but I am having difficulties explaining why and how. Doesn't each pass of the encryption create a separate file header which makes this assertion untrue? Can anyone point me to references that would better help me explain this?" What other laughable claims have you heard attributed to encryption, and how were you able to properly lay them to rest?

8 of 215 comments (clear)

  1. Meet in the middle attack by dtfinch · · Score: 5, Informative

    http://en.wikipedia.org/wiki/Meet-in-the-middle_at tack

    That's why we have triple-DES instead of double-DES.

  2. Your keyspace wouldn't be that much bigger by Profane+MuthaFucka · · Score: 5, Insightful

    Seems like encrypting twice with a 64-bit key just means that instead of breaking a 64-bit key once, you have to do it twice. That's like using a 65-bit key, instead of a 64-bit key. Every bit doubles your keyspace.

    Plus, you have to realize that the amount of time needed to brute force a single key of a certain size goes up non-linearly with each additional bit. If you just double the number of times you encrypt, you're pretty much just increasing the effort to brute force the thing linearly.

    --
    Fascism trolls keeping me up every night. When I starts a preachin', he HITS ME WITH HIS REICH!
    1. Re:Your keyspace wouldn't be that much bigger by sr180 · · Score: 5, Funny

      Think of it as this: If you encrypt something as rot-13 twice, does it become any more secure?

      --
      In Soviet Russia the insensitive clod is YOU!
    2. Re:Your keyspace wouldn't be that much bigger by Kadin2048 · · Score: 5, Insightful

      I think a big part of that comes down to the file headers and how you actually implement the cryptographic algorithms into a system.

      If you take a plaintext file and encrypt it into a file which has headers ("BEGIN ENCRYPTED CONTENT---"), and then encrypt the result again, assuming the attacker knows how you did it and that the intermediate file has plaintext headers, then they'll know the moment they broke the first 64-bit encryption layer. So in this example, you're basically at 65 bits.

      Now if you don't include any headers, so that there's no terribly good way to determine whether you've gotten the right key or not, as you're brute-forcing the first layer, then I think you're right -- the strength of the overall system is somewhere in a grey area between 65 and 128 bits.

      If someone was just thinking that they could use a file-encryption utility twice (which produces output files that have plaintext headers) and double the keyspace, they are dead wrong.

      --
      "Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
    3. Re:Your keyspace wouldn't be that much bigger by swillden · · Score: 5, Informative

      Wouldn't you have to do the "inner" 64bit bruteforce procedure for each possible key of the "outer" 64bit keyspace, thus making it 128bit again?

      No, you do a meet-in-the-middle attack, which is basically 2^64 in complexity if you're using two 2^64 keys.

      There are some optimizations that can be done, but the basic idea is this: You start with one ciphertext block and its corresponding known plaintext. Then you encrypt the plaintext with all 2^64 possible keys and store the results (with some indexes to make it easy to search for a particular block). Then you decrypt the ciphertext with all 2^64 possible keys, looking each result up. When you find a match, you have found the pair of 64-bit keys that turns that plaintext into that ciphertext. So to search the entire space, you have to do 2^64+2^64 = 2^65 trial operations. On average, you only have to search half of the second keyspace, so the complexity of the search is 2^64+2^63 = 2^64 (plus the huge storage cost).

      Triple encryption is also weakened by a meet-in-the-middle attack. Using three 64-bit keys, it would be nice to think you have a 192-bit key. But a meet-in-the-middle requires encrypting with all 64-bit keys for the first step, and decryption with all 128-bit keys for the second step, giving an effective strenth of 2^64+2^127 = 2^127 (plus the huge storage cost).

      Finally, keep in mind that DES keys aren't 64 bits. They're 56 bits. So 3DES has a brute force search computational complexity of 111 bits, on average.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
  3. Think about it as number of possibilities by Phantombrain · · Score: 5, Informative

    I'm going to think of it as if you were trying to bruteforce it.
    If you have 64 bits, that is 1.84467441 × 10^19 (2^64), meaning maximum that many tries to break the first layer of encryption. The second layer is the same number, meaning to break it would mean a maximum of 3.68934881 × 10^19 attempts.
    With 128 bit encryption, there are 3.40282367 × 10^38 (2^128) different possibilities, MUCh more than the double 64 bit encryption.

    Obviously people don't usually bruteforce encrypted files, but you can see there are much more possiblities for 128 bit encryption than with double 64 bit.

    --
    echo YOUR_OPINION > /dev/null
  4. Bad math by Dan+East · · Score: 5, Funny

    Your both wrong. Encrypting twice at 64 bit is like 64*64=4096 bit encryption. Personally, I like to encrypt 7 times at 2 bit encryption for 128 bit strength. If its something I really want to keep secret, I encrypt four times at 128 bit for 268435456 bit encryption. However, don't make the mistake I made once of encrypting 128 times at 1 bit. Because that is just 1^128, which yields nothing more than 1 bit encryption.

    In case anyone is wondering, I'm hoping some DRM coder will gain valuable insight from this post.

    Dan East

    --
    Better known as 318230.
  5. Get a book on cryptography by cunkel · · Score: 5, Informative
    Well, one common way to dispel a myth is to find an authoritative source on the subject that explains why the myth is untrue. Perhaps a book on cryptography would be helpful, for example:
    • Applied Cryptography: Protocols, Algorithms, and Source Code in C by Bruce Schneier
    • Handbook of Applied Cryptography by Alfred J. Menezes et al.
    Either one will explain such things as why double-DES is not twice as strong as DES and common pitfalls in thought and design of cryptographic systems.