I am skeptical of this entire enterprise. In the spheres in which PEM
is expected to be used, there is no reason to believe that the
security of DES is not entirely adequate. Proliferating multiple
incompatible versions of PEM - i.e. I can send messages to you that
you can't read because I assumed you had the fancier crypto when you
didn't - seems a much greater threat to deployment than any worries
about the security of DES. A case can be made, however, that DES will
not be secure forever and that it would be better to get the
infrastructure in place for a replacement now so that it can be
present in virtually all implementations. If we can be confident it's
there, the sender has a more straightforward security vs performance
tradeoff and need not worry about compatibility. For that reason, I
think the most important consideration is that we only add *one* new
variant and that we as a community make every effort to see that it is
universally available (at least for receipt of messages). All of the
issues being debated seem small enough that we aren't going to make
any serious mistakes flipping a coin. I think whoever deploys first
should "win", and the community should rally support for that solution
and boo down subsequent proposals.
That said, I have some opinions on the issues, and can't resist
stating them:
1) There's no reason to believe EDE is any more secure than EEE, but
it's "more standard" so it seems obvious we should use it.
2) The security of 112 bits against exhaustive search will be adequate
for even the most paranoid for a very long time. The argument for
three keys is that some non-exhaustive search attack might be found
and three keys might be more secure against that new attack. The
argument for two keys is that it is "more standard" in an irrelevant
context and there might someday be useful hardware that depends on it.
I don't care whether you pick 2 or 3 keys; just please don't do both.
3) As an amateur cryptographer, I can see a lot of advantages of doing
sequential CBC encrypt/decrypt/encrypt steps on the entire message
over doing EDE on each block and doing a CBC outside of that step. It
is more likely to be able to make efficient use of existing hardware
that is designed for single DES; it allows new hardare designers the
flexibility of using three times as many gates instead of gates that
are three times as fast; it is not self-synchronizing and therefore
has the potential of efficiently combining encryption and integrity
protection; and coupled with encrypted IVs it can make cryptanalytic
attacks much more difficult. But I'm only an amateur and the pros
recommend doing it the other way. It might be they do that because
they want the result to be weaker, but it might be they have a good
reason. This is an area where unnecessary creativity is dangerous.
It seems clear we should go with the "proven" approach.
4) If we were starting from scratch, I would have preferred encrypted
IVs more because it would shorten the PEM header than because I
believed it added meaningful security. But given that DES-CBC does
not encrypt it, it seems silly to start now with a cryptographic
algorithm much less susceptible to cryptanalysis based on a single
known plaintext block.
5) Re: the suggestion that we should find a better strong encryption
algorithm than EDE, I'd say that it's true that it would be nice if
the cryptographic community were to propose a really strong DES
replacement with - say - a 128 bit block size and 256 bit keys, but
that it's certainly beyond the scope and almost certainly beyond the
qualifications of the PEM community to do so. We're doing well if we
can combine the proven algorithms competently into a secure package.
If we wanted to appease the "DES was designed with a trapdoor and even
EDE won't protect us" paranoids, we could do EDE where the middle step
uses IDEA instead of DES. But I'm not proposing that.
--Charlie
(kaufman(_at_)zk3(_dot_)dec(_dot_)com)