On May 20, 23:57, Mark Riordan wrote:
If no one stops me, I will select 3-key EDE DES for implementation
in RIPEM.
I propose to use the identifier DES-EDE3-CBC for the algorithm
in the PEM (actually, at this point it would be pseudo-PEM)
header line.
Thanks to Mark Henderson and Richard Outerbridge, we already have
code just about ready to go, awaiting resolution of these details.
Many messages later:
While I agree that single-DES is quite secure, I can tell you
that one of the most frequently-made suggestions about RIPEM is
that something more secure than single DES be implemented.
In general, I attribute this to overenthusiasm on the part
of crypto-hackers. But, let's face it, these are the very
people who are the early adopters.
Also, I think the situation with DES is ironic. It has withstood
the test of time against theoretical attacks very well, while
retaining its one original glaring weakness: the short keysize.
This weakness can be addressed quite easily with Triple DES.
While I think that the bankers' EDE2 cryptochip issue is a
red herring, I propose that RIPEM implement EDE2 as its
enhanced algorithm.
What I propose we do is always RSA-encrypt k1, k2, k3 and include
them as the DEK. The message will be encrypted in EDE 3 mode,
but in this implementation, we always set k1=k3.
I don't feel guilty about the wasted 8 bytes of key.
I would have an additional command-line option -A alg
where alg is des-cbc, or des-ede-cbc.
The pseudo-PEM identifier in messages would be DES-EDE-CBC.
This would leave the door open for 3-key EDE in the future.
If EDE3 were ever implemented,
those chosen few who have EDE2 chips can code enhancements
to RIPEM to notice when k1=k3 and use hardware assist in that case.
The PEM identifier DES-EDE-CBC could be used in either case.
CBC would be applied after EDE. Thus, DES-EDE-CBC would be derived
from DES-CBC simply by taking out the single-DES and inserting
DES-EDE. IV's would not be encrypted.
Mark R.