On Thu, May 23, 2019 at 4:06 PM Eric Biggers <ebiggers@xxxxxxxxxx> wrote: > > On Thu, May 23, 2019 at 01:07:25PM +0000, Pascal Van Leeuwen wrote: > > > > 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; +1. It seems like a firmware update in the hardware or a software update to the driver are the ways to proceed. Why isn't the driver able to work around the hardware bugs? I don't think it is wise to remove tests from the Test Manager. Jeff
