[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Thoughts on a basic encryption mode
Phil Karn says:
> 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.
This is clear. A baseline of functionality is needed by all
implementations in order to assure that we don't die of optionitis.
I'll discuss what you mention out of order.
> 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 seems 100% perfectly reasonable, except for the fact that you
haven't discussed MACs, check fields, or other options to assure
integrity (although you do discuss the question of IVs later on). We
need to decide on whether the "base algorithm" should have some
explicit integrity check.
> 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.
Sequence numbers in TCP-only encapsulations might serve a similar
purpose. I'm not sure, however, that either is long enough to really
provide good initialization. Does anyone else have an opinion on this?
> 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 widely recognised as "good" -- IDEA does not have
sufficiently widespread buy-in. DES is also (nearly) patent free.
> DES is also more readily available in hardware, though I suspect
> that the vast majority of IPSEC implementations will do it in
> software.
This is true, but don't forget that several vendors ARE selling
encrypting tunneling gateways (UUNET among them) and it might be nice
to get them interoperable.
> 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.
Undoing them in hardware might also be quite feasable.
However, my feeling is that we ought to stick to the DES as specified
if only to keep things "standard". Since we've opened up the
floodgates for negotiated encryption, a very easy "optional" change
would be DES without the initial and final permutations. My feeling
is, however, since hardware manufacturers are a major potential client
of the protocol that the "mandatory" algorithm should be standard.
> 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.
I like virtually everything you've proposed, except that I somewhat
feel that the "no permutation" mode might better be a negotiated
option rather than the "mandatory" part of the algorithm set.
Perry
References: