On Apr 6, 2012, at 16:12, Sam Hartman wrote: > RFC 3961 says that you can pass in any length data to that operation, > which presumably includes 0. I think our checksums are well-defined for > 0-length inputs. It's not a widely tested code path, but it probably > works and we can work through any bugs relatively quickly. Greg Hudson > at MIT did check the aes128 code path and that seems to work.
It does say "any length". On the other hand, we did explicitly rule out empty messages for encryption, and I don't recall whether we thought as hard about the checksum case. I don't think des-mac-k is well-defined for a zero-length message. For a zero-length message, the length is a multiple of 8 octets, so no padding bytes are added. With a zero-length input, we get zero bytes out of the CBC-mode encryption… and then we're supposed to use the last block of that output as the MIC. However, it was described as "no longer recommended" even in RFC 1510, and between that and the des-die-die-die draft, I'm not inclined to worry about it too much. The rest appear to support zero-length messages. It's something to keep in mind for 3961bis. :-) Ken _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
