[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: replay field size
>> We should be able to just plug in a new cipher algorithm and a new
>> digest algorithm without having to re-invent the wheel. Just plug
in
>> their identifiers and go...
>There _is_ more to it than just identifiers. Different algorithms
have
>different modes and different resulting data sizes and IVs and so
forth.
>With AH HMAC SHA-1 there was the question raised of using the
standard
>160-bit SHA-1 output or truncating to use 128-bits of SHA-1 output.
>If one truncates, then the method/process of truncation needs to
>be openly and clearly specified. Just assigning identifiers will
>tend NOT lead to interoperable implementations. Additional
structure
>to the base specifications will help, but is probably not a panacea.
Ran, my point was that a very large portion of the existing transform
drafts contain the exact same words and definitions. Yes, more than
an identifier would be required for some algorithms, but again there
exists quite a lot of the specification wording that overlap. Rules
for such things as truncating a digest (or padding it) would be better
defined in a common draft (ESP and/or AH).
If there was a common method to obtain a variable length IV and
variable length keys from keying material, then this information would
not have to be in every transform draft.
Why should all ESP transform drafts list the ESP structure, define
replay protection, and define how to obtain keying? These common
specification sections only need to be specified once.
Follow-Ups: