> > Valid? A totally fabricated case, if you ask me. Yes, you could do that, > > but is it *useful* at all? Really? > > Yes, really. The likelihood of a test vector occurring in practice is > entirely irrelevant. What matters is that the test vectors provide > known outputs for known inputs, and many algorithm specifications > explicitly contain the empty message as one of the documented test > vectors. > I wholeheartedly disagree - in the context of hardware design, anyway. When you implement something, you care about practicle usability. Wasting gates / timing / power / cycles / whatever on something that has no use relevant use case is just silly. (In the particular case of zero length messages, this is not so trivial to implement in a data driven HW architecture! Data driven ... But no data ...) As long as you properly specify your hardware's limitations, it should not need to be an issue. If the HW doesn't match your use case, then don't use it for that ... HW almost always has such limitations. For FIPS certification, zero length vectors are considered *optional*. Probably because they realized most HW out there can't do it ... > In fact, given the above, I am slightly shocked that your hardware > does not handle empty messages correctly. Are you sure it is a > hardware problem and not a driver problem? > As a matter of fact, pretty sure, yeah, as I'm actually "the HW guy". Nothing really shocking about that. We mainly do network protocol acceleration anyway, being able to do some basic operations is just a bonus. We do specify very extensively what we can and cannot support. > In any case, as Eric points out as well, nothing is stopping you from > adding a special case to your driver that falls back to the software > implementation for known broken test cases. > Sure. But my point is that you end up with a driver full of special cases. Which is just bloat slowing it down and blowing it up. Besides, in order to be able to fallback to software for this case I would have to maintain a shadow software context for *every* HW context just because someone *might* do some zero length operation somewhere in the future. Because by the time the context is established (setkey), I cannot predict that I will get such a zero length request yet. Yuck. > Removing test cases from the set because of broken hardware is out of > the question IMO. It doesn't actually fix the problem, and it may > actually result in breakage, especially for h/w accelerated crypto > exposed to userland, of which we have no idea whatsoever how it is > being used, and whether correct handling of zero length vectors is > likely to break anything or not. > The driver could check for it and return an -EINVAL error code. That would not break anything besides the application itself trying to do this. Which could then fail gracefully. > > No, it's not because a file of length 0 is a file of length 0, the length > > in itself is sufficient guarantee of its contents. The hash does not add > > *anything* in this case. It's a constant anyway, the same value for *any* > > zero-length file. It doesn't tell you anything you didn't already know. > > IMHO the tool should just return a message stating "hashing an empty file > > does not make any sense at all ...". > > > > You are making assumptions about how the crypto is being used at a > higher level. Eric's example may not make sense to you, but arguing > that *any* use of sha256sum on empty files is guaranteed to be > non-sensical in all imaginable cases is ridiculous. > Actually, the thought occurred to me in the shower this morning that that *might* be useful in case you don't have expectations of the length whatsoever and only know the expected sum. In which case that would validate that a zero-length file is indeed what you should have ... Still - is that something the crypto API is *currently* being used for? And if not, do we ever *intend* to use it for something like that? If not, then we could just specify it to be illegal such that no one would ever attempt to do it. You have that freedom as long as there are no existing applications depending on it ... Regards, Pascal van Leeuwen Silicon IP Architect, Multi-Protocol Engines Tel. : +31 (0)73 65 81 900 www.insidesecure.com
