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
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
On Fri, 15 Jul 1994, Carl Ellison wrote: 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...
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
On Fri, 15 Jul 1994, Carl Ellison wrote: 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
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,
On Sun, 17 Jul 1994, Carl Ellison wrote: 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.
participants (4)
-
Berzerk -
Carl Ellison -
DAVESPARKS＠delphi.com -
Mike Johnson second login