Re: Triple encryption...

Carl Ellison (cme@tis.com) wrote:

> have you considered
>
>        des | tran | des | tran | des ?

That one's sort of your "trademark", isn't it? <g>  (TRAN is really
clever, BTW.)  One scheme that seems to make even more sense, though, is:

         des | tran | IDEA | tran | des

You get the benefits of 112 bits worth of DES keyspace along with 128 bits
of IDEA keyspace, and thus don't stake your total security on the strength
of EITHER algorithm.  Other than making the code bulkier by requiring the
inclusion of code for TWO crypto algorithms, and 64 bits of extra key
material, what other drawbacks would there be to such a scheme (in a
NON-commercial setting where licensing of the patented IDEA is not an
issue)?  If IDEA turns out to not be as secure as we've been led to believe,
at least it, sandwiched between two layers of TRAN shuffling, should at least
slow down a meet-in-the-middle attack on the remaining two layers of DES.

As I recall, last time we discussed this over on sci.crypt you also
advocated an additional step of "PRNGXOR".  Is that still the case?  Have
you had the opportunity to read the Eurocrypt '94 paper by Eli Biham on
triple DES modes, yet?

 /--------------+------------------------------------\
 |              |  Internet: davesparks@delphi.com   |
 | Dave Sparks  |  Fidonet:  Dave Sparks @ 1:207/212 |
 |              |  BBS:      (909) 353-9821 - 14.4K  |
 \--------------+------------------------------------/

>Date: Fri, 15 Jul 1994 01:14:52 -0400 (EDT)
>From: DAVESPARKS@delphi.com
>Subject: Re: Triple encryption...

>Carl Ellison (cme@tis.com) wrote:
>
>> have you considered
>>
>>        des | tran | des | tran | des ?
>
>That one's sort of your "trademark", isn't it? <g> 

yup :-)

>clever, BTW.)  One scheme that seems to make even more sense, though, is:
>
>         des | tran | IDEA | tran | des
>
>You get the benefits of 112 bits worth of DES keyspace along with 128 bits
>of IDEA keyspace, and thus don't stake your total security on the strength
>of EITHER algorithm.

good, too.  Of course, it leaves open the question of which should be
inside and which outside.

I'd be most concerned about any ciphertext-only attack which is improved by
having purely random bits as input.  Whichever algorithm is more resistant
to such an attack should be on the outside.  (No, I'm not aware of such an
attack, yet....)


>As I recall, last time we discussed this over on sci.crypt you also
>advocated an additional step of "PRNGXOR".  Is that still the case?  Have
>you had the opportunity to read the Eurocrypt '94 paper by Eli Biham on
>triple DES modes, yet?

Yes, it's in response to Eli's paper that I advocated prngxor, as in:


         des | prngxor | tran | des | tran | des

with the DES instances in ECB mode (in acknowledgement of Eli's attack).
The prngxor destroys any patterns from the input, which was the purpose of
CBC, without using the feedback path which Eli exploited.

	 - Carl

p.s.  tran.shar is available at ftp.std.com:/pub/cme

> ...
> >> have you considered
> >>
> >>        des | tran | des | tran | des ?
> >
> >That one's sort of your "trademark", isn't it? <g> 
> 
> yup :-)
> 
> >clever, BTW.)  One scheme that seems to make even more sense, though, is:
> >
> >         des | tran | IDEA | tran | des
> >
> >You get the benefits of 112 bits worth of DES keyspace along with 128 bits
> >of IDEA keyspace, and thus don't stake your total security on the strength
> >of EITHER algorithm.
> 
> good, too.  Of course, it leaves open the question of which should be
> inside and which outside.
> ... 
> Yes, it's in response to Eli's paper that I advocated prngxor, as in:
> 
> 
>          des | prngxor | tran | des | tran | des
> 
> with the DES instances in ECB mode (in acknowledgement of Eli's attack).
> The prngxor destroys any patterns from the input, which was the purpose of
> CBC, without using the feedback path which Eli exploited.

Or for the rabid, clinically paranoid:

3des | tran | IDEA | tran | Diamond | tran | Blowfish | prngxor | 
3des | tran | IDEA | tran | Diamond | tran | Blowfish | prngxor | 
3des | tran | IDEA | tran | Diamond | tran | Blowfish | prngxor | 
3des | tran | IDEA | tran | Diamond | tran | Blowfish | prngxor | 
3des | tran | IDEA | tran | Diamond | tran | Blowfish | prngxor | 
3des | tran | IDEA | tran | Diamond | tran | Blowfish | prngxor | 
3des | tran | IDEA | tran | Diamond | tran | Blowfish | prngxor | 
3des | tran | IDEA | tran | Diamond | tran | Blowfish | prngxor | 
3des | tran | IDEA | tran | Diamond | tran | Blowfish | prngxor | 
3des | tran | IDEA | tran | Diamond | tran | Blowfish | prngxor | 
3des | tran | IDEA | tran | Diamond | tran | Blowfish | prngxor | 
3des | tran | IDEA | tran | Diamond | tran | Blowfish | prngxor | 
... about 500 more lines of the same ...

with a memorized 5 megabyte key.

And I thought 15 round Diamond with a 256 bit key was overkill worse than 
3 key triple DES!

Seriously, folks, the weakest links of most cryptosystems are not in the 
symmetric key cipher (provided you pick one of the good ones), but in the 
key management, associating people with keys, and in picking good pass 
phrases.

Peace to you.
Mike Johnson
m.p.johnson@ieee.org

On Fri, 15 Jul 1994, Carl Ellison wrote:
> I'd be most concerned about any ciphertext-only attack which is improved by
> having purely random bits as input.  Whichever algorithm is more resistant
Ahhhhhhh, I don't know how to say this, but no such atack exists, and 
none will ever exist.  You can not EVER atack a cipher if the plaintext 
is "random", as you have no basis for saying which "plaintext" is in fact 
the "plaintext".  Now if you know the plaintext(random bits) this is a 
different story.

Roger.

>Date: Fri, 15 Jul 1994 17:09:47 -0600 (MDT)
>From: Berzerk <berzerk@xmission.xmission.com>
>Subject: Re: Triple encryption...

>On Fri, 15 Jul 1994, Carl Ellison wrote:
>> I'd be most concerned about any ciphertext-only attack which is improved by
>> having purely random bits as input.  Whichever algorithm is more resistant
>Ahhhhhhh, I don't know how to say this, but no such atack exists, and 
>none will ever exist.  You can not EVER atack a cipher if the plaintext 
>is "random", as you have no basis for saying which "plaintext" is in fact 
>the "plaintext".  Now if you know the plaintext(random bits) this is a 
>different story.

Call it a hunch.

I didn't say I knew of any such attacks.  In fact, I used to believe that
such are completely impossible (and may yet come back to that belief), but
for the moment, I'm entertaining the notion of such attacks and seeing
where that leads me.  If there were such attacks, they would rely on
information about the key leaking into the ciphertext, independent of the
plaintext.  It might be possible to prove that any key-driven permutation
(1:1 mapping) can not allow such attacks, but I haven't composed such a
proof yet.

 - Carl

On Sun, 17 Jul 1994, Carl Ellison wrote:
> where that leads me.  If there were such attacks, they would rely on
> information about the key leaking into the ciphertext, independent of the
> plaintext.  It might be possible to prove that any key-driven permutation
This is bogus.  No symetric algorithim has this characteristic, in fact, 
the 1 on 1 nature of the algorithim precludes this as the total ammount 
of information is equal to the information in the plaintext.  The proof 
is simple enumeration.

Roger.