Any customers asking for double encryption?

Comments

# Scott said on November 9, 2004 04:23 PM:

Isn't this essentially what TripleDES is? DES Encryption performed three times with three separate keys?

# Or-n said on November 9, 2004 04:46 PM:

I assume you are talking about symetric algorithms here as you are talking about a single key.

Ciphertext encrypted with the same block cipher algorithm using two different keys takes the same amount of time to crack as ciphertext encrypted with one key.

The operation simply results in a third key equally valid as using key two and then one to decrypt, therefore only the resultant key three has to be found and key one and two never have to be broken.

I would suggest just using a larger key size and (current) secure algorithms such as AES and Triple DES instead of playing around with multiple encryptions.

If your client absolutely insists on encrypting more than once, let him know that you will have to use multiple chiper schemes and the resultant output will be much larger, take much longer to generate, and be much harder to manage without significantly increasing security. He'll come around

# Or-n said on November 9, 2004 04:53 PM:

Yes, but the most common mode of TripleDes accepts the three keys as one large key and then does EDE (Encrypt Decrypt Encrypt) rather than three encypts. Much simpler and, for now, secure.

# kevin said on November 9, 2004 07:06 PM:

Also key size is not a completely accurate indicator of security. A longer key does not immediately mean more secure. The encryption method and the security of the key are far more important.

# DKappey said on November 10, 2004 12:13 PM:

Hello, I'm the customer who asked for the double encryption.
We are not looking for a stronger encryption: we simply need two different keys in order to avoid that who have only one key wont decrypt the data.

# Or-n said on November 10, 2004 02:52 PM:

Then what you are looking for is called an m of n solution (m members of a group size n are needed to decrypt the info).

The easiest method to accomplish this for just two parties is to halve the key, then use a trusted arbitrator (usually a computer) to bring them back together when both parties are present.

However, if you are using a system such as triple-des, each party now has one and a half keys out of the three and therefore breaking the chiper-text if some plain text is known will be fairly trivial.


A more secure method would be to give each party a full key, the first party performs encryption on the plaintext data, then the second party takes a random sequence of numbers equivilant to the length of the chipertext and xor's it with said chipertext, then encrypts the random sequence with the key and stores it.

Now the second party can remove the xor'ed value but can not decrypt the chipertext and the first party can decrypt the chipertext but can not access it without the second party first removing the xor-ing.

Just remember that the amount of data you need to store now is chipertext*2, and you need a trusted arbitrator to recieve the plaintext and both parties keys to perform the initial encryption and generate the pseudo-random sequence.

The method you choose all depends on how sensitive the data is and how long you need to that data to remain secure. i.e. it doesn't make sense to encrypt a public announcement that will go out next week with an encryption that will take 10 years to break, the same as it doesn't make sense to encrypt a credit card number that will expire in two years with an encryption that will take one week to break....

hope this was helpfull....

# Duane Laflotte said on November 11, 2004 11:43 AM:

Hi All,
This is a great topic and one we get a lot. We have had clients who need to secure data and want encryption. We usually explain a bit about encryption to give them the feel for how much is really needed to decrypt data. For Example. I'm assuming you are going to use a symmetric algorithm (due to the fact that you only discuss one key). Assuming you are going to use a block encryption algorithm as well you have a few options:

* DES- Use by financial institutions to hold volatile data. DES is used for anything that needs to be secure in a measure of hours not days. This algorithm uses a 56 bit key. [Downside= Crackable in 3.5 hours with special hardware. If you were to try 90 billion keys a second it would take 56 hours to crack.]

* 3DES (Triple DES) - This can use up to 3 keys (sometimes 2 but we wont talk about that). The first key is used to encrypt the data using the normal DES algorithm. The second key then decrypts the encrypted data, essentially decrypting it to mush as your are attempting to decrypt with the non-encrypting key. Then the third key re-encrypts the data output from the second keys decryption. [Downside = takes 3 times as long as DES but is almost impossible to brute force crack]

* RC2 - Invented in 1987 by Ron Rivest (the R in RSA) RC2 can use a key of 1-128 bits. One thing to note RC2 is actually twice as fast as DES. [Downside = RC2 can be easy to crack if your key is not of sufficient length]

* Rijndael (or AES) - This is preferred by the DOD for its security. It will work with key sizes of up to 256 bites. But you can also alter the block sizes that are used during the encryption as well to 128, 192, or 256 bits. Due to the flexibility of this algorithm it has no known vulnerabilities.

In summary. One of the problems with DES and 3DES is its non-flexibility in the key size as well as the block size it will cipher. RC2 and Rijndael are much more secure in the fact that it adds a certain entropy to the mix.

So to answer the question of double encryption. If don’t properly (like 3DES) it can add cryptographic security but there is no guarantee that if you use two different algorithms they will not cancel each other in some way. I personally wouldn’t recommend encrypting data twice with different algorithms as there are great algorithms out there that are currently "uncrackable".

Hope this helps!

p.s. I will probably post a bit more around this topic to my blog today as well as this really is a good question.

Duane Laflotte
blog = http://www.criticalsites.com/dlaflotte

# Michael Brundage said on November 13, 2004 11:26 PM:

Your coworker's right - it depends on the encryption routines and a lot of mathematical analysis.

Unless the encryption algorithm is already flawed, using a key that's twice as big is almost always stronger than applying encryption twice with two keys of the same length. The reason is that the strength of the cipher is usually exponential in the size of the key. So doubling the key actually squares the complexity, while appying the encryption twice at best doubles the complexity.

There are encryptions for which repeated application weakens the encryption. Probably the best example of this is ROT13 :-) There are other cases where repeated encryption makes it stronger. It really depends on the particular algorithms used.

Encryption is closely related to pseudo-random number generation; if you wanted to, you could read about, for example, the fast shift register generator R250. R250 has some statistical flaws, but combining it with R521 makes it better. The specific numbers chosen here are significant -- just picking something ad hoc would not produce the desired results.

# floriran said on November 21, 2004 09:37 AM:

http://2005sonnerie.magikmobile.com,
http://2006sonneries.magikmobile.com,
http://2007sonneries.magikmobile.com ,
http://20.magikmobile.com ,
http://2oo5.magikmobile.com ,
http://sonneries-sonnerie-portable-portables.magikmobile.com,
http://magicmobile.magikmobile.com,
http://magikmobil.magikmobile.com,
http://p.magikmobile.com,
http://sonnerieslogo.magikmobile.com,
http://sonneriesportable.magikmobile.com,
http://sonneriesportables.magikmobile.com ,
http://telephones.magikmobile.com ,
http://sonneriestelephoneportable.magikmobile.com ,
http://101sonneries.magikmobile.com,
http://www.sonneries-sonnerie-portable.com

# TrackBack said on November 24, 2004 02:32 PM:

Leave a Comment

Title (required) 

Name (required) 

Your URL (optional)

Comments (required) 

Remember Me?