Re: Is encrypting twice much more secure?



On 2010-01-13, Michael B Allen <ioplex@xxxxxxxxx> wrote:
On Jan 12, 6:25?pm, unruh <un...@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
On 2010-01-12, Michael B Allen <iop...@xxxxxxxxx> wrote:
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.

Those are your weak points. Not the encryption technique.

Here's what I'm really doing: I am going to encrypt the source code of
a commercial software library. Companies using the library in their
commercial products need to be able to retrieve the source code for it
if I'm hit by a bus, if the library is discontinued, etc so that they
can continue to maintain this part of the functionality of their
products.

So rather than use an code escrow service that has all sorts of
constraints that I would have to figure out and conform to, I will
just give the source code packages of library to these particular
customers but in encrypted form. Then all they need is the password
(actually it will be a list of passwords) to recover the source. An
attorney will simply hold the escrow agreement, the list of passwords
and the list of beneficiaries. Periodically customers can pay the
attorney to update the beneficiaries list with their info and test the
decryption procedure which should amount to clicking on a VBScript and
pasting in the correct password.

So if the escrow agent leaks the password that would be a drag but
it's not a big deal. But if AES256 is miraculously cracked next month,
I don't want to make it easy for people with the encrypted packages to
recover the source.

?? But if the agent leaks the password, they have the source. That is
like the encryption being cracked ( an dfar far more probable).
You security concerns are completely ass backwards.


I hear you - 1 pass of AES is enough. But it's trivial to do 3 passes
so why not? The only reason not to would be if it somehow made it
*less* secure. That is what I'm asking and I think the question has
been answered well (although I have to go back and understand
Maaartin's master password bit). Thanks sci.crypt.

It does make it less secure. It makes it more complex and means that the
probablility of problems, so that when you die noone can decrypt anyway,
is far far higher.


? 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

The hashes add no strength whatsoever.

Actually I know a little bit about cryptography. It is standard
practice to use a hash so that the keyblock is the right size. And the
Windows CryptoAPI functions work with hashes. But you know this so I
suspect you're just one of those people who like to get into long
meaningless arguments on Internet forums?

Although it is interesting to hear hashing the password provides "no
strength whatsoever". I would think a much more random key might do
something.

Yes, but hashing does NOT give a much more random key. the key is simply
the original key. That there is a more random looking thing between your
entry of the key and the AES is really irrelevant. You must assume that
the hash function is known, and thus the real key is the original key.


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

Why not do it 1948 times instead of just three times?

You're going to have to come up with something much more pedantic and
clever if you're ever going to look cool on this group.

I am not trying to look cool. I am trying to figure out what you are
trying to do, and to point out that your logic has severe problems.



Mike
.



Relevant Pages

  • Re: Is encrypting twice much more secure?
    ... of beneficiaries will have the ability to recover this data. ... source code of the decryption program. ... like the encryption being cracked. ...
    (sci.crypt)
  • Re: Is encrypting twice much more secure?
    ... of beneficiaries will have the ability to recover this data. ... source code of the decryption program. ... Not the encryption technique. ...
    (sci.crypt)
  • Re: Encrypted software backups?
    ... The more you spread it around, ... I'd encrypt the source code before distributing copies of it to ... Although good encryption would minimize the ... copies among friends and relatives. ...
    (sci.crypt)
  • US crypto export regs (was Re: Use of Debian For Non-Profits)
    ... We're trying to find a version of Linux that we could ... > current encryption. ... is subject to an express agreement for the payment of a license fee ... from the compiling of such source code is also eligible for License ...
    (Debian-User)
  • Re: U.S. export laws on SSH/SSL?
    ... >]> Notifying the BXA that you provide encryption source code can be done ... these loose regulations only apply to freely available source ... regular basis to restrict encryption even further, ...
    (comp.os.linux.security)