1994-07-15 - Re: Why triple encryption instead of split+encrypt?

Header Data

From: solman@MIT.EDU
To: Carl Ellison <cme@tis.com>
Message Hash: c5f01e3d41ee7440743f91ff6ce7ad6fed6ac3c49c2d8ce29ab5e004e7e20369
Message ID: <9407150726.AA13887@ua.MIT.EDU>
Reply To: <9407141449.AA19157@tis.com>
UTC Datetime: 1994-07-15 07:27:06 UTC
Raw Date: Fri, 15 Jul 94 00:27:06 PDT

Raw message

From: solman@MIT.EDU
Date: Fri, 15 Jul 94 00:27:06 PDT
To: Carl Ellison <cme@tis.com>
Subject: Re: Why triple encryption instead of split+encrypt?
In-Reply-To: <9407141449.AA19157@tis.com>
Message-ID: <9407150726.AA13887@ua.MIT.EDU>
MIME-Version: 1.0
Content-Type: text/plain


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

My point is that you can get the same level of
security with much less effort/computation.

BTW, am I incorrect in my belief that the additional
security provided by the 32 bit shifting TRAN operation
suggested for the 3DEA hardly provides any additional
security? (i.e. if they could break 3 IDEA operations
or 3 DES operations, they can break them with
32 bit shifting TRAN operations interleaved in just
about the same amount of time.) It looks like it would
make meet-in-the middle attacks take up substantially
more memory and make identifying successful decryptions
slightly more difficult, but for security against nearly
brute force there isn't much difference between
2^(47) and 2^(47.2) operations. 

JWS





Thread