-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,MIC-CLEAR
Content-Domain: RFC822
Originator-ID-Asymmetric:
ME0xCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5j
LjEcMBoGA1UECxMTUGVyc29uYSBDZXJ0aWZpY2F0ZQ==,12
MIC-Info: RSA-MD5,RSA,
adgc7k4HP4CBaof30PDF4L+pFctA09TuIqAM5pI8gT0jkagDhK5AGGnhMBwAMuJk
xAtAjE09qCvGhNz/W2G3FnXUAkQnGdoZYcTzA18ZbAkvI+heL9aG6I7xPF0SFKL+
Steve Dusse writes:
As far as how many keys to use, if 3 keys are better than 2 (which
seems to be true by assertion) than why not use 4 or 5. What is the
tradeoff ? If 2^112 (a big f*ing number) is not acceptable, what
makes 2^168 acceptable ? If DES is broken by some means other than
brute force, then the extra burden if another DES operation may do
very little to the security.
There's an added cost in doing 4, 5, etc. whereas there's no added
cost in doing 3 keys vs. 2.
My preference would be to go with a single standard (even at the risk
of phasing-out current use of single-DES) which balances security,
ease of implementation, and (my favorite) export issues. (Have we
forgotten our place in the global Internet community ? Shall we doom
all US PEM manufacturers to the "support multiple versions or don't sell
outside the US" curse ?)
*Sigh* My suspicion is that 2 keys or anything comparable will not
be exportable rendering this issue moot. Unless you know something I don't
(a strong possibility considering that crypto is your professional concern
whereas it's my hobby), plain ol' DES is still not exportable...
If on the other hand, you are proposing yet another algorithm which *is*
exportable, then that's a different story.
Carl writes:
If someone has a DES chip which does CBC mode by itself, it is *far* more
efficient to encrypt a batch with k1, then do the batch with k2 and then
do the batch with k3. In brutal detail:
My understanding is that DES chips did... DES. No CBC, etc.
-Ray
-----END PRIVACY-ENHANCED MESSAGE-----
Created with RIPEM Mac.