RE: another testmgr question

[Pascal Van Leeuwen <pvanleeuwen@insidesecure.com>]

> > Valid? A totally fabricated case, if you ask me. Yes, you could do that,
> > but is it *useful* at all? Really?
> > 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 ...".
> >
>
> Of course it's useful.  It means that *every* possible file has a SHA-256
> digest.  So if you're validating a file, you just check the SHA-256 digest;
> or
> if you're creating a manifest, you just hash the file and list the SHA-256
> digest.  Making everyone handle empty files specially would be insane.
>
As I already mentioned in another thread somewhere, this morning in the
shower I realised that this may be useful if you have no expectation of
the length itself. But it's still a pretty specific use case which was
never considered for our hardware. And our HW doesn't seem to be alone in
this.
Does shaXXXsum or md5sum use the kernel crypto API though?

>
> The standard attack model for MACs assumes the attacker can send an arbitrary
> (message, MAC) pair.  Depending on the protocol there may be nothing
> preventing
> them from sending an empty message, e.g. maybe it's just a file on the
> filesystem which can be empty.  So it makes perfect sense for the HMAC of an
> empty message to be defined so that it can be checked without a special case
> for> empty messages, and indeed the HMAC specification
> (https://csrc.nist.gov/csrc/media/publications/fips/198/1/final/documents/fip
> s-198-1_final.pdf)
> clearly says that 0 is an allowed input length.  Note that the algorithmic
> description of HMAC handles this case naturally; indeed, it would be a
> special case if 0 were *not* allowed.
>
> Essentially the same applies for AEADs.
>
Oh, it's defined all right. I never argued that it wasn't.
But just because the *algorithm* allows it doesn't necessarily mean that you
*have* to support it from your API. Even FIPS allows for not supporting zero
length for validation - zero length support is optional there.

And I'm just not aware of any real use case - usually some standard non-zero
header is included as AAD - so why bother going out of your way to support it.
If something fails because of this, you can always fix it right there and then.

>
> People can develop weird dependencies on corner cases of APIs, so it's best
> to
> avoid cases where the behavior differs depending on which implementation of
> the
> API is used.  So far it's been pretty straightforward to get all the crypto
> implementations consistent, so IMO we should simply continue to do that.
>
I want to bet the people having to implement all these workarounds and fixes
in those drivers would argue that it's not so straightforward at all ...

> What might make sense is moving more checks into the common code so that
> implementations need to handle less, e.g. see how
> https://patchwork.kernel.org/patch/10949189/ proposed to check the message
> length alignment for skciphers (though that particular patch is broken as-
> is).
>
That goes without saying.

Regards,
Pascal van Leeuwen
Silicon IP Architect, Multi-Protocol Engines @ Inside Secure
www.insidesecure.com