From: "'Bas Westerbaan' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: bitcoindev@googlegroups.com
Subject: [bitcoindev] jpeg resistance of various post-quantum signature schemes
Date: Wed, 21 May 2025 12:32:33 +0200 [thread overview]
Message-ID: <CAMjbhoU=PCUwbhWFbqCbOdZc+ybmREJmmt1K1TuHrCTncKH6VA@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 5422 bytes --]
Hi all,
My colleague Ethan asked me the fun question which post-quantum signature
schemes have the following security property, which he called jpeg
resistance.
Attacker wins if for a (partially specified) signature and full message,
they can find a completed signature and public key, such that the completed
signature verifies under the public key.
A naive hash-based signature is not jpeg resistant. Schoolbook Winternitz
one-time signatures, forest-of-trees few-time signatures, and Merkle trees
all validate signatures (/authentication paths) by recomputing the public
key (/Merkle tree root) from the signature and the message, and checking
whether the recomputed public key matches the actual public key. That means
we can pick anything for the signature, and just set the public key to the
recomputed public key.
The situation is more subtle for actual standardized hash-based signatures.
RFC 8391 XMSS doesn’t sign the message itself, but first hashes in (among
others) the public key. Basically the best we can do for XMSS (except for
setting the signature randomizer) is to guess the public key. Thus it’s
pretty much jpeg resistant.
The situation is different again for RFC 8391 XMSSMT. XMSSMT is basically a
certificate chain of XMSS signatures. An XMSSMT public key is an XMSS
public key. An XMSSMT signature is a chain of XMSS signatures: the XMSSMT
public key signs another XMSS public key; which signs another public XMSS
public key; …; which signs the message. Again the top XMSSMT public key is
hashed into the message signed, but that only binds the first XMSS
signature. We can’t mess with the first signature, but the other signatures
we can choose freely, as those roots are not bound. Thus XMSSMT with two
subtrees is only half jpeg resistant and it gets worse with more subtrees.
Similarly SLH-DSA (FIPS 205, née SPHINCS+) is a certificate chain of (a
variant of) XMSS signing another XMSS public key, which signs another XMSS
public key, etc, which signs a FORS public key, which signs the final
message. The SLH-DSA public key is the first XMSS public key. From the
message and the public key it derives the FORS key pair (leaf) in the hyper
tree to use to sign, and the message to actually sign. This means we can’t
mess with the first XMSS keypair. Thus to attack SLH-DSA we honestly
generate the first XMSS keypair. Then given a message, we just pick the
signature arbitrarily for all but the first XMSS signature. We run the
verification routine to recompute the root to sign by the first XMSS
keypair. Then we sign it honestly. It depends a bit on the parameters, but
basically we get to pick roughly ⅞ of the signature for free.
ML-DSA (FIPS 204, née Dilithium) is a Fiat–Shamir transform of a
(module-)lattice identification scheme. In the identification scheme the
prover picks a nonce y, and sends the commitment w1 = HighBits(A y) to the
verifier, where A is a matrix that’s part of the public key and HighBits
drops the lower bits (of the coefficients of the polynomials in the
vector). The verifier responds with a challenge c, to which the prover
returns the response z = y + c s1, where s1 is part of the private key. The
verifier checks, among other things, whether HighBits(Az-ct) = w1, where t
= As1+s2 is part of the public key. As usual with Fiat–Shamir, in ML-DSA
the challenge c is the hash of the commitment, message, and public key. The
scheme has commitment recovery, so the signature itself consists of the
response z and the challenge c. (There is also a hint h, but that’s small
and we can ignore it.) If we set s1 to zero, then z=y, which is free to
choose. So we can freely choose z, which is by far the largest part of the
signature. Such a public key t is easy to detect, as it has small
coefficients. Instead we can set s1 to zero on only a few components. That
allows us to choose z arbitrarily for those components, still breaking jpeg
resistance, while being hard to detect. There could well be other
approaches here.
Falcon. A Falcon private key are small polynomials f,g. Its public key is h
= g f-1. With the private key, for any polynomial c, we can compute small s1
and s2 with s1 + s2h = c. A Falcon signature is a pair r, s2 where s1 =
H(r, m) - s2 h is small. s2 is Guassian distributed, and is encoded using
an Elias–Fano approach. It’s then padded to make signatures fixed-length.
Clearly the randomizer r can be set arbitrarily, but it’s only 40 bytes.
Putting arbitrary bytes in most of the encoding of s2 will likely yield a
sufficiently small s2. Now, I thought about using this s2 as a new g and
construct a signature that way by finding s’1 and s’2 with s’1 + s’2s1f-1 =
H(r,m), but my brother suggested a simpler approach. s2 is likely
invertible and we can set h = H(r, m)/s2. Both approaches would be thwarted
by using H(H(h), r, m) instead of H(r, m). I do not know if there is still
another attack.
Best,
Bas
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAMjbhoU%3DPCUwbhWFbqCbOdZc%2BybmREJmmt1K1TuHrCTncKH6VA%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 29470 bytes --]
next reply other threads:[~2025-05-21 11:20 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-21 10:32 'Bas Westerbaan' via Bitcoin Development Mailing List [this message]
2025-05-21 20:38 ` [bitcoindev] " Hunter Beast
2025-05-22 12:57 ` 'Bas Westerbaan' via Bitcoin Development Mailing List
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAMjbhoU=PCUwbhWFbqCbOdZc+ybmREJmmt1K1TuHrCTncKH6VA@mail.gmail.com' \
--to=bitcoindev@googlegroups.com \
--cc=bas@cloudflare$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox