Side-channel vulnerability in libgcrypt - the Marvin Attack

Hubert Kario hkario at
Thu Mar 7 14:46:22 CET 2024


I've tested libgcrypt against the Marvin Attack[1] and have verified it to
be vulnerable.

Running the test harness from marvin-toolkit[2] I got the following result:

tlsfuzzer version 5 analysis
Sign test mean p-value: 0.1769, median p-value: 0.01503, min p-value: 
Friedman test (chisquare approximation) for all samples
p-value: 2.0539047856632484e-85
Worst pair: 2(no_padding_48), 4(signature_padding_8)
Mean of differences: 2.09765e-07s, 95% CI: 1.83451e-07s, 2.311208e-07s 
Median of differences: 2.09797e-07s, 95% CI: 1.81122e-07s, 2.323270e-07s 
Trimmed mean (5%) of differences: 2.09885e-07s, 95% CI: 1.84586e-07s, 
2.308092e-07s (±2.311e-08s)
Trimmed mean (25%) of differences: 2.10169e-07s, 95% CI: 1.84646e-07s, 
2.302561e-07s (±2.281e-08s)
Trimmed mean (45%) of differences: 2.09076e-07s, 95% CI: 1.82240e-07s, 
2.321705e-07s (±2.497e-08s)
Trimean of differences: 2.08114e-07s, 95% CI: 1.80188e-07s, 2.266213e-07s 

Looking more closely at results, the side-channel from removal of blinding
or conversion of the integer returned from the RSADP() operation[3] to a
byte string is the most significant source of leakage.
That means that all padding modes that use RSA will be vulnerable: raw RSA
(RSASVE), PKCS#1v1.5, and RSA-OAEP.

But even with this code fixed, because the API of the decryption operation
doesn't permit a side-channel free returning of error messages (as the
returned object has different type and size depending on error or size of
the decrypted message), fixing it will require either implementing implicit
rejection or providing API specifically for PKCS#1v1.5 decryption.

This issue has been assigned CVE-2024-2236

 1 -
 2 -
 3 -
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic

More information about the Gcrypt-devel mailing list