On Fri, 24 May 2019 at 09:47, Pascal Van Leeuwen <pvanleeuwen@xxxxxxxxxxxxxxxx> wrote: > > > > 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". > Apologies, I did not mean to imply that you don't understand your own hardware. > 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. > Those are usually the consequences of a HW guy deciding to punt something to software. The software never looks better for it :-) > 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. > Yuck indeed. Sacrificing correctness for reduced silicon area comes with a cost. > > 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. > This is intractible. Software already exists that does not treat the zero length vector as a special case. Such software may be plumbed into the kernel crypto API via its AF_ALG interface. So the only wiggling room we have is in the kernel driver. > > > 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 ... > As others have pointed out as well, h/w accelerated crypto is exposed to userland, so nobody knows how exactly it is being used in the field.
