Continuing with: Account request + libgcrypt security finding

Bert van der Weerd via Gcrypt-devel <[email protected]> Wed, 15 Apr 2026 13:54:53 +0000
Newsgroups gmane.comp.encryption.gpg.libgcrypt.devel
Message-ID <ummvavqzkslo42vslkezt5icixcftbydgk4b66hqpnj5tmz54l@6pakdm3lixly>
--b1=_qh1q306ePmQUwRpyQNvNcymCNw0i8F9WPhBOK8wIx4
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi NIIBE, list,

This is my first message from my other email addres that has a yubikey-back=
ed key. I'm working on getting it working with my neomutt.
Because I just subscribed, it cannot reply to the thread about set_iv(). --=
> /me looks in the mirror: Yah, it's really me :o) and I have a second patc=
h.



Okay, I removed all the FIPS related patch content and reformulated the gua=
rd statement, this second patch.

I'm aware that there are other issues, and am just trying to help, so I'm j=
ust focusing on fixing this leak that is still there.

The issue:

In non-FIPS mode, _if_ the caller never invokes set_iv() before calling gcm=
_encrypt(), gcm_decrypt(), or gcm_authenticate(), the library does not retu=
rn an error.
It silently calls _gcry_cipher_gcm_setiv_zero(), which initializes the IV t=
o an all-zero static buffer and proceeds. The caller receives no indication=
 that anything is wrong.

This is a real vulnerability. The triggering condition is straightforward:

Any caller that opens a GCM cipher handle, sets a key, and encrypts without=
 setting an IV gets a zero nonce silently.
In a multi-message session this means nonce reuse under the same key =
=E2=80=94 GCM authentication is broken and confidentiality is compromised.
My demo program demonstrates this: without set_iv(), gcry_cipher_encrypt() =
returns GCRY_ERR_NO_ERROR while using a zero IV, and the ciphertext is decr=
yptable =E2=80=94 confirming silent proceed, not a no-op.



Now my fix is basically in the three affected functions to write a guard:

  if (!c->marks.iv && c->aead.geniv_method =3D=3D 0)
    return GPG_ERR_INV_STATE;

And as you say it's not recommended IV practice, but still, it's not comple=
tely weird API usage either...



I'm thankful for pointing out the relevant tickets for the FIPS related stu=
ff.

Best regards,
--Bert


--b1=_qh1q306ePmQUwRpyQNvNcymCNw0i8F9WPhBOK8wIx4
Content-Type: text/x-diff; charset=us-ascii; name=cipher-gcm-zero-iv-fallback-2.patch
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=cipher-gcm-zero-iv-fallback-2.patch

ZGlmZiAtLWdpdCBhL2NpcGhlci9jaXBoZXItZ2NtLmMgYi9jaXBoZXIvY2lwaGVyLWdjbS5jDQpp
bmRleCBhOWM0ODU1MS4uMDhhZjQ0ZmEgMTAwNjQ0DQotLS0gYS9jaXBoZXIvY2lwaGVyLWdjbS5j
DQorKysgYi9jaXBoZXIvY2lwaGVyLWdjbS5jDQpAQCAtOTc3LDYgKzk3Nyw4IEBAIF9nY3J5X2Np
cGhlcl9nY21fZW5jcnlwdCAoZ2NyeV9jaXBoZXJfaGRfdCBjLA0KICAgICAgIHx8IGMtPnVfbW9k
ZS5nY20uZ2hhc2hfZGF0YV9maW5hbGl6ZWQNCiAgICAgICB8fCAhYy0+dV9tb2RlLmdjbS5naGFz
aF9mbikNCiAgICAgcmV0dXJuIEdQR19FUlJfSU5WX1NUQVRFOw0KKyAgaWYgKCFjLT5tYXJrcy5p
diAmJiBjLT5hZWFkLmdlbml2X21ldGhvZCA9PSAwKQ0KKyAgICByZXR1cm4gR1BHX0VSUl9JTlZf
U1RBVEU7DQogDQogICBpZiAoIWMtPm1hcmtzLml2KQ0KICAgICBfZ2NyeV9jaXBoZXJfZ2NtX3Nl
dGl2X3plcm8gKGMpOw0KQEAgLTEwMTcsNiArMTAxOSw4IEBAIF9nY3J5X2NpcGhlcl9nY21fZGVj
cnlwdCAoZ2NyeV9jaXBoZXJfaGRfdCBjLA0KICAgICAgIHx8IGMtPnVfbW9kZS5nY20uZ2hhc2hf
ZGF0YV9maW5hbGl6ZWQNCiAgICAgICB8fCAhYy0+dV9tb2RlLmdjbS5naGFzaF9mbikNCiAgICAg
cmV0dXJuIEdQR19FUlJfSU5WX1NUQVRFOw0KKyAgaWYgKCFjLT5tYXJrcy5pdiAmJiBjLT5hZWFk
Lmdlbml2X21ldGhvZCA9PSAwKQ0KKyAgICByZXR1cm4gR1BHX0VSUl9JTlZfU1RBVEU7DQogDQog
ICBpZiAoIWMtPm1hcmtzLml2KQ0KICAgICBfZ2NyeV9jaXBoZXJfZ2NtX3NldGl2X3plcm8gKGMp
Ow0KQEAgLTEwNTIsNiArMTA1Niw4IEBAIF9nY3J5X2NpcGhlcl9nY21fYXV0aGVudGljYXRlIChn
Y3J5X2NpcGhlcl9oZF90IGMsDQogICAgICAgfHwgYy0+dV9tb2RlLmdjbS5naGFzaF9kYXRhX2Zp
bmFsaXplZA0KICAgICAgIHx8ICFjLT51X21vZGUuZ2NtLmdoYXNoX2ZuKQ0KICAgICByZXR1cm4g
R1BHX0VSUl9JTlZfU1RBVEU7DQorICBpZiAoIWMtPm1hcmtzLml2ICYmIGMtPmFlYWQuZ2VuaXZf
bWV0aG9kID09IDApDQorICAgIHJldHVybiBHUEdfRVJSX0lOVl9TVEFURTsNCiANCiAgIGlmICgh
Yy0+bWFya3MuaXYpDQogICAgIF9nY3J5X2NpcGhlcl9nY21fc2V0aXZfemVybyAoYyk7DQo=

--b1=_qh1q306ePmQUwRpyQNvNcymCNw0i8F9WPhBOK8wIx4
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Gcrypt-devel mailing list
[email protected]
https://lists.gnupg.org/mailman/listinfo/gcrypt-devel

--b1=_qh1q306ePmQUwRpyQNvNcymCNw0i8F9WPhBOK8wIx4--