From: solman@MIT.EDU
Date: Thu, 14 Jul 94 23:45:54 PDT
To: perry@imsi.com
Subject: Re: Why triple encryption instead of split+encrypt?
In-Reply-To: <9407141343.AA17589@snark.imsi.com>
Message-ID: <9407150645.AA13763@ua.MIT.EDU>
MIME-Version: 1.0
Content-Type: text/plain


> 
> solman@mit.edu says:
> > Why do people do triple DES and *shudder* triple IDEA
> > instead of doing some form of non-redundant secret splitting
> > and then encrypting with multiple keys.
> 
> Because people like algorithms that work quickly and don't expand
> their data by a factor of two or three. As I've noted before, in spite
> of protestations, the evidence is good that splitting and encryption
> doesn't by you much over simple superencipherment.

Although I mentioned "true" secret splitting at the end of my post, I was
refering to non-redundant secret splitting in most of the post. That is,
for each 128 bit block, you split it into two 64 bit blocks. Obviously you
have to make sure that in the inverse of the split, each bit of the 128 is
dependent on multiple bits in both 64 bit parts.

This is obviously not as secure as traditional secret splitting, but you
don't need it to be because this isn't a threshold scheme. You just need
to guarantee that knowing one half does not allow you to reassemble the
other half. I am claiming that you can allow the crypt analyst to remove
half of the entropy from the plaintext (did I phrase that right? probably
not :( ) and the other half will still require successful cryptanalysis
of DES and since you can't tell if you're right until you get both halves,
meet in the middle does not work.

So, is a secret splitting algorithm that does NOT increase redundancy
followed by DES with different keys on both halves as secure as triple
DES? I believe so, but I would like your opinions on the issue before
I consider implementing this. If it works it would be especially nice
because it allows arbitrary extension of keysize without substantially
increasing the time required for computation.

I have a hunch that if I'm wrong, its because the time required to do secure
non-redundant secret splitting is as large as the time I'm saving.

JWS