Is encrypting twice much more secure?
in [Cryptography]
|
Prev: A published list of rare tetragraphs?
Next: A discrepancy in literatures on permutation polynomials
From: Michael B Allen on 12 Jan 2010 17:10 On Jan 12, 4:24 pm, Sebastian Garth <sebastianga...(a)gmail.com> wrote: > On Jan 12, 11:06 am, Michael B Allen <iop...(a)gmail.com> wrote: > > > I need to encrypt some data and give the password to an escrow > > attorney so that only under certain conditions (e.g. dirt nap) a list > > of beneficiaries will have the ability to recover this data. But I am > > going to make the encrypted package publicly available along with the > > source code of the decryption program. So I need the encryption method > > used to be particularly good. > > > My first thought is to simply encrypt the data multiple times using > > different algorithms and key sizes (e.g. AES128 -> RC4 -> AES256) > > using different segments of a randomly generated 32 character > > alphanumeric password. The rational is that if / when an algorithm is > > broken, the enclosed encrypted layer would look random and thus not > > give the attacker any feedback as to their success. They would have to > > successfully crack all layers simultaneously. Is this reasoning valid? > > > Mike > > Short answer: probably...but it would likely be overkill. Running the > data through, say, a 4096-bit RSA would be more than sufficient. If in > doubt, though, just increase the key length. Hi Sebastian, It is highly desirable that the decryption process be very simple as it will be exercised occasionally by legal types who may have limited technical savvy. In particular I want to: 1. Use an alphanumeric password that can be easily communicated using a trivial methods such as in a document or email or perhaps even verbally. Using a certificate is troubling. 2. The decryption program needs to highly portable . So I need to use whatever crypto is available on a Microsoft Windows machine which probably amounts to RC4, AES128, AES192, AES256, SHA1 and MD5 (I don't think XP has "BICOM" and I have no idea what that is anyway). So combined with Maaartin's recommendation not to derive keys from the same master key, I'm thinking of something like the following encryption procedure: 1. Generate random 64 character alphanumeric password P. 2. Use P[0-15] to generate 16 byte hash H1 3. Encrypt plaintext using AES128 initialized with H1 to yield encrypted data E1 4. Use P[16-31] to generate 16 byte hash H2 5. Encrypt E1 using RC4 initialized with H2 to yield encrypted data E2 6. Use P[32-63] to generate 32 byte hash H3 7. Encrypt E2 using AES256 initialized with H3 to yield encrypted data E3 So no part of the password is reused and I'm using 2 different algorithms with 3 different key sizes. If this is in fact overkill, that is fine. Writing a program to encrypt something 3 times is only fractionally more difficult than encrypting it once. My only concern would be if the cyphertext at each step will look completely random. Meaning if someone successfully decrypted the AES256 outer layer, could they know that it was successful or would an invalid decryption product look as equally random as the correct RC4 cyphertext? Mike
From: Andrew Poelstra on 12 Jan 2010 17:17 On 2010-01-12, Michael B Allen <ioplex(a)gmail.com> wrote: > Hi Sebastian, > > It is highly desirable that the decryption process be very simple as > it will be exercised occasionally by legal types who may have limited > technical savvy. In particular I want to: > > 1. Use an alphanumeric password that can be easily communicated > using a trivial methods such as in a document or email or perhaps even > verbally. Using a certificate is troubling. > > 2. The decryption program needs to highly portable . So I need to > use whatever crypto is available on a Microsoft Windows machine which > probably amounts to RC4, AES128, AES192, AES256, SHA1 and MD5 (I don't > think XP has "BICOM" and I have no idea what that is anyway). > > So combined with Maaartin's recommendation not to derive keys from the > same master key, I'm thinking of something like the following > encryption procedure: > > 1. Generate random 64 character alphanumeric password P. > 2. Use P[0-15] to generate 16 byte hash H1 > 3. Encrypt plaintext using AES128 initialized with H1 to yield > encrypted data E1 > 4. Use P[16-31] to generate 16 byte hash H2 > 5. Encrypt E1 using RC4 initialized with H2 to yield encrypted data > E2 > 6. Use P[32-63] to generate 32 byte hash H3 > 7. Encrypt E2 using AES256 initialized with H3 to yield encrypted > data E3 > > So no part of the password is reused and I'm using 2 different > algorithms with 3 different key sizes. If this is in fact overkill, > that is fine. Writing a program to encrypt something 3 times is only > fractionally more difficult than encrypting it once. > > My only concern would be if the cyphertext at each step will look > completely random. Meaning if someone successfully decrypted the > AES256 outer layer, could they know that it was successful or would an > invalid decryption product look as equally random as the correct RC4 > cyphertext? > > Mike Who/how/why would somebody attempt to break your encryption? If the data is physically safe, it would be okay to use TrueCrypt or some other prebuilt application?
From: Maaartin on 12 Jan 2010 18:02 On Jan 12, 11:10 pm, Michael B Allen <iop...(a)gmail.com> wrote: > On Jan 12, 4:24 pm, Sebastian Garth <sebastianga...(a)gmail.com> wrote: > So combined with Maaartin's recommendation not to derive keys from the > same master key, I'm thinking of something like the following > encryption procedure: I *was* recomending to derive keys from one master key, but *not* using different segments of a password. Instead you should do something like key1 = secure_hash("1", masterPassword) key2 = secure_hash("2", masterPassword) plus some password strengthening. Of course, you don't need it in case of randomly generated password which is long enough. But such a password is hard to remember. > 1. Generate random 64 character alphanumeric password P. > 2. Use P[0-15] to generate 16 byte hash H1 Wrong, 16 alphanumeric characters have less entropy than 16 bytes, so you make it a weaker than possible. You'd need 22 characters for it. > 3. Encrypt plaintext using AES128 initialized with H1 to yield > encrypted data E1 > 4. Use P[16-31] to generate 16 byte hash H2 > 5. Encrypt E1 using RC4 initialized with H2 to yield encrypted data > E2 > 6. Use P[32-63] to generate 32 byte hash H3 > 7. Encrypt E2 using AES256 initialized with H3 to yield encrypted > data E3 > > So no part of the password is reused and I'm using 2 different > algorithms with 3 different key sizes. If this is in fact overkill, > that is fine. Writing a program to encrypt something 3 times is only > fractionally more difficult than encrypting it once. > > My only concern would be if the cyphertext at each step will look > completely random. Meaning if someone successfully decrypted the > AES256 outer layer, could they know that it was successful or would an > invalid decryption product look as equally random as the correct RC4 > cyphertext? All ciphertexts produced by any cipher worth its name look very random, for RC4 there some known biases in the order of 2**-24, see http://groups.google.com/group/sci.crypt/browse_thread/thread/d9b391d50ba06c5f The greatest risk is probably something else, e.g., leaking of password by some social engineering or some mistake you make. I'd go for some existing application.
From: Paul Rubin on 12 Jan 2010 18:16 Michael B Allen <ioplex(a)gmail.com> writes: > I need to encrypt some data and give the password to an escrow > attorney so that only under certain conditions (e.g. dirt nap) a list > of beneficiaries will have the ability to recover this data. But I am > going to make the encrypted package publicly available along with the > source code of the decryption program. So I need the encryption method > used to be particularly good. This whole scheme sounds kind of silly. Why do you want to publish the ciphertext? Why not give the attorney all the data and not just the key? If you want to make authenticity verifiable, just sign the data with a private key and publish the corresponding public key.
From: unruh on 12 Jan 2010 18:19
On 2010-01-12, Michael B Allen <ioplex(a)gmail.com> wrote: > I need to encrypt some data and give the password to an escrow > attorney so that only under certain conditions (e.g. dirt nap) a list > of beneficiaries will have the ability to recover this data. But I am > going to make the encrypted package publicly available along with the > source code of the decryption program. So I need the encryption method > used to be particularly good. > > My first thought is to simply encrypt the data multiple times using > different algorithms and key sizes (e.g. AES128 -> RC4 -> AES256) > using different segments of a randomly generated 32 character > alphanumeric password. The rational is that if / when an algorithm is > broken, the enclosed encrypted layer would look random and thus not > give the attacker any feedback as to their success. They would have to > successfully crack all layers simultaneously. Is this reasoning valid? You are going nuts. a) Your first layer is by far the weakest. That attourney could be bribed to give up the keys. All other layers are then open. That is by far, by far the easiest to break your system. b) How much is the content worth. If less than $1000000 then nooone is going to spend the time and effort trying to break one layer. Just use AES once. c) your reasoning is relatively valid, but also irrelevant (see a) > > Mike |