On Thu, May 23, 2019 at 01:07:25PM +0000, Pascal Van Leeuwen wrote: > Eric, > > I'm running into some trouble with some random vectors that do *zero* > length operations. Now you can go all formal about how the API does > not explictly disallow this, but how much sense does it really make > to essentially encrypt, hash or authenticate absolutely *nothing*? > > It makes so little sense that we never bothered to support it in any > of our hardware developed over the past two decades ... and no > customer has ever complained about this, to the best of my knowledge. > > Can't you just remove those zero length tests? > For hashes this is absolutely a valid case. Try this: $ touch file $ sha256sum file e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 file That shows the SHA-256 digest of the empty message. For AEADs it's a valid case too. You still get an authenticated ciphertext even if the plaintext and/or AAD are empty, telling you that the (plaintext, AAD) pair is authentically from someone with the key. It's really only skciphers (length preserving encryption) where it's questionable, since for those an empty input can only map to an empty output. Regardless of what we do, I think it's really important that the behavior is *consistent*, so users see the same behavior no matter what implementation of the algorithm is used. Allowing empty messages works out naturally for most skcipher implementations, and it also conceptually simplifies the length restrictions of the API (e.g. for most block cipher modes: just need nbytes % blocksize == 0, as opposed to that *and* nbytes != 0). So that seems to be how we ended up with it. If we do change this, IMO we need to make it the behavior for all implementations, not make it implementation-defined. Note that it's not necessary that your *hardware* supports empty messages, since you can simply do this in the driver instead: if (req->cryptlen == 0) return 0; - Eric
