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

[Michael Richardson <[e-mail]>]

Bas Westerbaan <bas=[e-mail]> wrote:
    > In the current draft, the leafs (TBSCertificateLogEntry) are mostly
    > predictable by an attacker. Thus with 128-bit work, an attacker can find a
    > collision: a harmless TBSCertificateLogEntry which it'll ask the CA to
    > issue which has the same hash as a nefarious TBSCertificateLogEntry. [1]

Doesn't this require that the attacker be able to directly submit
the entire TBSCertificateLogEntry to the CA?  While most of the fields are
controlled or constant, at least the low-bits of Validity ought to be up to
the CA, as well as the choice of extensions, and I think, the order of them.

    > The standard way to solve this is to make the leaf unpredictable to the
    > attacker, by including a CA-picked random value (randomizer) in each leaf.
    > [2] That'll boost the forgery resistance above 192 bits and well along to
    > 256-bits [3].

    > The downside is that we need to add that 32-byte randomizer in each
    > certificate.

    > Worth it?

    > I would say so.

I buy your argument even if I'm wrong about above.

    > [1] There are some minor hurdles: it'll need to guess the serial number
    > correctly. And it'll need some immaterial field to vary to create attempts
    > for the colission. Oh, and of course 128-bit work, but we're suspending
    > disbelief for a moment.

I don't see a SerialNumber in the TBSCertificateLogEntry :-)
{Of course, I read 2^128 work, but maybe that's now implied...}

    > ( https://eprint.iacr.org/2022/1061.pdf ). The attack requires room in the
    > message for the logarithmically many collision values after the address.
    > It'll depend on the algorithm whether that's feasable for the
    > subjectPublicKeyInfo, and we can remove that room by moving
    > subjectPublicKeyHash earlier in TBSCertificateLogEntry. The rigorous
    > solution is not to use SHA-256, but a hash that is DM-SPR, such as
    > SHAKE-256. But is that worth it? With a trillion certificates the attack is
    > still in the order of 217-bit work.

My experience (as an engineer^Wphysicist-software-designer) is that, to date, most
preimage attacks are longer than the original.  AFAIK, DER encoding for enclosing SEQUENCE
would include the length of the object in bytes.  I think that means any
preimage has to be the same size as the original.
Or is my disbelief supposed to also accomodate same-sized preimage attacks :-)

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide