From simon at josefsson.org Wed May 1 20:24:25 2024 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 01 May 2024 20:24:25 +0200 Subject: Very first Beta of GnuPG 2.6 available In-Reply-To: <87jzkg8uh7.fsf@jacob.g10code.de> (Werner Koch via Gnupg-devel's message of "Mon, 29 Apr 2024 10:05:08 +0200") References: <87jzkg8uh7.fsf@jacob.g10code.de> Message-ID: <87v83xv19i.fsf@kaka.sjd.se> Werner Koch via Gnupg-devel writes: > Hi! > > Gniibe and me have been working on PQC Support in GnuPG for some time > now. Now we have a first Beta version available. Because we have done > no releases of the supporting libraries yet, a tarball with all sources is > available: > > https://gnupg.org/ftp/gcrypt/snapshots/gnupg/gnupg-w32-2.5.0-beta465_20240426.tar.xz > > https://gnupg.org/ftp/gcrypt/snapshots/gnupg/gnupg-w32-2.5.0-beta465_20240426.tar.xz.sig I had several problems building/running this and eventually became tired of fixing small issues (mostly build environment related) -- is it possible to build from git instead? Which branches were used? Will you support sntrup761 and/or mceliece6688128? I would like to see some alternative to kyber early on. /Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 255 bytes Desc: not available URL: From dgouttegattat at incenp.org Wed May 1 21:57:20 2024 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Wed, 01 May 2024 20:57:20 +0100 Subject: Very first Beta of GnuPG 2.6 available In-Reply-To: <87v83xv19i.fsf@kaka.sjd.se> References: <87jzkg8uh7.fsf@jacob.g10code.de> <87v83xv19i.fsf@kaka.sjd.se> Message-ID: <26403280.1r3eYUQgxm@borealin.local.incenp.org> On Wednesday, 1 May 2024 19:24:25 BST Simon Josefsson via Gnupg-devel wrote: > Werner Koch via Gnupg-devel writes: > I had several problems building/running this and eventually became tired > of fixing small issues (mostly build environment related) FWIW I also ran into a few problems when trying to build the beta. I believe the correct build instruction should have been make -f build-aux/speedo.mk this-native At least that?s what I had to use on my machine. With `native`, Speedo attempted to use the latest *released* versions of Libassuan and Libgcrypt, resulting in GnuPG itself failing to build since it depends on newer versions of those libraries that have not been released yet. With `this-native`, Speedo will use the already unpacked sources provided in the tarball (in PLAY/src). Another problem is that when building bzip2, it would try to install a header in /usr/local, instead of the PLAY root. Not sure why, but I didn?t investigate further. I just removed bzip2 from the list of packages (variable `speedo_spkgs`) and let GnuPG use my system-wide bzip2 instead. Hope this helps. - Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From ben+freesoftware at benfinney.id.au Thu May 2 05:55:47 2024 From: ben+freesoftware at benfinney.id.au (Ben Finney) Date: Thu, 02 May 2024 13:55:47 +1000 Subject: GPGME: What does =?utf-8?B?4oCYMOKAmQ==?= (zero) =?utf-8?Q?=E2=80=98signature=2Esummary=E2=80=99?= value mean? References: <87jzl36nry.fsf@benfinney.id.au> <8734romgfr.fsf@jacob.g10code.de> <87frvn5l66.fsf@benfinney.id.au> Message-ID: <878r0sx3y4.fsf@benfinney.id.au> Ben Finney writes: > Werner Koch via Gnupg-devel writes: > > > Do you have an example? > > Included in this message is a Python program ?verify_test.py?. [?] > > You can see that the ?verify? call succeeds (no error is raised), and > there is a single attached Signature. > > That Signature, though it has a valid timestamp and fingerprint, has ?0? > for all of ?pka_trust?, ?status?, ?summary?, ?validity?, and > ?validity_reason?. Has this helped understand the problem? What more diagnostic information can I provide? I am trying to make use of GPGME (via the Python wrapper) to verify signatures and interpret the result using the documented API. -- \ ?If you always want the latest and greatest, then you have to | `\ buy a new iPod at least once a year.? ?Steve Jobs, MSNBC | _o__) interview 2006-05-25 | Ben Finney From wk at gnupg.org Thu May 2 08:42:44 2024 From: wk at gnupg.org (Werner Koch) Date: Thu, 02 May 2024 08:42:44 +0200 Subject: Specification for Kyber in GnuPG (was: Very first Beta of GnuPG 2.6 available) In-Reply-To: <87jzkg8uh7.fsf@jacob.g10code.de> (Werner Koch via Gnupg-devel's message of "Mon, 29 Apr 2024 10:05:08 +0200") References: <87jzkg8uh7.fsf@jacob.g10code.de> Message-ID: <87y18s67ff.fsf@jacob.g10code.de> Hi! Please find attached a diff towards the LibrePGP specification which describes the new KEM algorithms used for quantum-resistant encryption. Before a new draft is published some minor things need to be fixed but it should nevertheless allow to implement the same thing as we did in GnuPG master. The SHOULD and MAYs in the table of ECC-KEM and ML-KEM are up to discussion. In particular whether a 256 bit or a 384 bit curve should go with ML-KEM-768. Note that in GnuPG we use the term "Kyber" instead of "ML-KEM" because that is easier to remember. The abbreviation is ky768 or ky1024 followed by the ECC curve name with Brainpool curves abbreviated as bp256 et. For example ky1024_cv448 stands for the composite of ML-KEM-1024 with X448. A description on how to add Kyber support to an existing OpenPGP implementation will follow. As long as the crypto primitives are available adding that support is straightforward because existing parser code may partly be re-used and all variants are covered by just one algorithm id. Support for quantum-resistant signature schemes is not not yet available and far less urgent than encryption: The goal is to protect encrypted data at rest (or being wiretapped). Also new signature schemes need more real world experience before they can be taken in use. The migration plan to quantum-resistant encryption is to add new Kyber subkeys so that implementation with support for them can start to use them. If at some point in the future a wide deployment as been achieved, the new gpg option --require-pqc-encryption can be used to force encryption with a quantum-resistant algorithm (i.e. Kyber). Many thanks to Stavros Kousidis, Falko Strenzke, and Aron Wussler for their draft on adding PQC to OpenPGP. The algorithms used by LibgrePGP are the same except for the fixed info. I took the freedom to remove the rationale parts which are not helpful for an implementer and was thus able to make the description more concise. 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: 0001-Describe-the-KEM-algorithms.patch Type: text/x-diff Size: 11877 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From wk at gnupg.org Thu May 2 08:56:45 2024 From: wk at gnupg.org (Werner Koch) Date: Thu, 02 May 2024 08:56:45 +0200 Subject: Very first Beta of GnuPG 2.6 available In-Reply-To: <87v83xv19i.fsf@kaka.sjd.se> (Simon Josefsson via Gnupg-devel's message of "Wed, 01 May 2024 20:24:25 +0200") References: <87jzkg8uh7.fsf@jacob.g10code.de> <87v83xv19i.fsf@kaka.sjd.se> Message-ID: <87ttjg66s2.fsf@jacob.g10code.de> Hi! > I had several problems building/running this and eventually became tired > of fixing small issues (mostly build environment related) -- is it > possible to build from git instead? Which branches were used? Actually it as been taken from Git and I tried it on a separate box without problems. But as Damien mentioned my description was wrong: You need to use the this-native target. You can also build from Gut. You need to use the latest Libgcrypt and gnupg master. Everything else has been released. The speedo things is good because you don't need to mess with an existing gnupg installation. > Will you support sntrup761 and/or mceliece6688128? I would like to see > some alternative to kyber early on. No. We need to avoid algorithm proliferation. That is also why I don't care about PC signatures right now. Thanks for trying to build. 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: 247 bytes Desc: not available URL: From wk at gnupg.org Thu May 2 08:58:27 2024 From: wk at gnupg.org (Werner Koch) Date: Thu, 02 May 2024 08:58:27 +0200 Subject: Very first Beta of GnuPG 2.6 available In-Reply-To: <26403280.1r3eYUQgxm@borealin.local.incenp.org> (Damien Goutte-Gattat via Gnupg-devel's message of "Wed, 01 May 2024 20:57:20 +0100") References: <87jzkg8uh7.fsf@jacob.g10code.de> <87v83xv19i.fsf@kaka.sjd.se> <26403280.1r3eYUQgxm@borealin.local.incenp.org> Message-ID: <87plu466p8.fsf@jacob.g10code.de> On Wed, 1 May 2024 20:57, Damien Goutte-Gattat said: > Another problem is that when building bzip2, it would try to install a > header in /usr/local, instead of the PLAY root. Not sure why, but I It is possible that there is no bzip2-dev package on my test building box. This would explain why it worked for me. I'll investigate. 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: 247 bytes Desc: not available URL: From kloecker at kde.org Thu May 2 09:21:01 2024 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Thu, 02 May 2024 09:21:01 +0200 Subject: GPGME: What does =?UTF-8?B?4oCYMOKAmSAoemVybykg4oCYc2lnbmF0dXJlLnN1bW1hcnnigJk=?= value mean? In-Reply-To: <8734rk68s3.fsf@benfinney.id.au> References: <87jzl36nry.fsf@benfinney.id.au> <12421620.O9o76ZdvQC@daneel> <8734rk68s3.fsf@benfinney.id.au> Message-ID: <4567689.LvFx2qVVIh@daneel> On Mittwoch, 17. April 2024 04:08:12 CEST Ben Finney wrote: > Ingo Kl?cker writes: > > It would be helpful if you also gave us the public key. > > Oh, I had expected a GnuPG client would fetch the key? It's part of the > signed message metadata, so it should be automatically fetched from the > key servers, I'd expect. Only if auto?key?retrieve is enabled. > Regardless, here is the URL to download that public key: > > https://keys.openpgp.org/search?q=517C+F14B+B2F3+98B0+CB35++4855+B8B2+4C06+ > AC12+8405> $ curl https://keys.openpgp.org/vks/v1/by-fingerprint/ 517CF14BB2F398B0CB354855B8B24C06AC128405 | gpg --import gpg: key B8B24C06AC128405: no user ID gpg: Total number processed: 1 gpg doesn't import keys without user ID. I found the key on another keyserver, but when I try to verify the test message Kleopatra tells me: Signature created on Montag, 15. April 2024 01:32:13 CEST With unavailable certificate: ID: 0x6159E0F29E2FA412E0795C73F9B46AAC84420C82 You can search the certificate on a keyserver or import it from a file. I guess the required subkey is missing on the certificate I could import. Searching the certificate 0x6159E0F29E2FA412E0795C73F9B46AAC84420C82 didn't yield any results. > $ gpg --status-fd 2 foo.txt.asc [...] > [GNUPG:] TRUST_UNDEFINED 0 pgp > gpg: WARNING: This key is not certified with a trusted signature! I think this is the important bit. If you look at the code snippet that Werner pasted then you'll see why `sum` isn't changed in this snippet. So, in this case 0 means good signature by an uncertified key. It's up to you to decide what to make of this. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From andrewg at andrewg.com Thu May 2 15:27:27 2024 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 2 May 2024 14:27:27 +0100 Subject: Specification for Kyber in GnuPG (was: Very first Beta of GnuPG 2.6 available) In-Reply-To: <87y18s67ff.fsf@jacob.g10code.de> References: <87jzkg8uh7.fsf@jacob.g10code.de> <87y18s67ff.fsf@jacob.g10code.de> Message-ID: On 2 May 2024, at 07:42, Werner Koch via Gnupg-devel wrote: > +Curve | ML-KEM | ECC-KEM | SHAFunc | Requirement > +---------------:|--------|---------|----------|------------ > +X25519 | 768 | XKem | SHA3-256 | SHOULD > +X448 | 768 | XKem | SHA3-512 | MAY > +X25519 | 1024 | XKem | SHA3-256 | MAY > +X448 | 1024 | XKem | SHA3-512 | SHOULD > +brainpoolP256r1 | 768 | ecdhKem | SHA3-256 | MAY > +brainpoolP384r1 | 768 | ecdhKem | SHA3-512 | SHOULD > +brainpoolP512r1 | 768 | ecdhKem | SHA3-512 | MAY > +brainpoolP512r1 | 1024 | ecdhKem | SHA3-512 | SHOULD > +brainpoolP256r1 | 1024 | ecdhKem | SHA3-256 | MAY > +brainpoolP384r1 | 1024 | ecdhKem | SHA3-512 | MAY > +NIST P-256 | 768 | ecdhKem | SHA3-256 | MAY > +NIST P-384 | 768 | ecdhKem | SHA3-512 | MAY > +NIST P-521 | 768 | ecdhKem | SHA3-512 | MAY > +NIST P-256 | 1024 | ecdhKem | SHA3-256 | MAY > +NIST P-384 | 1024 | ecdhKem | SHA3-512 | MAY > +NIST P-521 | 1024 | ecdhKem | SHA3-512 | MAY This is an enormous set of initial combinations, not all of which make any sense. Why suggest pairing P-256 curves with kyber1024? Do we need all three grades of brainpool and NIST? The four SHOULDs and the corresponding two NIST equivalents are plenty. Once again I?ll beg you to please implement the Kousidis, Strenzke and Wussler spec instead of making trivial changes to their assigned numbers in order to start a pointless and exhausting fight with the IETF WG over ownership of the registry. If we need to allocate four more code points for the brainpool and nist alternatives, what?s the harm? The registry is SPECIFICATION REQUIRED (or will be shortly) and the use of brainpool/nist curves in PQC is not controversial. Why reinvent the wheel? A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From wk at gnupg.org Thu May 2 20:10:34 2024 From: wk at gnupg.org (Werner Koch) Date: Thu, 02 May 2024 20:10:34 +0200 Subject: Specification for Kyber in GnuPG In-Reply-To: (Andrew Gallagher's message of "Thu, 2 May 2024 14:27:27 +0100") References: <87jzkg8uh7.fsf@jacob.g10code.de> <87y18s67ff.fsf@jacob.g10code.de> Message-ID: <875xvw5bl1.fsf@jacob.g10code.de> On Thu, 2 May 2024 14:27, Andrew Gallagher said: > This is an enormous set of initial combinations, not all of which make > any sense. Why suggest pairing P-256 curves with kyber1024? Do we need I already mentipned that this list is up for discussion. Well, except for the SHOULDs which at least need to stay in the list. There are no MUSTs here because PQC algorithms are not mandatory and needed for all applications. Instead implementations should decide what to do. > all three grades of brainpool and NIST? The four SHOULDs and the > corresponding two NIST equivalents are plenty. The Brainpool curves are needed and not subject to discussion. Adding different codepoints for the same algorithm (ECC-KEM + ML-KEM aka Kyber) is a major implementation hassle and diverts from existing OpenPGP protocol behaviour. There is one code point for RSA, one for DSA, one for Elgamal, one for ECDH, one for ECDSA, one for EdDSA, and now one for Kyber. They all have different parameters: either length of parameters or an OID for the curev parameters (which are too large to include in all keys). Thus it is natural to do the same for Kyber. After all we are not TLS with its hunderds of codepoints for algorithms. Adding more codepoints to TLS is also the natural way - for TLS. > Once again I?ll beg you to please implement the Kousidis, Strenzke and > Wussler spec instead of making trivial changes to their assigned The changes might sound trivial but I explained them above. They come from an implementer with a specific and practical knowledge of OpenPGP protocol needs. The actual algorithm and cryptography has not changed because that is not my specific knowledge. That is how OpenPGP has always been extended - let the crypto folks do the math and the coders the implementation. > numbers in order to start a pointless and exhausting fight with the > IETF WG over ownership of the registry. If we need to allocate four We can't wait another 9 years for a simple crypto enhancement. We need a new identifier NOW and need to get it used. After a discussion with the BSI we will temporary add a notification to Kyber keys created according to the current ML-KEM draft. Just in case the NIST decides to do some final changes we can the detect keys created according to the current draft and sort them out. 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: 247 bytes Desc: not available URL: From andrewg at andrewg.com Fri May 3 14:09:29 2024 From: andrewg at andrewg.com (Andrew Gallagher) Date: Fri, 3 May 2024 13:09:29 +0100 Subject: Specification for Kyber in GnuPG In-Reply-To: <875xvw5bl1.fsf@jacob.g10code.de> References: <87jzkg8uh7.fsf@jacob.g10code.de> <87y18s67ff.fsf@jacob.g10code.de> <875xvw5bl1.fsf@jacob.g10code.de> Message-ID: <73FDDD64-F433-4D99-A119-0EFB832EC4DE@andrewg.com> On 2 May 2024, at 19:10, Werner Koch wrote: > > The Brainpool curves are needed and not subject to discussion. Is this a BSI requirement? Are there any other aspects of the list which are not subject to discussion? > Adding > different codepoints for the same algorithm (ECC-KEM + ML-KEM aka Kyber) > is a major implementation hassle Hassle for who though? Supporting both this proposal and the BSI/IETF PQC draft is a major implementation hassle. Supporting an arbitrary combination of algorithms that your underlying crypto library does not expose in its API is a major implementation hassle. Mapping a set of fixed code points to OIDs is a Friday afternoon job by comparison. If you want other implementations to be interoperable with you, then you need to consider their concerns sometimes. (I?m thinking particularly about gopenpgp and hockeypuck here, although it applies to others also). I *want* to stay compatible with GnuPG, but it feels like every concern I raise is being dismissed out of hand. This is not how open standards are supposed to work. > After all we are not TLS with its hunderds of codepoints for algorithms. > Adding more codepoints to TLS is also the natural way - for TLS. The OpenPGP asymmetric algorithms registry currently has 16 assigned code points out of 255, some of which have been reserved for years and never implemented. That?s less than 10% usage in over 30 years of PGP. Even if we?d always had separate code points for the various (recommended) sizes of RSA and the individual curves, we still wouldn't have filled up the unused block between code points 3 and 16. In the unlikely event we?re all still alive when the registry runs out, we can define new packet versions with a two byte algorithm ID area. This is a non issue. I simply don?t understand how a difference of opinion over how to organise a numbering convention is sufficient justification for defining two completely separate standards that differ only in that numbering convention (and the knock-on effects thereof). The only explanation that makes sense is that it is a deliberate strategy to avoid having to discuss algorithm details with other implementations before shipping them in GnuPG. Which is very convenient for GnuPG, but not so convenient for the rest of us. >> Once again I?ll beg you to please implement the Kousidis, Strenzke and >> Wussler spec instead of making trivial changes to their assigned > > The changes might sound trivial but I explained them above. They come > from an implementer with a specific and practical knowledge of OpenPGP > protocol needs. The actual algorithm and cryptography has not changed > because that is not my specific knowledge. That is how OpenPGP has > always been extended - let the crypto folks do the math and the coders > the implementation. Sorry, are you seriously claiming here that the authors of the IETF PQC draft, which include one of the principal developers of gopenpgp, do not have practical knowledge of OpenPGP protocol needs? >> numbers in order to start a pointless and exhausting fight with the >> IETF WG over ownership of the registry. If we need to allocate four > > We can't wait another 9 years for a simple crypto enhancement. We need > a new identifier NOW and need to get it used. On this we agree, but I don?t believe that doing the same work twice helps us achieve it. > After a discussion with > the BSI we will temporary add a notification to Kyber keys created > according to the current ML-KEM draft. Just in case the NIST decides to > do some final changes we can the detect keys created according to the > current draft and sort them out. Is this a GnuPG-specific proposal? It hasn?t been mentioned in any of the calls or emails I?ve been in with the authors of the IETF PQC draft, and the first author of that draft is a BSI employee. I?m seriously worried now that the BSI appear to be funding and/or directing two separate instances of the same project. Is this a conscious decision by the BSI or just a failure of communication between departments? A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From meep at meeps.dev Sat May 4 15:55:40 2024 From: meep at meeps.dev (meep) Date: Sat, 04 May 2024 15:55:40 +0200 Subject: Possible bug in GPGME Python Message-ID: <1c2471ada3be762ea02f8e4fa8cc601c7860e6be.camel@meeps.dev> Good day. I would like to report what I believe to be an oversight in the Python wrapper of GPGME. I am reporting it here as it is a minor thing, and account creation is disabled on the bug tracker at dev.gnupg.org. I would also prefer not to make an account if possible. In the interact(...) function of the Context class on line 1089 in core.py it is checked whether a key is actually passed in to the function: if key is None: raise ValueError("First argument cannot be None") Which is fine when editing a key, but when interacting with a smart card (setting the flag INTERACT_CARD) - for example to generate a key on it - there is not necessarily a key to be edited. In interact_start(...) on line 131 of edit.c the presence of the key is only checked if card_edit isn't set: if ((card_edit == 0 && !key) || !fnc || !out) return gpg_error (GPG_ERR_INV_VALUE); This functions is called by gpgme_op_interact(...) in the same file which is called from Python in the aforementioned interact(...) function. Thus I believe that the intended behavior in Python would be to mirror the C code and only check whether the key is None if INTERACT_CARD is not set. Please correct me if I am wrong and point me in the right direction. Thanks in advance - meep -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 854 bytes Desc: This is a digitally signed message part URL: From ben+freesoftware at benfinney.id.au Sun May 5 08:47:03 2024 From: ben+freesoftware at benfinney.id.au (Ben Finney) Date: Sun, 05 May 2024 16:47:03 +1000 Subject: GPGME: What does =?utf-8?B?4oCYMOKAmQ==?= (zero) =?utf-8?Q?=E2=80=98signature=2Esummary=E2=80=99?= value mean? References: <87jzl36nry.fsf@benfinney.id.au> <12421620.O9o76ZdvQC@daneel> <8734rk68s3.fsf@benfinney.id.au> <4567689.LvFx2qVVIh@daneel> Message-ID: <87cyq021so.fsf@benfinney.id.au> Ingo Kl?cker writes: > On Mittwoch, 17. April 2024 04:08:12 CEST Ben Finney wrote: > > $ gpg --status-fd 2 foo.txt.asc > [...] > > [GNUPG:] TRUST_UNDEFINED 0 pgp > > gpg: WARNING: This key is not certified with a trusted signature! > > I think this is the important bit. If you look at the code snippet > that Werner pasted then you'll see why `sum` isn't changed in this > snippet. So, in this case 0 means good signature by an uncertified > key. If that's the meaning, surely this should be unambiguously encoded with the Signature result attributes? Rather than "everything is zero", which (as you point out) just seems to be some default when the conditions were not as expected. > It's up to you to decide what to make of this. I make of this, that GPGME has a bug: It does not handle this normal condition well. The message emitted shows GnuPG understands what happened; but the result object from the GPGME API does not communicate that information unambiguously. So, please consider this thread a bug report to that effect. How do I formalise this so it can be addressed as such? -- \ ?Most people, I think, don't even know what a rootkit is, so | `\ why should they care about it?? ?Thomas Hesse, Sony BMG, 2006 | _o__) | Ben Finney From wk at gnupg.org Mon May 6 13:40:16 2024 From: wk at gnupg.org (Werner Koch) Date: Mon, 06 May 2024 13:40:16 +0200 Subject: Specification for Kyber in GnuPG In-Reply-To: <73FDDD64-F433-4D99-A119-0EFB832EC4DE@andrewg.com> (Andrew Gallagher via Gnupg-devel's message of "Fri, 3 May 2024 13:09:29 +0100") References: <87jzkg8uh7.fsf@jacob.g10code.de> <87y18s67ff.fsf@jacob.g10code.de> <875xvw5bl1.fsf@jacob.g10code.de> <73FDDD64-F433-4D99-A119-0EFB832EC4DE@andrewg.com> Message-ID: <87v83r2mov.fsf@jacob.g10code.de> Hi! Sorry Andrew, I won't follow up on your mail. I gave a rationale for the changes in replies here and on the librepgp-discuss list [1]. I also posted a new draft for an updated Librepgp draft today [2]. If you have any problems implementing any of this in your OpenPGP implementation, please let us know and we see how we can help in coding. Shalom-Salam, Werner ps. Let me remark that this is not the IETF OpenPGP WG which unfortunately had been hijacked in 2022 by a small group of people trying to undermine the stability of the OpenPGP protocol with their irresponsible changes (aka crypto-refresh). They reused the term OpenPGP for something very different and thus we had to established the term LibrePGP for a responsible update to the crypto algorithms used in OpenPGP. [1] https://lists.gnupg.org/pipermail/librepgp-discuss/2024/000043.html [2] https://lists.gnupg.org/pipermail/librepgp-discuss/2024/000068.html -- 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: 247 bytes Desc: not available URL: From wk at gnupg.org Mon May 6 13:51:48 2024 From: wk at gnupg.org (Werner Koch) Date: Mon, 06 May 2024 13:51:48 +0200 Subject: GPGME: What does =?utf-8?B?4oCYMOKAmQ==?= (zero) =?utf-8?Q?=E2=80=98signature=2Esummary=E2=80=99?= value mean? In-Reply-To: <87cyq021so.fsf@benfinney.id.au> (Ben Finney's message of "Sun, 05 May 2024 16:47:03 +1000") References: <87jzl36nry.fsf@benfinney.id.au> <12421620.O9o76ZdvQC@daneel> <8734rk68s3.fsf@benfinney.id.au> <4567689.LvFx2qVVIh@daneel> <87cyq021so.fsf@benfinney.id.au> Message-ID: <87r0ef2m5n.fsf@jacob.g10code.de> On Sun, 5 May 2024 16:47, Ben Finney said: > the Signature result attributes? Rather than "everything is zero", which > (as you point out) just seems to be some default when the conditions > were not as expected. Let's have a look at the docs: ?gpgme_sigsum_t summary? This is a bit vector giving a summary of the signature status. It provides an easy interface to a defined semantic of the signature status. Checking just one bit is sufficient to see whether a signature is valid without any restrictions. This means that you can check for GPGME_SIGSUM_VALID like this: if ((sig.summary & GPGME_SIGSUM_VALID)) { ..do stuff if valid.. } else { ..do stuff if not fully valid.. } VALID is not set and this is the basic informaion you need. After all this is a summary and does not give deatils informaion on the reason why a signature is not valid. The whole point here is easily see whether you can accept a signature. There are other flags which allow you to further investigate thinsg. For example: ?GPGME_SIGSUM_GREEN? The signature is good but one might want to display some extra information. Check the other bits. Note the "might". It is not required as per the policy implemented currently be GPGME. Just go ahead and display the signature with a green frame or similar. ?GPGME_SIGSUM_RED? The signature is bad. It might be useful to check other bits and display more information, i.e., a revoked certificate might not render a signature invalid when the message was received prior to the cause for the revocation. Same here - the signature is definitely bad. Display with a red frame. There are no other colors but some MUAs will use a yellow or uncolored frame if they don't see the green or red bit. This is a UI decision which for example depends on whether you expect signed messages or not. > I make of this, that GPGME has a bug: It does not handle this normal > condition well. The message emitted shows GnuPG understands what > happened; but the result object from the GPGME API does not communicate GPGME policy is not to set the green flag in this case. If you want something elease check out the detailed results and act upon them. > So, please consider this thread a bug report to that effect. How do I > formalise this so it can be addressed as such? What should we do? Add another bit flag "other_problem"? 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: 247 bytes Desc: not available URL: From simon at josefsson.org Mon May 6 14:49:46 2024 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 06 May 2024 14:49:46 +0200 Subject: Specification for Kyber in GnuPG In-Reply-To: <87y18s67ff.fsf@jacob.g10code.de> (Werner Koch via Gnupg-devel's message of "Thu, 02 May 2024 08:42:44 +0200") References: <87jzkg8uh7.fsf@jacob.g10code.de> <87y18s67ff.fsf@jacob.g10code.de> Message-ID: <8734qvt89h.fsf@kaka.sjd.se> Werner Koch via Gnupg-devel writes: > + - Prepare fixedInfo as specified above > > - Compute KEK := multiKeyCombine(eccKeyShare, eccCipherText, > mlkemKeyShare, mlkemCipherText, fixedInfo, 256) as defined in > - Section [](#KEM-Key-Combiner). > + Section [](#kem-key-combiner). Where is multiKeyCombine defined? I can't find it in draft-koch-librepgp-00 nor in your patch. I'm happy you included the ciphertext in the combiner, but I'm trying to work out how strong the binding to the Kyber public key material this has. Is the source code of the file this patch is against public? It is easier to review a patched version of an entire document than a patch against an unknown file. /Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 255 bytes Desc: not available URL: From wk at gnupg.org Mon May 6 14:59:08 2024 From: wk at gnupg.org (Werner Koch) Date: Mon, 06 May 2024 14:59:08 +0200 Subject: Specification for Kyber in GnuPG In-Reply-To: <8734qvt89h.fsf@kaka.sjd.se> (Simon Josefsson via Gnupg-devel's message of "Mon, 06 May 2024 14:49:46 +0200") References: <87jzkg8uh7.fsf@jacob.g10code.de> <87y18s67ff.fsf@jacob.g10code.de> <8734qvt89h.fsf@kaka.sjd.se> Message-ID: <87edaf2j1f.fsf@jacob.g10code.de> On Mon, 6 May 2024 14:49, Simon Josefsson said: > Werner Koch via Gnupg-devel writes: > >> + - Prepare fixedInfo as specified above >> >> - Compute KEK := multiKeyCombine(eccKeyShare, eccCipherText, >> mlkemKeyShare, mlkemCipherText, fixedInfo, 256) as defined in >> - Section [](#KEM-Key-Combiner). >> + Section [](#kem-key-combiner). > > Where is multiKeyCombine defined? I can't find it in Line 6133 in the draft I posted today to librepgp-discuss https://lists.gnupg.org/pipermail/librepgp-discuss/2024/000068.html > draft-koch-librepgp-00 nor in your patch. I'm happy you included the > ciphertext in the combiner, but I'm trying to work out how strong the > binding to the Kyber public key material this has. That is the same as in draft-wussler-openpgp-pqc-03.txt. > Is the source code of the file this patch is against public? It is > easier to review a patched version of an entire document than a patch > against an unknown file. git://git.gnupg.org/people/wk/rfc4880bis.git and take rfc4880bis.md 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: 247 bytes Desc: not available URL: From heiko.schaefer at posteo.de Mon May 6 14:37:55 2024 From: heiko.schaefer at posteo.de (=?UTF-8?Q?Heiko_Sch=C3=A4fer?=) Date: Mon, 6 May 2024 12:37:55 +0000 Subject: Specification for Kyber in GnuPG In-Reply-To: <87v83r2mov.fsf@jacob.g10code.de> References: <87jzkg8uh7.fsf@jacob.g10code.de> <87y18s67ff.fsf@jacob.g10code.de> <875xvw5bl1.fsf@jacob.g10code.de> <73FDDD64-F433-4D99-A119-0EFB832EC4DE@andrewg.com> <87v83r2mov.fsf@jacob.g10code.de> Message-ID: On 5/6/24 1:40 PM, Werner Koch via Gnupg-devel wrote: > ps. Let me remark that this is not the IETF OpenPGP WG which > unfortunately had been hijacked in 2022 by a small group of people > trying to undermine the stability of the OpenPGP protocol with their > irresponsible changes (aka crypto-refresh). All of this is a very odd thing to write, from my perspective. I'd like to point out for the record that this so-called "small group" included very active participation by Proton AG, who are the main implementers of both OpenPGP.js and GopenPGP (and who deploy one of the bigger OpenPGP-based products on the planet). Also: "trying to undermine". Really? Extraordinary claims require extraordinary evidence. I'd love to see the evidence for that claim. You seem to be saying that you believe a group of people has colluded to spend very many person years in the IETF process, just to make the OpenPGP standard worse? That does not sound like a very plausible assertion to me. Maybe what you are actually trying to say is that there is a technical difference of opinion regarding the future direction of the standard. And that you believe your judgment for a good future direction is more valid than that of some other group of people. Which ... sure, it's fair if that is your subjective assessment of the situation. However, it almost appears to me as though you are attempting to underhandedly smear the parties on the other side of that difference of opinion. Which, to my mind, wouldn't be a very good look. From KaiE at kuix.de Mon May 6 15:12:31 2024 From: KaiE at kuix.de (Kai Engert) Date: Mon, 6 May 2024 15:12:31 +0200 Subject: Specification for Kyber in GnuPG In-Reply-To: <8734qvt89h.fsf@kaka.sjd.se> References: <87jzkg8uh7.fsf@jacob.g10code.de> <87y18s67ff.fsf@jacob.g10code.de> <8734qvt89h.fsf@kaka.sjd.se> Message-ID: <055ec4c0-f230-417f-937c-ab5c135e4494@kuix.de> On 06.05.24 14:49, Simon Josefsson via Gnupg-devel wrote: > Is the source code of the file this patch is against public? It is > easier to review a patched version of an entire document than a patch > against an unknown file. The patch from Werner's email applies on this revision: https://git.gnupg.org/cgi-bin/gitweb.cgi?p=people/wk/rfc4880bis.git;a=tree of file rfc4880bis which can be found here: https://git.gnupg.org/cgi-bin/gitweb.cgi?p=people/wk/rfc4880bis.git;a=tree Kai From simon at josefsson.org Mon May 6 17:06:32 2024 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 06 May 2024 17:06:32 +0200 Subject: Specification for Kyber in GnuPG In-Reply-To: <87edaf2j1f.fsf@jacob.g10code.de> (Werner Koch via Gnupg-devel's message of "Mon, 06 May 2024 14:59:08 +0200") References: <87jzkg8uh7.fsf@jacob.g10code.de> <87y18s67ff.fsf@jacob.g10code.de> <8734qvt89h.fsf@kaka.sjd.se> <87edaf2j1f.fsf@jacob.g10code.de> Message-ID: <87ttjbrnd3.fsf@kaka.sjd.se> Werner Koch via Gnupg-devel writes: > On Mon, 6 May 2024 14:49, Simon Josefsson said: >> Werner Koch via Gnupg-devel writes: >> >>> + - Prepare fixedInfo as specified above >>> >>> - Compute KEK := multiKeyCombine(eccKeyShare, eccCipherText, >>> mlkemKeyShare, mlkemCipherText, fixedInfo, 256) as defined in >>> - Section [](#KEM-Key-Combiner). >>> + Section [](#kem-key-combiner). >> >> Where is multiKeyCombine defined? I can't find it in > > Line 6133 in the draft I posted today to librepgp-discuss > https://lists.gnupg.org/pipermail/librepgp-discuss/2024/000068.html Thank you! As far as I can tell this doesn't strongly bind eccPublicKey and mlkemPublicKey to the KEK which may complicate a security proof. /Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 255 bytes Desc: not available URL: From wk at gnupg.org Mon May 6 17:09:24 2024 From: wk at gnupg.org (Werner Koch) Date: Mon, 06 May 2024 17:09:24 +0200 Subject: Specification for Kyber in GnuPG In-Reply-To: ("Heiko =?utf-8?Q?Sch=C3=A4fer?= via Gnupg-devel"'s message of "Mon, 6 May 2024 12:37:55 +0000") References: <87jzkg8uh7.fsf@jacob.g10code.de> <87y18s67ff.fsf@jacob.g10code.de> <875xvw5bl1.fsf@jacob.g10code.de> <73FDDD64-F433-4D99-A119-0EFB832EC4DE@andrewg.com> <87v83r2mov.fsf@jacob.g10code.de> Message-ID: <875xvr2d0b.fsf@jacob.g10code.de> On Mon, 6 May 2024 12:37, Heiko Sch?fer said: > to spend very many person years in the IETF process, just to make the > OpenPGP standard worse? That does not sound like a very plausible It took only a few month to destroy all work done in the 6 years before. See our timeline over at http://librepgp.org/#timeline . In short: I started the update of OpenPGP in 2015, the WG agreed 2018 on everything in 4880bis, a few people started some bike shedding which required another 3 years to solve. Right after that in fall 2021, a small group started to entirely rework everything. In fact, Proton (who don't really do E2E) introduced GCM as an additional encryption mode and thus large changes to the protocol were required. Nobody except them needs or wants that brittle GCM anyway. All comments from the major implementers (GnuPG and RNP) were either ignored or as insubstantial rejected. Pretty please: Stop discussing this here. We spent way to much time with that IETF group's behaviour. That group does not consider working and deployed code as important but prefers a dev-ops strategy. 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: 247 bytes Desc: not available URL: From wk at gnupg.org Mon May 6 17:13:24 2024 From: wk at gnupg.org (Werner Koch) Date: Mon, 06 May 2024 17:13:24 +0200 Subject: Specification for Kyber in GnuPG In-Reply-To: <87ttjbrnd3.fsf@kaka.sjd.se> (Simon Josefsson via Gnupg-devel's message of "Mon, 06 May 2024 17:06:32 +0200") References: <87jzkg8uh7.fsf@jacob.g10code.de> <87y18s67ff.fsf@jacob.g10code.de> <8734qvt89h.fsf@kaka.sjd.se> <87edaf2j1f.fsf@jacob.g10code.de> <87ttjbrnd3.fsf@kaka.sjd.se> Message-ID: <871q6f2ctn.fsf@jacob.g10code.de> On Mon, 6 May 2024 17:06, Simon Josefsson said: > Thank you! As far as I can tell this doesn't strongly bind eccPublicKey > and mlkemPublicKey to the KEK which may complicate a security proof. Can you give a reason for this? The fingerprint binds the two public keys and it is an input to the key combiner. 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: 247 bytes Desc: not available URL: From simon at josefsson.org Mon May 6 17:24:06 2024 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 06 May 2024 17:24:06 +0200 Subject: Specification for Kyber in GnuPG In-Reply-To: <871q6f2ctn.fsf@jacob.g10code.de> (Werner Koch's message of "Mon, 06 May 2024 17:13:24 +0200") References: <87jzkg8uh7.fsf@jacob.g10code.de> <87y18s67ff.fsf@jacob.g10code.de> <8734qvt89h.fsf@kaka.sjd.se> <87edaf2j1f.fsf@jacob.g10code.de> <87ttjbrnd3.fsf@kaka.sjd.se> <871q6f2ctn.fsf@jacob.g10code.de> Message-ID: <87pltzrmjt.fsf@kaka.sjd.se> Werner Koch writes: > On Mon, 6 May 2024 17:06, Simon Josefsson said: > >> Thank you! As far as I can tell this doesn't strongly bind eccPublicKey >> and mlkemPublicKey to the KEK which may complicate a security proof. > > Can you give a reason for this? The fingerprint binds the two public > keys and it is an input to the key combiner. I haven't chaised the entire chain -- does it bind to the master key fingerprint only, or to the Ecc+Kyber subkey too? Including the public key in the KEK binding has been discussed before, some references: https://mailarchive.ietf.org/arch/msg/cfrg/84TUdtD0w12qFSNPpdV5ArS4-IE/ I'm not saying it is critical for security for the entire ECC+Kyber in LibrePGP (I can't fit all of it in my head), but it makes it easier to reason about security properties of the combiner on its own. /Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 255 bytes Desc: not available URL: From dave at sleepmap.de Mon May 6 21:17:01 2024 From: dave at sleepmap.de (David Runge) Date: Mon, 6 May 2024 21:17:01 +0200 Subject: Specification for Kyber in GnuPG In-Reply-To: <875xvr2d0b.fsf@jacob.g10code.de> References: <87jzkg8uh7.fsf@jacob.g10code.de> <87y18s67ff.fsf@jacob.g10code.de> <875xvw5bl1.fsf@jacob.g10code.de> <73FDDD64-F433-4D99-A119-0EFB832EC4DE@andrewg.com> <87v83r2mov.fsf@jacob.g10code.de> <875xvr2d0b.fsf@jacob.g10code.de> Message-ID: On 2024-05-06 17:09:24 (+0200), Werner Koch via Gnupg-devel wrote: > Pretty please: Stop discussing this here. Yet you are the one that keeps bringing this topic up over and over again. Have you considered to stop doing so? That way you would not have to complain that someone is asking you for actual facts for your claims. And by facts I do not mean a marketing website full of inaccurate material such as the one for LibrePGP. I am not interested in your personal vendetta with your ex-employees (now Sequoia-GPG), and I can not imagine anyone else on this list is. I had hoped we were here to collaborate on technical matters, but it doesn't seem that you are willing or able to do that at all. > We spent way to much time with that IETF group's behaviour. It's ironic, I keep thinking about how we all have to deal with yours, and it saddens me that you are apparently unable to let your grudges go. Quite frankly, this mailing list has become unbearable to read due to your spiteful tirades, condescencion towards others and sheer unwillingness to collaborate. I don't think there is much to gain here for anyone anymore that isn't aligned with what you dictate. You are clearly no longer interested in a healthy OpenPGP ecosystem. Hence, this is my last message to this list. Bye -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From wk at gnupg.org Tue May 7 09:26:01 2024 From: wk at gnupg.org (Werner Koch) Date: Tue, 07 May 2024 09:26:01 +0200 Subject: Specification for Kyber in GnuPG In-Reply-To: <87pltzrmjt.fsf@kaka.sjd.se> (Simon Josefsson via Gnupg-devel's message of "Mon, 06 May 2024 17:24:06 +0200") References: <87jzkg8uh7.fsf@jacob.g10code.de> <87y18s67ff.fsf@jacob.g10code.de> <8734qvt89h.fsf@kaka.sjd.se> <87edaf2j1f.fsf@jacob.g10code.de> <87ttjbrnd3.fsf@kaka.sjd.se> <871q6f2ctn.fsf@jacob.g10code.de> <87pltzrmjt.fsf@kaka.sjd.se> Message-ID: <87seyu13sm.fsf@jacob.g10code.de> On Mon, 6 May 2024 17:24, Simon Josefsson said: > I haven't chaised the entire chain -- does it bind to the master key > fingerprint only, or to the Ecc+Kyber subkey too? You mean the primary key? No, it does not because that is not intended by OpenPGP. Doing so would not allow to move a subkey to another master key. > Including the public key in the KEK binding has been discussed before, > some references: Only taking the algorithm id is good iff there is one algorithm id per ECC+ML-KEM combination. This is not the case here and thus we need to adjust for it. Frankly, keeping the algo id is superfluous as it it also part of the fingerprint but it does not harm either. The other choice, would be to include the entire public key as in an early draft, but the fingerprint is easier to describe. 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: 247 bytes Desc: not available URL: From KaiE at kuix.de Wed May 8 00:32:19 2024 From: KaiE at kuix.de (Kai Engert) Date: Wed, 8 May 2024 00:32:19 +0200 Subject: Specification for Kyber in GnuPG In-Reply-To: <87y18s67ff.fsf@jacob.g10code.de> References: <87jzkg8uh7.fsf@jacob.g10code.de> <87y18s67ff.fsf@jacob.g10code.de> Message-ID: <2f3ac45e-97c2-46a7-8d37-bc7eac45592a@kuix.de> On 02.05.24 08:42, Werner Koch via Gnupg-devel wrote: > Many thanks to Stavros Kousidis, Falko Strenzke, and Aron Wussler for > their draft on adding PQC to OpenPGP. The algorithms used by LibgrePGP > are the same except for the fixed info. I took the freedom to remove > the rationale parts which are not helpful for an implementer and was > thus able to make the description more concise. Hi Werner, is my understanding correct, LibrePGP reuses most of the PQC specification from draft-ietf-openpgp-pqc, and your only concerns are about the algorithm IDs and the fixed info? If that's correct, I think it's exciting that your views are so close to each other! I wonder if the authors of draft-ietf-openpgp-pqc might be willing to accept these changes, for the sake of a common specification. Would you be open to a shared specification for the PQC subkey format? Furthermore, as I understand it, the v5 key format and the v6 key format are very close to each other (thanks a lot to Andrew Gallagher for enlightening me about this detail). I wonder if we could find a way to introduce the specification of a v5 format subkey (only) into an IETF specification, to allow the draft-ietf-openpgp-pqc specification to use it. Actually, I think it would be better if there was a common specification, agreed to by both the LibrePGP and IETF groups. How could such a common specification be defined? Do you have ideas or suggestions? I'm dreaming here, but I think it would be great to see a base specification, that extracts the common denominator of draft-librepgp and crypto-refresh, and which could be extended to contain the v5 subkey format. Then, draft-librepgp (and ideally crypto-refresh) could potentially be rewritten to be incremental specifications on top of the common denominator spec. Thanks Kai From steffen at sdaoden.eu Wed May 8 02:31:34 2024 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 08 May 2024 02:31:34 +0200 Subject: Fwd: Re: Specification for Kyber in GnuPG Message-ID: <20240508003134.f3KdR3In@steffen%sdaoden.eu> Unfortunately i got : host ellsberg.gnupg.com[176.9.119.14] said: 550 [SPF] 217.144.132.164 is not allowed to send mail from sdaoden.eu. (in reply to MAIL FROM command) which seems a bit square given that i DKIM sign my messages now, and the SPF cannot have anything else but ~all because i speak to people behind forwarders which do not use SRS rewriting, and what is a SPF record of ~all worth, thus i had thrown it away. (Worked for almost two months without problems.) --- Forwarded from Steffen Nurpmeso --- Date: Wed, 08 May 2024 02:13:53 +0200 Author: Steffen Nurpmeso From: Steffen Nurpmeso To: Kai Engert via Gnupg-devel Subject: Re: Specification for Kyber in GnuPG Message-ID: <20240508001353.Kz1gyZ6F at steffen%sdaoden.eu> Mail-Followup-To: Kai Engert via Gnupg-devel OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt Kai Engert via Gnupg-devel wrote in <2f3ac45e-97c2-46a7-8d37-bc7eac45592a at kuix.de>: |On 02.05.24 08:42, Werner Koch via Gnupg-devel wrote: |> Many thanks to Stavros Kousidis, Falko Strenzke, and Aron Wussler for |> their draft on adding PQC to OpenPGP. The algorithms used by LibgrePGP |> are the same except for the fixed info. I took the freedom to remove |> the rationale parts which are not helpful for an implementer and was |> thus able to make the description more concise. | |Hi Werner, | |is my understanding correct, LibrePGP reuses most of the PQC |specification from draft-ietf-openpgp-pqc, and your only concerns are |about the algorithm IDs and the fixed info? | |If that's correct, I think it's exciting that your views are so close to |each other! | |I wonder if the authors of draft-ietf-openpgp-pqc might be willing to |accept these changes, for the sake of a common specification. | |Would you be open to a shared specification for the PQC subkey format? | |Furthermore, as I understand it, the v5 key format and the v6 key format |are very close to each other (thanks a lot to Andrew Gallagher for |enlightening me about this detail). | |I wonder if we could find a way to introduce the specification of a v5 |format subkey (only) into an IETF specification, to allow the |draft-ietf-openpgp-pqc specification to use it. | |Actually, I think it would be better if there was a common |specification, agreed to by both the LibrePGP and IETF groups. How could |such a common specification be defined? Do you have ideas or suggestions? | |I'm dreaming here, but I think it would be great to see a base I wholeheartly agree and would think that nearby a hundred percent of all persons using OpenPGP of whatever kind do, too. (And would be surprised if not.) |specification, that extracts the common denominator of draft-librepgp |and crypto-refresh, and which could be extended to contain the v5 subkey |format. Then, draft-librepgp (and ideally crypto-refresh) could |potentially be rewritten to be incremental specifications on top of the |common denominator spec. --End of <2f3ac45e-97c2-46a7-8d37-bc7eac45592a at kuix.de> ... -- End forward <20240508001353.Kz1gyZ6F at steffen%sdaoden.eu> --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From wk at gnupg.org Wed May 8 11:33:57 2024 From: wk at gnupg.org (Werner Koch) Date: Wed, 08 May 2024 11:33:57 +0200 Subject: Specification for Kyber in GnuPG In-Reply-To: <2f3ac45e-97c2-46a7-8d37-bc7eac45592a@kuix.de> (Kai Engert via Gnupg-devel's message of "Wed, 8 May 2024 00:32:19 +0200") References: <87jzkg8uh7.fsf@jacob.g10code.de> <87y18s67ff.fsf@jacob.g10code.de> <2f3ac45e-97c2-46a7-8d37-bc7eac45592a@kuix.de> Message-ID: <87a5l0zlyy.fsf@jacob.g10code.de> Hi Kai, On Wed, 8 May 2024 00:32, Kai Engert said: > Furthermore, as I understand it, the v5 key format and the v6 key > format are very close to each other (thanks a lot to Andrew Gallagher It is not alone about the key packet version (which also flags some other behaviour) but on the algorithm specific fields for the public key system. For the the same public key algorithm (e.g. EdDSA) they defined new algorithms named after the curve (27 = Ed25519 and 28 = Ed448) and deprecated the long established algorithm 22 (now called EdDSALegacy). The obvious intention is to merge the parameters of the algorithm into the algorithm id. In their PQC draft they did the same and ended up with a bunch of new algorithm ids for just 3 new algorithms. Merging algorithms and their parameters into one algorithm id is the way it is done in SSL/TLS but it is not the way it is done in PGP/OpenPGP. Salam-Shalom, Werner p.s. We should eventually face the fact that crypto-refresh has ?hijacked? the term OpenPGP for an entire new protocol. This is why I started to use ?*PGP? or ?LibrePGP?. After 25 years of popularizing the term ?OpenPGP? over of GPG or PGP that is not easy ;-) -- 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: 247 bytes Desc: not available URL: From KaiE at kuix.de Sun May 12 16:49:34 2024 From: KaiE at kuix.de (Kai Engert) Date: Sun, 12 May 2024 16:49:34 +0200 Subject: Specification for Kyber in GnuPG In-Reply-To: <87a5l0zlyy.fsf@jacob.g10code.de> References: <87jzkg8uh7.fsf@jacob.g10code.de> <87y18s67ff.fsf@jacob.g10code.de> <2f3ac45e-97c2-46a7-8d37-bc7eac45592a@kuix.de> <87a5l0zlyy.fsf@jacob.g10code.de> Message-ID: <27e37d7d-c09e-45f4-adcc-beac94f863d0@kuix.de> Hi Werner, I understand you have strong opinions what's better, but I think the overall goal to protect users has the highest priority. I'd consider the encoding strategy of transport metadata, like the algorithm identifier or parameters, as a rather unimportant detail that shouldn't justify a schism. If more users and implementations can share a single interoperable specification, the overall protection of users will be better, because it increases the chance that fallbacks to weaker, classic algorithms is unnecessary. I would kindly ask for more willingness to compromise on the protocol level, for the sake of protecting users. I recently saw a political cartoon, which reminded me of the term "Divide and Conquer". I don't know if there is any actor who's actively playing that political game and is sowing discord, in order to weaking the OpenPGP protocol. But if someone is, we shouldn't let them win. Kai From jcb62281 at gmail.com Mon May 13 03:18:13 2024 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Sun, 12 May 2024 20:18:13 -0500 Subject: Specification for Kyber in GnuPG In-Reply-To: <27e37d7d-c09e-45f4-adcc-beac94f863d0@kuix.de> References: <87jzkg8uh7.fsf@jacob.g10code.de> <87y18s67ff.fsf@jacob.g10code.de> <2f3ac45e-97c2-46a7-8d37-bc7eac45592a@kuix.de> <87a5l0zlyy.fsf@jacob.g10code.de> <27e37d7d-c09e-45f4-adcc-beac94f863d0@kuix.de> Message-ID: <66416A55.7040505@gmail.com> Kai Engert via Gnupg-devel wrote: > [...] > > I recently saw a political cartoon, which reminded me of the term > "Divide and Conquer". > > I don't know if there is any actor who's actively playing that > political game and is sowing discord, in order to weaking the OpenPGP > protocol. But if someone is, we shouldn't let them win. Observing the recent discussion on these mailing lists, and assuming that all comments (especially those about the way OpenPGP has previously handled parameterized algorithms) are accurate and truthful, it appears to me that the culpable parties are probably *not* on this mailing list. In other words, OpenPGP algorithm IDs should refer to algorithm types (RSA, DSA, EC-RSA, McEliece, Kyber, etc.) with details (key length, curve parameters, etc.) included in type-specific fields in the key packets. The other side of this debate is attempting to treat OpenPGP algorithm IDs like TLS ciphersuite IDs, which attach all of the details to each codepoint. If someone is sowing discord, I presently believe that it is not the GPG maintainers. If someone is trying to weaken the OpenPGP protocol, I believe it to be the parties pushing for less flexibility, where OpenPGP has historically allowed wide flexibility. -- Jacob From KaiE at kuix.de Mon May 13 06:53:43 2024 From: KaiE at kuix.de (Kai Engert) Date: Mon, 13 May 2024 06:53:43 +0200 Subject: Specification for Kyber in GnuPG In-Reply-To: <66416A55.7040505@gmail.com> References: <87jzkg8uh7.fsf@jacob.g10code.de> <87y18s67ff.fsf@jacob.g10code.de> <2f3ac45e-97c2-46a7-8d37-bc7eac45592a@kuix.de> <87a5l0zlyy.fsf@jacob.g10code.de> <27e37d7d-c09e-45f4-adcc-beac94f863d0@kuix.de> <66416A55.7040505@gmail.com> Message-ID: <22f20d87-2435-4f59-a45d-a73a24f7cb1a@kuix.de> On 13.05.24 03:18, Jacob Bachmeyer wrote: > The other side of this debate is attempting to treat > OpenPGP algorithm IDs like TLS ciphersuite IDs, which attach all of the > details to each codepoint. > > If someone is sowing discord, I presently believe that it is not the GPG > maintainers.? If someone is trying to weaken the OpenPGP protocol, I > believe it to be the parties pushing for less flexibility, where OpenPGP > has historically allowed wide flexibility. In my understanding, the others argue that being less flexible is a benefit. I cannot judge who's right. My point is, an attempt should be made to negotiate, rather than insisting on one approach being better. It doesn't seem that important. For example, if the GnuPG developers said, that this detail is really important to them, and that it is the only remaining disagreement regarding the use of PQC with v4 primary keys, then the GnuPG developers could reach out of the others, and suggest to change this detail in order to reach a common specification. That's what I suggest to do. Thanks, Kai From andrewg at andrewg.com Mon May 13 11:41:31 2024 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 13 May 2024 10:41:31 +0100 Subject: Specification for Kyber in GnuPG In-Reply-To: <66416A55.7040505@gmail.com> References: <87jzkg8uh7.fsf@jacob.g10code.de> <87y18s67ff.fsf@jacob.g10code.de> <2f3ac45e-97c2-46a7-8d37-bc7eac45592a@kuix.de> <87a5l0zlyy.fsf@jacob.g10code.de> <27e37d7d-c09e-45f4-adcc-beac94f863d0@kuix.de> <66416A55.7040505@gmail.com> Message-ID: On 13 May 2024, at 02:18, Jacob Bachmeyer via Gnupg-devel wrote: > > it appears to me that the culpable parties are probably *not* on this mailing list. In other words, OpenPGP algorithm IDs should refer to algorithm types (RSA, DSA, EC-RSA, McEliece, Kyber, etc.) with details (key length, curve parameters, etc.) included in type-specific fields in the key packets. The other side of this debate is attempting to treat OpenPGP algorithm IDs like TLS ciphersuite IDs, which attach all of the details to each codepoint. OpenPGP algorithm IDs have historically referred to broad algorithm types. I think the crucial part of this disagreement is whether historical practice should be continued in this instance, or whether it is preferable to limit the number of free parameters for future algorithms. (BTW this is not the same code point allocation model as TLS. TLS ciphersuites also include the AEAD mode, which remains a separate registry in *PGP) A -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From team at token2.ch Mon May 20 11:41:02 2024 From: team at token2.ch (TOKEN2 Support Team) Date: Mon, 20 May 2024 09:41:02 +0000 Subject: OpenPGP Card manufacturer id Message-ID: Hello, We are planning to add OpenPGP functionality to one of our products, and it seems we need to obtain a manufacturer ID. Could anyone assist us in getting such an ID assigned? The only reference we found for this procedure was on this mailing list. Therefore, in addition to requesting this by email from FSFE, we are also posting here. We apologize if this results in a duplicate message. Regards, TOKEN2 Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From team at token2.ch Mon May 20 11:48:49 2024 From: team at token2.ch (TOKEN2 Support Team) Date: Mon, 20 May 2024 09:48:49 +0000 Subject: OpenPGP Card manufacturer id In-Reply-To: References: Message-ID: Hello, We are planning to add OpenPGP functionality to one of our products, and it seems we need to obtain a manufacturer ID. Could anyone assist us in getting such an ID assigned? The only reference we found for this procedure was on this mailing list. Therefore, in addition to requesting this by email from FSFE, we are also posting here. We apologize if this results in a duplicate message. Regards, TOKEN2 Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Tue May 21 10:48:17 2024 From: wk at gnupg.org (Werner Koch) Date: Tue, 21 May 2024 10:48:17 +0200 Subject: OpenPGP Card manufacturer id In-Reply-To: (TOKEN's message of "Mon, 20 May 2024 09:41:02 +0000") References: Message-ID: <877cfnv9da.fsf@jacob.g10code.de> Hi! On Mon, 20 May 2024 09:41, TOKEN2 Support Team said: > and it seems we need to obtain a manufacturer ID. Could anyone assist > us in getting such an ID assigned? The easiest way is to write me a private mail including your mail address, web address, and a brief reason why you need a vendor id. No HTML mail parts please. Note that we don't assign them for experiments or small scale deployments - therefore it is better to take the id from the random range 0xFF00..FFFE - Range reserved for randomly assigned serial numbers. Serialnumbers with manufacturer ID in this range are an exception to the rule that they should be unique. It is expected that such a serialnumber is assigned using a true random function which generates 5 bytes (4 for the actual serial number and one to select a manufacturer ID out of this range). Note, that the 0xffff is not part of this range. Implementers using serial numbers as a unique ID should keep in mind that duplicates may happen. Using the of manufacturer IDs out of this range should only be done if no other way of obtaining a manufacturer ID is possible. 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: 247 bytes Desc: not available URL: