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?

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
.



Relevant Pages

  • Re: Is encrypting twice much more secure?
    ... give the attacker any feedback as to their success. ... It is highly desirable that the decryption process be very simple as ... Use an alphanumeric password that can be easily communicated ... Not the encryption technique. ...
    (sci.crypt)
  • Re: Is encrypting twice much more secure?
    ... Use an alphanumeric password that can be easily communicated ... The decryption program needs to highly portable. ... My only concern would be if the cyphertext at each step will look ... Who/how/why would somebody attempt to break your encryption? ...
    (sci.crypt)
  • Re: Auto-update protocol
    ... to transfer even with a single client and no interference. ... shared secret/public key is the only way to do the encryption. ... successfully decryption is the authentication. ... you can get using a generic farm server, but TFTP does not have any ...
    (comp.arch.embedded)
  • Re: Securing data to a process principal
    ... encryption key first time for the user - and use it later). ... secret. ... I need the decryption to ... You MAY think that instead of a filter driver you can simply ...
    (microsoft.public.platformsdk.security)
  • Re: embedded keys - there has to be a less vulnerable approach
    ... the database would be run on top of an encrypting file system ... > The use of an asymmetrical encryption algorithm does not seem to offer ... because the encryption and decryption ... > a hostile attacker is not a member of that small knowledgeable elite. ...
    (comp.security.misc)