[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Thoughts on a basic encryption mode
I am encouraged by the progress toward concensus we made last week. Of
course, much of that progress was made possible by minimizing what it was
we had to agree on -- a 32 bit SAID, followed by something we haven't
fully defined yet.
To promote interoperability at at least a basic level of security, we
should define an encryption encapsulation algorithm that everyone can
implement, even though newer and better ones are certain to appear
later. We need to discuss this algorithm.
I propose that this basic algorithm be DES with cipher block chaining
(CBC). Ciphertext produced by this algorithm will always be a
multiple of 8 bytes long, so padding is necessary. The very last byte
of the decrypted plaintext contains a value from 0-6 indicating how much
of this last block should be considered valid data. And the second
last byte of the last block is the IP protocol field.
This leaves a few questions for discussion.
First, should we use DES as opposed to IDEA? DES has a smaller key and
is showing signs of age, but it is widely available and avoids patent
issues (IDEA is patented in the US). DES is also more readily
available in hardware, though I suspect that the vast majority of
IPSEC implementations will do it in software.
Second, should we use standard DES, or can we eliminate the initial
and final permutations? These are widely regarded as having no
cryptographic value, and eliminating them can improve software
performance substantially. The only drawback is the loss of direct
interoperability with "standard" DES in hardware, but such systems
could always "undo" the permutations in software to remain compatible.
And again, I expect the vast majority of IPSEC implementations will do
DES in software.
Third, do we need an explicit IV in every packet? 8 bytes is a lot of
overhead, and it may not be necessary in every case to ensure "churn"
in the resulting ciphertext. E.g., when encrypting an IP datagram the
ID field will land within the first 8 bytes of plaintext, and this
will ensure completely different ciphertext from packet to packet even
if the remaining packet contents are identical.
Remember, what I'm proposing here would be a basic encryption mode
that everyone would implement to ensure interoperability, but its use
would NOT be mandatory in any particular situation. Consenting hosts
would always be able to negotiate the use of any alternative
encryption scheme that they both support.
Phil
Follow-Ups: