Side-channel vulnerability in libgcrypt - the Marvin Attack

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


Hello,

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 analyse.py version 5 analysis
Sign test mean p-value: 0.1769, median p-value: 0.01503, min p-value: 
4.587e-55
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 
(±2.384e-08s)
Median of differences: 2.09797e-07s, 95% CI: 1.81122e-07s, 2.323270e-07s 
(±2.560e-08s)
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 
(±2.322e-08s)

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 - https://people.redhat.com/~hkario/marvin/
 2 - 
https://github.com/tomato42/marvin-toolkit/tree/master/example/libgcrypt
 3 - https://datatracker.ietf.org/doc/html/rfc8017#section-5.1.2
-- 
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic




More information about the Gcrypt-devel mailing list