[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
draft-ipsec-cipher-generic.txt (was: draft-...cipher-*)
I had written such a draft and submitted it before the second last ANX
tests to the ANX mailing list, but most peole thought it would be better
to have a separate draft for each algorithm.
Now that we have a more unified ESP model, it might be worth while to do
a generic/multi-algorithm ESP algorithm draft. What do people think?
On Saturday, September 20, 1997 5:13 PM, Helger Lipmaa
[SMTP:helger@ioc.ee] wrote:
> On Fri, 19 Sep 1997, Theodore Y. Ts'o wrote:
>
> > Speaking personally, I'd rather not include a document for every single
> > cryptographic algorithm under the sun, just for completeness sake.
>
> Same here. I think that it would be a much better idea to compose one
> draft for all (or most) block ciphers that would give a general framework
> on using them in ESP.
>
> Parts of this document ought to go like that:
>
> ...
>
> This document gives implementers general instructions for using
> any standard block cipher algorithm in CBC mode to secure ESP.
>
> For information about concrete ciphers (key sizes, block sizes,
> performance, patents) see "Handbook of Applied Cryptography". The
> warnings about weaknesses of concrete ciphers given there (weak keys,
> minimal number of rounds) given there MUST be followed.
>
> Implementers SHOULD also be aware of the newest attacks available in
> the cryptographical literature.
>
> /* I consider [Schneier] to be a unsuitable reference for RFC's.
> HAC is much better, but not complete (and partly out-of-date).
> The best reference (imho) available is by Lars Knudsen at
> http://www.esat.kuleuven.ac.be/~knudsen/bc and is continously
> changing. Maybe IPSEC WG should contact Lars and ask him to
> collaborate by adding some IPSEC specific info to this page
> (e.g., by emphasing for dumb implementers the ciphers and parameters
> that are considered to be long term secure atm).
> */
>
> ...
>
> ... ESP Payload
>
> Most block ciphers in CBC mode require an initialization vector of
> $b/8$ octets for use with ESP, where $b$ is the block size in
> bits [Kent97]. The IV MUST precede the data to be encrypted in the
> packet and must be $b$ octets in length. The IV SHOULD be chosen at
> random. Common practice is to use random data for the first IV and the
> last $b/8$ of encrypted data from an encryption process as the IV for
> the next encryption process.
>
> ...
>
> XXX Block Size and Padding
>
> Block size of cipher algorithm in bits is denoted by $b$. /* Some
> overall requirements on $b$, e.g. $32|b$ */
>
> Padding is used to align the payload type and pad length octets as
> specified in [Kent97]. Padding must be sufficient to align the
> data to be encrypted to an $b/8$ octet ($b$ bit) boundary.
>
> ...
>
> XXX Some concrete ciphers
>
> While writing the draft, IPSEC WG encouraged using of the next
> ciphers with following parameters.
>
> Name | block size | key size | rounds |
> --------+------------+----------+--------+
> DES | 64 | 56 | 16 |
> ...
>
> One should be aware that new attacks are discovered continously,
> therefore implementers MUST consult the updated information [Knudsen?]
> once in a while.
>
> ...
>
> Actually, I think that most implementers are currently doing exactly what
> I've written here:
>
> x one needs general framework how to implement ESP with _any_ block
> cipher
> x data given in drafts gets older with every day; things like
> 'performance' or 'best attack currently known' shouldn't be there at
> all. For example, in draft-ietf-ipsec-ciph-idea-cbc-00.txt it is
> written:
>
> Normal eight round IDEA is approximately twice as fast [word 'as'
> missing] DES on 386 and 486 processors. However on a Pentium, both
> eight round IDEA and 56 bit key, 16 round DES require about the same
> number of clock cycles per byte encrypted.
>
> If you check the page by Knudsen, you get different figures.
>
> Best,
> Helger
>