From gniibe at fsij.org Tue Apr 7 03:15:13 2026 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 7 Apr 2026 10:15:13 +0900 Subject: [PATCH] tests:kem: Don't emit a message each time, but once. Message-ID: <460695d0538b2d9df6511e7ae686469bcecc686a.1775524495.git.gniibe@fsij.org> * tests/t-kem.c (test_kem_sntrup761, test_kem_mceliece6688128f) (test_kem_mlkem512, test_kem_mlkem768, test_kem_mlkem1024): Don't emit message here. (check_kem): But here, before the loop. Signed-off-by: NIIBE Yutaka --- tests/t-kem.c | 15 +++++---------- 1 file changed, 5 insertions(+), 10 deletions(-) -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-tests-kem-Don-t-emit-a-message-each-time-but-once.patch Type: text/x-patch Size: 3273 bytes Desc: not available URL: From gniibe at fsij.org Fri Apr 10 03:45:44 2026 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 10 Apr 2026 10:45:44 +0900 Subject: [PATCH 1/2] cipher:dilithium: Fix the glue of libgcrypt. Message-ID: <5a875908cb95407e12c7d206e31c287b0e06dbca.1775717788.git.gniibe@fsij.org> * cipher/dilithium.h (dilithium_sign, dilithium_verify): Define the macro correctly so that we can keep using _gcry namespace for internal functions. -- It was mistake when we followed the code of Kyber. Fixes-commit: 81a8332963e2a5581ee0e7d0393363e8b9015bbf Signed-off-by: NIIBE Yutaka --- cipher/dilithium.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-cipher-dilithium-Fix-the-glue-of-libgcrypt.patch Type: text/x-patch Size: 555 bytes Desc: not available URL: From gniibe at fsij.org Fri Apr 10 03:45:46 2026 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 10 Apr 2026 10:45:46 +0900 Subject: [PATCH 2/2] cipher:dilithium: Check the label length by caller. In-Reply-To: <5a875908cb95407e12c7d206e31c287b0e06dbca.1775717788.git.gniibe@fsij.org> References: <5a875908cb95407e12c7d206e31c287b0e06dbca.1775717788.git.gniibe@fsij.org> Message-ID: <73ec45d3b5d3453cc48ce51939c80fe54c8e4016.1775717788.git.gniibe@fsij.org> * cipher/dilithium.h (dilithium_keypair, dilithium_sign) (dilithium_verify): Return gpg_err_code_t. * cipher/dilithium.c (dilithium_keypair): Return gpg_err_code_t. (dilithium_sign, dilithium_verify): Ditto. Check CTXLEN. * cipher/pubkey-dilithium.c (mldsa_generate): Follow the change. (mldsa_sign, mldsa_verify): Likewise. -- Reported by Calif.io in collaboration with Claude and Anthropic Research. GnuPG-bug-id: 8208 Co-authored-by: Thai Duong Signed-off-by: NIIBE Yutaka --- cipher/dilithium.c | 101 ++++++++++++++++++++++++++++---------- cipher/dilithium.h | 20 ++++---- cipher/pubkey-dilithium.c | 32 +++++------- 3 files changed, 99 insertions(+), 54 deletions(-) -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-cipher-dilithium-Check-the-label-length-by-caller.patch Type: text/x-patch Size: 9268 bytes Desc: not available URL: From saad at rhoulam.tech Fri Apr 10 16:38:11 2026 From: saad at rhoulam.tech (Saad Rhoulam) Date: Fri, 10 Apr 2026 22:38:11 +0800 Subject: [guile-gcrypt] Symmetric Ciphers Module Message-ID: Hello everyone, While hoping to make something in Guile that needed symmetric encryption, it fell to me to extend guile-gcrypt. Unfortunately, because of how some procedures like `gcrypt_cipher_gettag` are implemented, the Guile FFI reports that they don't exist! This blocks AEAD, which is what I needed, so it's back to the drawing board for me. But, short of AEAD, some amount of symmetric cryptographic functionality is accessible from Guile, hence the attached patch. I've left the AEAD-related code commented out in the module in case anyone is interested in this challenge. Regards, S. Rhoulam -------------- next part -------------- A non-text attachment was scrubbed... Name: cipher.patch Type: text/x-patch Size: 18361 bytes Desc: not available URL: From opalraava at riseup.net Sat Apr 11 18:41:40 2026 From: opalraava at riseup.net (Bert van der Weerd) Date: Sat, 11 Apr 2026 18:41:40 +0200 Subject: Account request + libgcrypt security finding Message-ID: <7hftswielxh2fbiatiz2lzqm3kr6f5ueucxsajeqs55govxj3s@7av4jx2eurix> Hi list, I would love to open an issue on dev.gnupg.org, but that requires an account. This mail is about the first of four high severity issues identified with some (current-gen) AI trickery. There are some 30-something other things flagged as mid to low severity. As per sign-on page, my requested account details would be: handle: threadpanic, shown name: Bert van der Weerd, address: bert at teamspicy.net The first patch is the first high severity issue: GCM silent zero-IV fallback ? patch and demonstration program made by Claude Code. I'm happy to discuss on-list; or privately first if preferred. Thanks for your time, --Bert From wk at gnupg.org Mon Apr 13 17:09:54 2026 From: wk at gnupg.org (Werner Koch) Date: Mon, 13 Apr 2026 17:09:54 +0200 Subject: [guile-gcrypt] Symmetric Ciphers Module In-Reply-To: (Saad Rhoulam's message of "Fri, 10 Apr 2026 22:38:11 +0800") References: Message-ID: <874ilelwvx.fsf@jacob.g10code.de> Hi! On Fri, 10 Apr 2026 22:38, Saad Rhoulam said: > encryption, it fell to me to extend guile-gcrypt. Unfortunately, > because of how some procedures like `gcrypt_cipher_gettag` are > implemented, the Guile FFI reports that they don't exist! This blocks Can you please explain this in more details. gcry_cipher_gettag is a pretty standard function and not a macro. Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 284 bytes Desc: not available URL: From wk at gnupg.org Mon Apr 13 17:12:09 2026 From: wk at gnupg.org (Werner Koch) Date: Mon, 13 Apr 2026 17:12:09 +0200 Subject: Account request + libgcrypt security finding In-Reply-To: <7hftswielxh2fbiatiz2lzqm3kr6f5ueucxsajeqs55govxj3s@7av4jx2eurix> (Bert van der Weerd via Gcrypt-devel's message of "Sat, 11 Apr 2026 18:41:40 +0200") References: <7hftswielxh2fbiatiz2lzqm3kr6f5ueucxsajeqs55govxj3s@7av4jx2eurix> Message-ID: <87zf36ki7q.fsf@jacob.g10code.de> On Sat, 11 Apr 2026 18:41, Bert van der Weerd said: > The first patch is the first high severity issue: GCM silent zero-IV > fallback ? patch and demonstration program made by Claude Code. Please explain the issue here. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 284 bytes Desc: not available URL: From gniibe at fsij.org Tue Apr 14 02:48:01 2026 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 14 Apr 2026 09:48:01 +0900 Subject: [guile-gcrypt] Symmetric Ciphers Module In-Reply-To: <874ilelwvx.fsf@jacob.g10code.de> References: <874ilelwvx.fsf@jacob.g10code.de> Message-ID: <877bqas6ym.fsf@haruna.fsij.org> Werner Koch wrote: > Can you please explain this in more details. gcry_cipher_gettag is a > pretty standard function and not a macro. IIUC, it's gcry_cipher_set_decryption_tag, which has the issue. It's a macro using gcry_cipher_ctl function. The glue code is needed to be written for such a macro. -- From opalraava at riseup.net Tue Apr 14 23:03:21 2026 From: opalraava at riseup.net (Bert van der Weerd) Date: Tue, 14 Apr 2026 23:03:21 +0200 Subject: Account request + libgcrypt security finding In-Reply-To: References: <7hftswielxh2fbiatiz2lzqm3kr6f5ueucxsajeqs55govxj3s@7av4jx2eurix> <87zf36ki7q.fsf@jacob.g10code.de> Message-ID: > On Mon, Apr 13, 2026 at 05:12:09PM +0200, Werner Koch wrote: > > On Sat, 11 Apr 2026 18:41, Bert van der Weerd said: > > > > > The first patch is the first high severity issue: GCM silent zero-IV > > > fallback ? patch and demonstration program made by Claude Code. > > > > Please explain the issue here. Hi Werner, all, This is an issue with the IV/nonce in the (Chacha20 stream cipher and) GCM encryption mode. The IV/nonce remains zero if set_iv() is not properly called before: _gcry_cipher_gcm_encrypt(), _gcry_cipher_gcm_decrypt(), _gcry_cipher_gcm_authenticate(). This is a known failure mode of these algorithmes, and the proper thing to do is return GPG_ERR_INV_STATE; I attached some AI slob: * cipher-gcm-zero-iv-fallback.readme.md - The full report of the bug, we did some digging in the code and found fips related code, and a function that was marked todo. * cipher-gcm-zero-iv-fallback.patch - The actual patch. In many ways the clearest I guess. Handcrafted (yay). * cipher-gcm-zero-iv-fallback.demo.md - This is the run results of the gcm issue: one patched, one unpatched. I'm not sending the cipher-gcm-zero-iv-fallback.demo.c file to the list, but I guess one can craft one conceptually. Will send it to wk at gnupg.org if you want? I'm not ready with the Chacha20 patch yet, sorry. I do have two other patches, that I can also just mail to this list, one is a typo in a function name and another is a forgotten wipememory(). This AI stuff is something I want to talk about. there are new (unreleased) AI models, from Anthropic and OpenAI. They actually eh... 'hack the planet' so to speak:) I just wanted to start off with the most pressing ones this generation of AI can already find. I can create a markdown file of all the bugs, but rather not. Well to be honest this is a lot of extra issues probably for a (short) while and then it cools down. Short version: I basically did a: for i in crypto/*.c; do foreach (fallacy in the Wikipedia 'fallacies' page) { check_the_c_file_for_it }; done; and a heap of markdown came out. I distrust AI professionally in code like this, so I just wanted to do the most critical then, and it did actually find something here, if I'm correct. I saw in the code that, yes, that Chacha20 thing might also be a positive. This patch is only about GCM. But I don't know what to do now, really. There also was two other pressing issues, both harder for me to grasp. One is about a missing point in an ECC implementation. The other one is simply just not clear to me yet. I hope this helps, --Bert P.S. Sorry about not signing this email. This is just an email for this list. -------------- next part -------------- A non-text attachment was scrubbed... Name: cipher-gcm-zero-iv-fallback.demo.md Type: text/markdown Size: 2501 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cipher-gcm-zero-iv-fallback.readme.md Type: text/markdown Size: 5310 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cipher-gcm-zero-iv-fallback.patch Type: text/x-diff Size: 4353 bytes Desc: not available URL: From gniibe at fsij.org Wed Apr 15 07:27:33 2026 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 15 Apr 2026 14:27:33 +0900 Subject: Account request + libgcrypt security finding In-Reply-To: References: <7hftswielxh2fbiatiz2lzqm3kr6f5ueucxsajeqs55govxj3s@7av4jx2eurix> <87zf36ki7q.fsf@jacob.g10code.de> Message-ID: <87eckg6bei.fsf@haruna.fsij.org> Hello, Bert van der Weerd wrote: > This is an issue with the IV/nonce in the (Chacha20 stream cipher and) > GCM encryption mode. The IV/nonce remains zero if set_iv() is not > properly called before: _gcry_cipher_gcm_encrypt(), > _gcry_cipher_gcm_decrypt(), _gcry_cipher_gcm_authenticate(). This is a > known failure mode of these algorithmes, and the proper thing to do is > return GPG_ERR_INV_STATE; Thank you for your argument. I could understand the last point of yours (returning GPG_ERR_INV_STATE). But I, for myself, don't think it's a severe issue of our implementation. Your patch is not good, unfortunately, it's removing important parts under FIPS mode. I know that it's hard to use the crypto API of libgcrypt. Problems around here are a bit larger. If interested, please have a look at: https://dev.gnupg.org/T5870 https://dev.gnupg.org/T4873 and not-yet-applied patch of ntbtls: https://dev.gnupg.org/rTf550b3323c8efd38c79b1daa26821a35ad486cf7 Direct use of set IV API for GCM is considered bad. We tried GCRY_CIPHER_GENIV_METHOD_CONCAT for now. > I attached some AI slob: I'd like to ask you, please, please don't do that. It's too noisy. If possible, please keep it in your blog post or else where. -- From bert at teamspicy.net Wed Apr 15 15:54:53 2026 From: bert at teamspicy.net (Bert van der Weerd) Date: Wed, 15 Apr 2026 13:54:53 +0000 Subject: Continuing with: Account request + libgcrypt security finding Message-ID: Hi NIIBE, list, This is my first message from my other email addres that has a yubikey-backed 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 patch. Okay, I removed all the FIPS related patch content and reformulated the guard statement, this second patch. I'm aware that there are other issues, and am just trying to help, so I'm just 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 return an error. It silently calls _gcry_cipher_gcm_setiv_zero(), which initializes the IV to 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 ? 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 decryptable ? 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 == 0) return GPG_ERR_INV_STATE; And as you say it's not recommended IV practice, but still, it's not completely weird API usage either... I'm thankful for pointing out the relevant tickets for the FIPS related stuff. Best regards, --Bert -------------- next part -------------- A non-text attachment was scrubbed... Name: cipher-gcm-zero-iv-fallback-2.patch Type: text/x-diff Size: 1136 bytes Desc: not available URL: From bert at teamspicy.net Wed Apr 15 21:22:35 2026 From: bert at teamspicy.net (Bert van der Weerd) Date: Wed, 15 Apr 2026 19:22:35 +0000 Subject: new additional patch (removing the #if 0 & TODO block) In-Reply-To: References: Message-ID: Hi Niibe && all, So, I hope this message gets signed. My public key is at: https://keys.openpgp.org/search?q=bert%40teamspicy.net About the rejected part, the FIPS path is implemented the GENIV and that works, but this file contains and old #if 0 & TODO block implemnting it there.. its not there, its in cipher.c instead. So I attach here this little patch to remove that block. Thanks, --Bert -------------- next part -------------- A non-text attachment was scrubbed... Name: cipher-gcm-zero-iv-remove-todo-block.patch Type: text/x-diff Size: 1198 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 887 bytes Desc: not available URL: From wk at gnupg.org Thu Apr 16 10:36:27 2026 From: wk at gnupg.org (Werner Koch) Date: Thu, 16 Apr 2026 10:36:27 +0200 Subject: Continuing with: Account request + libgcrypt security finding In-Reply-To: (Bert van der Weerd via Gcrypt-devel's message of "Wed, 15 Apr 2026 13:54:53 +0000") References: Message-ID: <87v7drb8tw.fsf@jacob.g10code.de> Hi! On Wed, 15 Apr 2026 13:54, Bert van der Weerd said: > In non-FIPS mode, _if_ the caller never invokes set_iv() before > calling gcm_encrypt(), gcm_decrypt(), or gcm_authenticate(), the > library does not return an error. GCM aas well as all other counter modes are pretty fragile and tehre are a lot of conditions which lead to catastrophic failures. So better avoid GCM and use a robust mode like OCB. I do not considere this a bug becuase it is improper use of the algorithms. Right, we may check whether set_iv has been used but it won't be possible to check for nonce re-use - that is the caller's duty. Let us open a feature request to return a GPG_ERR_MISSING_ACTION error if set_iv has not been used. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 284 bytes Desc: not available URL: