Re: Is encrypting twice much more secure?

On Jan 12, 4:24 pm, Sebastian Garth <sebastianga...@xxxxxxxxx> wrote:
On Jan 12, 11:06 am, Michael B Allen <iop...@xxxxxxxxx> 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?


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
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