Re: [TLS] Merkle Tree Certificates

[Ilari Liusvaara <[e-mail]>]

On Tue, Jun 06, 2023 at 01:28:17PM +0200, Bas Westerbaan wrote:
> > > Thanks! That’s indeed inconsistent, we’ll fix it.
> > > https://github.com/davidben/merkle-tree-certs/issues/32
> >
> > Hmm... Looking at that construct, why is the pad there?
> 
> 
> We pad to the hash block size. When computing the full Merkle tree, or
> verifying an authentication path, the values before the pad are the same,
> and thus we can precompute the hash state after digesting those fixed
> values.
> 
> (With the current inputs and sha256, it will only make a difference for
> HashAssertion though.)

I mean, is there a cryptographic reason for it? 

If one wanted to really micro-optimize performance, I think the optimal
design for SHA-256 would be to have padding for assertions but not for
empty nor nodes (since not padding empty and node saves one block).

(However, absent cryptographic reasons, this all is way premature.)


> > And there does not seem to be any way to salt the hash. WebPKI requires
> > what effectively amounts to salting the hash via serial number (even
> > for SHA-256).
> >
> 
> Please elaborate.

>From CABForum Baseline Requirements version 1.8.7 (2.0.0 has the same
requirement, but in several places), section 7.1.:

"CAs SHALL generate non‐sequential Certificate serial numbers greater
than zero (0) containing at least 64 bits of output from a CSPRNG."

In certificate structure, serial number comes very early (it is in
fact the first non-length field that varies). What that in effect does
is to make it much more difficult to exploit chosen-prefix collisions in
hash function.

However, that requirement holds irrespective of the hash function used,
and it has in fact been held for SHA-256 (regardless of there not being
any known even remotely feasible attacks) instead of just being a dead
letter from the past with much worse hash functions.




-Ilari