To the PEM-DEV mailing list (& friends):
We RIPEM developers plan on adding triple-DES data encryption
to an upcoming version of RIPEM. (We have received permission
to modify the RSAREF API to do this.) As RIPEM is also slated to
become PEM-compatible in the not-too-distant future, I would
like input from PEM developers on two items:
1. Just what form of "triple DES" should be used?
2. What algorithm identifier (e.g., DES-EEE-CBC) should
be used in the DEK-Info: header line of the output ciphertext?
Triple DES isn't an official PEM algorithm yet--will it/should it
ever be?
------------------------------------------------------------------------
Regarding the exact definition of triple DES: this topic has been
enthusiatically debated in the last 24 hours by several RIPEM developers.
Some candidates are:
a. encrypt(encrypt(encrypt(block,k1),k2),k3) [EEE]
b. encrypt(decrypt(encrypt(block,k1),k2),k1) [traditional EDE]
c. encrypt(decrypt(encrypt(block,k1),k2),k3) [3-key EDE]
Here are some arguments that have been advanced in the last day.
My apologies to anyone quoted out of context, but I didn't want to
requote the entire exchange:
Ray Lau says:
I prefer, in the name of possible future compability, to downgrade
to EDE w/2 keys. It's pretty clear that EDE is the one that's been
around the longest because the proof that DES is not a group under enc.
is relatively recent. And I suspect that the 2 key version is in
wider use than the 3 key version.
112 bits is enough in my book. 2**112 is pretty astronomical.
If anything else, DES will fall apart
before exhaustive search of 2**112 becomes feasible!
Mark Henderson says:
On the other hand, the 3 key version is easy to implement, and barring a
breakthrough in the cryptanalysis of MD5, should be more secure (of
course, all the key bits, IV and padding are essentially pumped out of
MD5).
As to EDE vs EEE, I don't see that it matters much. Actually,
the first time I implemented it, I did EDE (3 keys).
TIS-PEM has some hooks for DES-EDE, but there isn't any code in there
to actually implement it.
So, if people want EDE, I'm content to go back to it. On the other
hand, I'd really like to stick with three independent DES keys. We
almost certainly don't get less security, and probably get a bit more,
essentially for free.
Carl Ellison says, in essence:
Even a minimum-size RSA key for key exchange has plenty of bits for
3 DES keys, so we might as well go for a three-key triple DES and
gain the additional keyspace over a 2-key triple DES. History is riddled with
cases of minimal escalation of security allowing almost uninterrupted
cryptanalysis success.
Richard Outerbridge says:
The de facto standard for double-DES >is< 2-key EDE. If we
want to stay as close as possible to standard practise and familiar
techniques, that's the way to go. Using CBC, of course. This is
absolutely the "most standard" way to go.
If we want to take it to the limit of standard practise, we could
use 3-key EDE. EDE vs. EEE doesn't matter much anymore, I agree,
but EDE is what everyone knows and loves. So use EDE. No one
anywhere (well, in the "private" sector) contemplates or advocates
using 3-key DES in practice. Not ISO, not ANSI, not even textbooks.
If discussed at all it's sort of "If you're >really< paranoid..."
On the other hand I wouldn't be surprised to find out that somewhere
on the bleeding edge, today, exists technology that won't be commonly
available for another forty years or so.
As to what the rest of the world will be using... I still don't think
the rest of the world (at least the commercial world) will be using
double-DES for anything but keys for some time to come. Frankly,
burt, I'm pleasantly surprised that RSA has authorised it for RSAREF.
Neither Atalla nor IBM permit (i.e. they prevent) the use of
double-length data keys. From that jaded perspective it doesn't much
matter what we do: we'll be the first, and the others can follow us.
Marty Hellman says:
Regarding "triple encryption," there is no cryptographic
difference between EEE or EDE (using Mark's notation)
if K1, K2 and K3 are independent. This follows from the
fact that DES does the same operations whether encrypting
or decrypting -- the only difference is that the C and D
key registers shift left or right, depending on encrypt vs
decrypt.
However, I think Mark's question is more directed toward
finding what is the "standard" way of doing triple encryption,
and there is no standard, at least that I am aware of. If I
were implementing it, I would probably do EDE since that
has been proposed as allowing easier compatability with
single encryption: merely set K1=K2=K3.
---------------------------------------------------------------
The conclusion so far:
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.
If anyone has objections, please voice them now.
The final question relates to exactly how the RSAREF API will
be changed to accomodation the additional data encryption mode.
I propose that we simply add an additional parameter to RSAREF's
functions R_XXXPEMBlock, where XXX = Encrypt, Decrypt, Seal, and Open.
This new last parameter would specify the data encryption algorithm.
It would be a manifest constant something like R_ALG_DES_CBC or
R_ALG_DES_EDE_CBC. This ought to be cleared with RSADSI before
distribution of any RIPEM using the new RSAREF.
Opinions?
Mark Riordan mrr(_at_)ripem(_dot_)msu(_dot_)edu