Received-SPF: pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <AM6PR09MB3523CED0B1587FCBDE4095A0D2010@AM6PR09MB3523.eurprd09.prod.outlook.com>
 <20190523185833.GA243994@google.com> <AM6PR09MB3523749B0306103E8D2D8315D2010@AM6PR09MB3523.eurprd09.prod.outlook.com>
 <20190523200557.GA248378@gmail.com> <AM6PR09MB3523DB255516D35B595AEA50D2010@AM6PR09MB3523.eurprd09.prod.outlook.com>
 <CAKv+Gu9F8EcDE8GRSyHFUh_pPXPJDziw7hXO=G4nA31PomDZ1g@mail.gmail.com> <AM6PR09MB3523A3C44CFE5C83746B6136D2020@AM6PR09MB3523.eurprd09.prod.outlook.com>
In-Reply-To: <AM6PR09MB3523A3C44CFE5C83746B6136D2020@AM6PR09MB3523.eurprd09.prod.outlook.com>
From:   Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date:   Fri, 24 May 2019 11:15:35 +0200
Message-ID: <CAKv+Gu_-Z9rVC4Yup1ZyhES4-bYopMVNWw4-0d+G2oFD83z7OA@mail.gmail.com>
Subject: Re: another testmgr question
To:     Pascal Van Leeuwen <pvanleeuwen@insidesecure.com>
Cc:     Eric Biggers <ebiggers@kernel.org>,
        "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk

On Fri, 24 May 2019 at 09:47, Pascal Van Leeuwen
<pvanleeuwen@insidesecure.com> 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.