Suresh Krishnan writes: > Summary: This draft is almost ready for publication as a Proposed > Standard but I have a comment you might wish to address. > * Section 2 > > The Encode_96 function mentions that the output is obtained by > "extracting the middle 96-bit long bitstring" from the argument. This > seems to be in conflict with Appendix E of RFC5201bis where the HIT suite > 3 recommends truncation of the hash to 96 bits. Shouldn't this just be a > truncation function?
=> Encode_96 is a truncation function because it takes a continuous part of the input, or with other words truncated allows to truncate one at one end, or twice. I agree it is not the usual/default truncation function which takes the first bits. So IMHO there is no conflict, even one can argue RFC5201bis is not enough accurate. (*) BTW all truncation functions are not really equivalent from a crypto point of view but in this particular use case it doesn't matter. To finish the Orchid v1 (RFC4843) uses an Encode_100 with the middle 100 bits. Regards Francis Dupont <[email protected]> PS (*): RFC5201bis misses the 128 bit Context ID in the hash input so there is already a conflict. PPS for Julien: at line 289 OLD ORCHID := Prefix | Encode_96( Hash ) NEW ORCHID := Prefix | OGA ID | Encode_96( Hash ) _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
