[Plants] Re: Higher forgery resistance almost for free?

[Amir Herzberg <[e-mail]>]

On Sun, May 10, 2026 at 10:56 PM Andrew Ayer <[e-mail]> wrote:

> On Thu, 07 May 2026 15:31:20 +0200
> "Filippo Valsorda" <[e-mail]> wrote:
>
> > I still don't understand why going above 128 bits of security for one
> > property when the rest of the system targets 128 bits is worth
> > anything,


I beg to differ; not all goals are as critical. Preventing forgery is the
#1 goal of a PKI; ensuring transparency even against a rogue CA is much
less critical. Don't forget that a rogue CA that intentionally creates a
collision to circumvent transparency, will still be likely detected and
removed from the root program, i.e., we have accountability of CAs.


> and I disagree it's worth adding 32 bytes to every single
> > Web TLS handshake (and reintroducing a policy requirement which we
> > have seen cause trouble in the past, because "entropy" can't be
> > externally assessed).


> I strongly agree.
>
> The extra 32 bytes also mean higher bandwidth and storage costs for
> mirrors and monitors. With one root store operator strongly encouraging 7
> day MTCs, these extra 32 bytes will add up fast. It's not worth it.


Maybe we can reach a compromise by using `practically unpredictable, almost
pseudo-random' 32 B? Two alternative methods:

Method 1:  CA can use the same 32B for all certs. This may still require
sending the 32B in TLS handshakes (Filippo's concern) but avoid (almost
all) extra cost for mirrors and monitors.

Method 2:
(2.1) The leftmost (`first') leaf of the MT, which I denote $L_1$, contains
32 random bytes (instead of a cert).
(2.2) The $i^{th}$ cert in the tree, denoted $C_i$ (where $i\geq 1$), is
placed in leaf $L_{i+1}$ of the tree. $C_i$ will contain, in addition to
the usual cert, also the (32B of the) hash of the lowest node in the proof
of inclusion (PoI) of $C_i$.

I'll give two examples (simplifying as is each node in the MT is just the
hash of its one or two descendents).

Example 1: $C_1$, the 1st cert in the tree, which will be the 2nd leaf
($L_2$), will contain the hash of the (random) 1st leaf $L_1$, i.e., we
will add to the other fields of $C_1$ the 32B string $h(L_1)$.

Example 2: $C_2$, the 2nd cert in the tree, which will now be the 3rd leaf
($L_3$), will contain, in addition to the other certificate fields, also
the 32B value $h(h(L_1)||h(L_2))=h(h(L_1)||h(C_1))$.

Using the 2nd method, there is no extra communication or storage - we send
the PoI anyway.

best, Amir
-- 
Amir Herzberg

Comcast professor of Security Innovations, Computer Science and
Engineering, University of Connecticut
Homepage: https://sites.google.com/site/amirherzberg/home
`Applied Introduction to Cryptography and Cybersecurity' textbook:
https://sites.google.com/site/amirherzberg/crypto-cyber-book



On Sun, May 10, 2026 at 10:56 PM Andrew Ayer <[e-mail]> wrote:

> On Thu, 07 May 2026 15:31:20 +0200
> "Filippo Valsorda" <[e-mail]> wrote:
>
> > I still don't understand why going above 128 bits of security for one
> > property when the rest of the system targets 128 bits is worth
> > anything, and I disagree it's worth adding 32 bytes to every single
> > Web TLS handshake (and reintroducing a policy requirement which we
> > have seen cause trouble in the past, because "entropy" can't be
> > externally assessed).
>
> I strongly agree.
>
> The extra 32 bytes also mean higher bandwidth and storage costs for
> mirrors and monitors. With one root store operator strongly encouraging 7
> day MTCs, these extra 32 bytes will add up fast. It's not worth it.
>
> Regards,
> Andrew
>
> _______________________________________________
> Plants mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>