Re: x488 vs all other : keyid flip
On Thu, 18 Apr 2024 10:26, Bruce Walzer said: > Perhaps things that accept key fingerprints should ignore anything > other than hex digits? Double clicking a word makes things really easy. I also doubt that anyone will compare a 64 hex digit fingerprint visually. Thus better paste it and let some software do the comare. Which reminds me that the gpg --edit-key -> sign dialog should also accept a fingerprint on the "Really sign? (y/N)" prompt. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein openpgp-digital-signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: x488 vs all other : keyid flip
On Thu, Apr 18, 2024 at 01:53:59PM +0200, Werner Koch via Gnupg-users wrote: > On Wed, 17 Apr 2024 16:43, Christian Sommer said: > > > I indeed choose to preset the "with-fingerprint" option in my > > gpg.conf. By removing it, listing my keys give back the full 64 > > character long fingerprint of my X448 key. > > We once agreed that it is better to show a shortened fingerprint for > human consumption. However, the mahine interface (--woth-colons) always > provides the full fingerprint. > > Further it seems that most users appreciate the non-formatted > fingerprint because that makes it easier to copy+paste. Perhaps things that accept key fingerprints should ignore anything other than hex digits? Bruce ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: x488 vs all other : keyid flip
On Wed, 17 Apr 2024 16:43, Christian Sommer said: > I indeed choose to preset the "with-fingerprint" option in my > gpg.conf. By removing it, listing my keys give back the full 64 > character long fingerprint of my X448 key. We once agreed that it is better to show a shortened fingerprint for human consumption. However, the mahine interface (--woth-colons) always provides the full fingerprint. Further it seems that most users appreciate the non-formatted fingerprint because that makes it easier to copy+paste. Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein openpgp-digital-signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: x488 vs all other : keyid flip
On 17 Apr 2024, at 15:43, Christian Sommer wrote: > > You are right Andrew! > > I indeed choose to preset the "with-fingerprint" option in my > gpg.conf. By removing it, listing my keys give back the full 64 > character long fingerprint of my X448 key. Good to hear! I think the best solution is for gnupg to ignore the `with-fingerprint` configuration option. Modern versions display primary key fingerprints by default anyway, so the alternative display format is both redundant and potentially confusing. I would be particularly concerned that people with different settings in their gpg.conf would see a mismatch between the 50-character fingerprint on one machine and the 64-character fingerprint on another, and incorrectly infer that something shady was going on. Differences in whitespace formatting are broadly expected (ref: credit card numbers) but truncation is not. And to pick up on an earlier point, short key IDs should never be displayed or processed under any circumstances. Evil32 was a whole decade ago. A signature.asc Description: Message signed with OpenPGP ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: x488 vs all other : keyid flip
You are right Andrew! I indeed choose to preset the "with-fingerprint" option in my gpg.conf. By removing it, listing my keys give back the full 64 character long fingerprint of my X448 key. Very nice to come back on this, thx. Kris. On Wed, Apr 17, 2024 at 1:00 PM Andrew Gallagher wrote: > > On 28 Mar 2024, at 12:54, Christian Sommer via Gnupg-users > wrote: > > > when explicitly telling GnuPG to display x448 fingerprints (gpg > --fingerprint) it just spits out the "abbreviated hex format" by takes > the first 50 bytes and sweeping the rest under the rug! Not very nice. > > > Hi, Christian. > > This seems to depend on whether you have “with-fingerprint” enabled in your > gpg.conf file. I commented out this line from my own gpg.conf, and I was able > to reproduce Werner’s full 64-character v5 fingerprint output. With this > configuration line enabled I could only see your 50-character fingerprint > output. > > Hope this helps, > Andrew. > ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: x488 vs all other : keyid flip
On 28 Mar 2024, at 12:54, Christian Sommer via Gnupg-users wrote: > > when explicitly telling GnuPG to display x448 fingerprints (gpg > --fingerprint) it just spits out the "abbreviated hex format" by takes > the first 50 bytes and sweeping the rest under the rug! Not very nice. Hi, Christian. This seems to depend on whether you have “with-fingerprint” enabled in your gpg.conf file. I commented out this line from my own gpg.conf, and I was able to reproduce Werner’s full 64-character v5 fingerprint output. With this configuration line enabled I could only see your 50-character fingerprint output. Hope this helps, Andrew. signature.asc Description: Message signed with OpenPGP ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: x488 vs all other : keyid flip
On 3 Apr 2024, at 10:32, Werner Koch wrote: > > On Tue, 2 Apr 2024 18:53, Andrew Gallagher said: > >> technical challenge since no modern software supports them, and gnupg1 >> doesn’t implement --list-packets :-) But I have to admit they do > > Sure it has the --list-packets command. This command dates back to the > very first release. Please ignore my above remark; PEBKAC :facepalm: > Given that Ubuntu's Hockeypuck is the default keyserver for GnuPG for > most people (i.e. on Windows) it would be good if it continues to > support at least the default keys. Whether X448 or the forthcominng > Kyber subkeys are relevant for keyservers is a different questions. I don’t see why a new algorithm would be fundamentally different from existing ones from a keyserver point of view. I would hope that they could be supported seamlessly. > FWIW, I have severe doubts on the usefulness of public keyservers given > the DoS problems for users and the wrong - but real - assumption of > users that keys from a keyserver are trustworthy. Sending keys with an > initial mail is a better way; keyserver should be used only to provide > subkey updates and revocations - no search by user id. I agree that keyservers are not ideal for userid search - unfortunately we haven’t collectively settled on an alternative yet. Sending initial keys with every email may not be the best solution for large key material such as Kyber, although one could imagine a two-step process such as looking up the signing key of a signed mail via a keyserver. And trust calculations would still be an issue of course; TOFU protects against a passive eavesdropper but doesn’t do much against an active MITM… there’s a lot of work still to be done to improve the UX of mutual verification. > I don't care about the IETF OpenPGP WG^Committee anymore. Like it or not, we have to find some way to tolerate each other’s existence. And petty name-calling doesn’t help. A signature.asc Description: Message signed with OpenPGP ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: x488 vs all other : keyid flip
On Tue, 2 Apr 2024 18:53, Andrew Gallagher said: > technical challenge since no modern software supports them, and gnupg1 > doesn’t implement --list-packets :-) But I have to admit they do Sure it has the --list-packets command. This command dates back to the very first release. >> But let me remark for the records that GnuPG has been the entity which >> always used the term /OpenPGP/ instead of /PGP/ or - as many Linux >> people did - the term /GPG/ keys. Thus we, and in particular me, >> stressed that this is the OpenPGP standard which GnuPG implements, >> popularized, took care, and pride of. Sure it does no "belong" to us or >> anyone - it is term without having a trademark. > > This is fair, and thank you. Not everyone is so careful. Thanks. > greatest amount of text declaring that OpenPGP no longer has a good > reputation has been written by you. So this is a circular argument. Well, I was obviously not caution enough with my statement. What I mean is that the current way the IETF WG works has a high potential to just this. At least an article in the very popular c't magazin might have such an effect. Maybe I should not overvalue such articles and postings on mailing lists. > Let us be clear here: you appear to be saying that if I want to update > hockeypuck to support both librepgp and crypto-refresh artifacts, I am > helping to destroy a solid standard? Or have I misunderstood your Given that Ubuntu's Hockeypuck is the default keyserver for GnuPG for most people (i.e. on Windows) it would be good if it continues to support at least the default keys. Whether X448 or the forthcominng Kyber subkeys are relevant for keyservers is a different questions. FWIW, I have severe doubts on the usefulness of public keyservers given the DoS problems for users and the wrong - but real - assumption of users that keys from a keyserver are trustworthy. Sending keys with an initial mail is a better way; keyserver should be used only to provide subkey updates and revocations - no search by user id. > I will bring this to the WG, with your comments. I don't care about the IETF OpenPGP WG^Committee anymore. Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein openpgp-digital-signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: x488 vs all other : keyid flip
On 2 Apr 2024, at 15:24, Werner Koch wrote: > > On Tue, 2 Apr 2024 12:39, Andrew Gallagher said: > >> Are you saying that this is *not* a novel failure mode? Because we’ve > > No. We had v2, v3 and v4 keyes in all kind of combinations in the past > (even as part of subkeys) and back then the two OpenPGP implementations > had no problems with that. The whole point of packet version numbers is > to be able to ignore such packets. This intrigued me, so I went back through the SKS dataset and found exactly four (4) v4 primary keys with v3 subkeys. This was quite a technical challenge since no modern software supports them, and gnupg1 doesn’t implement --list-packets :-) But I have to admit they do exist… and rfc4880 technically doesn’t forbid them. Still, I’m sure most people would find their existence as surprising as that of v3 sbinds over v4 subkeys (which are several orders of magnitude more common). >> different version number (since v3 did not support subkeys). Have you >> interop-tested this with other implementations? Besides RNP? What were > > If there are new implementaions they should check interop with the > de-facto standards which are PGP, GnuPG and later RNP. There is also > the widely used BouncyCastle library and we have not seen problems with > it except when ppl ignore features of these library. BouncyCastle is quite low level, and AFAICT does not enforce much in the way of packet grammar etc., so may not be the best comparison. And surely the entire point of a written specification is to avoid "de-facto standard” reference implementations? > But let me remark for the records that GnuPG has been the entity which > always used the term /OpenPGP/ instead of /PGP/ or - as many Linux > people did - the term /GPG/ keys. Thus we, and in particular me, > stressed that this is the OpenPGP standard which GnuPG implements, > popularized, took care, and pride of. Sure it does no "belong" to us or > anyone - it is term without having a trademark. This is fair, and thank you. Not everyone is so careful. > OTOH, tehre is a > respoisbility here to keep the repudiation of that standard high - this > is what the /current OpenPGP WG participants/ don't a do anymore since > fall 2021. Reputation is a matter of publicly expressed opinion, and by far the greatest amount of text declaring that OpenPGP no longer has a good reputation has been written by you. So this is a circular argument. >>> how should an implementation behave if it wants to support both the >>> librepgp and crypto-refresh specs? > > That is up to those implementaions who want to destroy a solid standard. > Why should I help them? Let us be clear here: you appear to be saying that if I want to update hockeypuck to support both librepgp and crypto-refresh artifacts, I am helping to destroy a solid standard? Or have I misunderstood your position? > This is a GnuPG mailing list and you are > welcome to discuss technical details of stuff relevant to GnuPG and > OpenPGP (up to fall 2021). Everything else is better addressed to the > crypto-refresh commitee. I will bring this to the WG, with your comments. Thanks, A signature.asc Description: Message signed with OpenPGP ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: x488 vs all other : keyid flip
On Tue, 2 Apr 2024 12:39, Andrew Gallagher said: > Are you saying that this is *not* a novel failure mode? Because we’ve No. We had v2, v3 and v4 keyes in all kind of combinations in the past (even as part of subkeys) and back then the two OpenPGP implementations had no problems with that. The whole point of packet version numbers is to be able to ignore such packets. > different version number (since v3 did not support subkeys). Have you > interop-tested this with other implementations? Besides RNP? What were If there are new implementaions they should check interop with the de-facto standards which are PGP, GnuPG and later RNP. There is also the widely used BouncyCastle library and we have not seen problems with it except when ppl ignore features of these library. > 3. The term “OpenPGP” does not belong to GnuPG. But let me remark for the records that GnuPG has been the entity which always used the term /OpenPGP/ instead of /PGP/ or - as many Linux people did - the term /GPG/ keys. Thus we, and in particular me, stressed that this is the OpenPGP standard which GnuPG implements, popularized, took care, and pride of. Sure it does no "belong" to us or anyone - it is term without having a trademark. OTOH, tehre is a respoisbility here to keep the repudiation of that standard high - this is what the /current OpenPGP WG participants/ don't a do anymore since fall 2021. > And I notice that you have not addressed the most important point in > my last email: > >> how should an implementation behave if it wants to support both the >> librepgp and crypto-refresh specs? That is up to those implementaions who want to destroy a solid standard. Why should I help them? This is a GnuPG mailing list and you are welcome to discuss technical details of stuff relevant to GnuPG and OpenPGP (up to fall 2021). Everything else is better addressed to the crypto-refresh commitee. Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein openpgp-digital-signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: x488 vs all other : keyid flip
On 2 Apr 2024, at 11:58, Werner Koch wrote: > > On Fri, 29 Mar 2024 13:00, Andrew Gallagher said: > >> V5 subkeys of v4 primary keys would appear to introduce a novel >> failure mode. It should be noted that in crypto-refresh, adding a > > Nope. Are you saying that this is *not* a novel failure mode? Because we’ve never before had a key of one version number with a subkey of a different version number (since v3 did not support subkeys). Have you interop-tested this with other implementations? Besides RNP? What were the results? > A v5 key has nothing to do a v4 signature and having different > algorithm on the primary key and the subkeys is really common and > allowed us once to slowly introduce RSA and ECC without any major > problems. This is why we will do the same for PQC encryption. Yes, but a subkey of a different *algorithm* is anticipated by the spec and should work (in principle). A subkey of a different *version* is a different matter. Or is it specified somewhere that I have overlooked? > All in all a really minor changes and not worth a long debate. It may be a minor change, but if it breaks interop it is still worth debating the consequences. > The crypto-refresh has a lot of things which breaks OpenPGP and that > draft, or soon to be RFC, does not care about backward compatibility. > They should not have used the term OpenPGP for this. You keep repeating these talking points, but they are simply not true. 1. crypto-refresh defines a *different* set of extensions to OpenPGP than GnuPG supports, but these do not “break” OpenPGP. 2. crypto-refresh has bumped all of its packet version numbers specifically to avoid compatibility issues. Just because the WG have a different opinion does not mean that they don’t care. 3. The term “OpenPGP” does not belong to GnuPG. And I notice that you have not addressed the most important point in my last email: > how should an implementation behave if it wants to support both the librepgp > and crypto-refresh specs? A signature.asc Description: Message signed with OpenPGP ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: x488 vs all other : keyid flip
On Fri, 29 Mar 2024 13:00, Andrew Gallagher said: > V5 subkeys of v4 primary keys would appear to introduce a novel > failure mode. It should be noted that in crypto-refresh, adding a Nope. A v5 key has nothing to do a v4 signature and having different algorithm on the primary key and the subkeys is really common and allowed us once to slowly introduce RSA and ECC without any major problems. This is why we will do the same for PQC encryption. To repeat: The *v5 key format* merely adds a four-octet count of the public key material to the v4 format. There are also minor chnages for the (not so import) secret key exchange format. And - more important - it defines that the fingerprint is now done using SHA-256. The latter is the whole point why we once decided to use add a v5 format - to make it clear tha a SHA-256 fingerprint is used. All in all a really minor changes and not worth a long debate. The crypto-refresh has a lot of things which breaks OpenPGP and that draft, or soon to be RFC, does not care about backward compatibility. They should not have used the term OpenPGP for this. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein openpgp-digital-signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: x488 vs all other : keyid flip
On 28 Mar 2024, at 09:47, Werner Koch via Gnupg-users wrote: > > x448 keys are created as version 5 keys and version 5 keys come with a > 32 byte fingerprint (v4 has 20 bytes). ... > Here is an example: > > pub ed25519 2016-02-02 [SC] > FD8FEC4F8595AB1B6F60D43FC2CED0800E50ACF1 > uid [ unknown] chicago > sub cv25519 2016-02-02 [E] > 532D5C7677B4D806B50B0E0F11E7BF9EE1034B1C > sub cv448 2024-03-27 [E] > FB6A3BC5EB92C8AA9F3807A9B4C79C38F16E9AA4CF9384B07485923574773DCF > > where a v5 subkey has been added. V5 subkeys of v4 primary keys would appear to introduce a novel failure mode. It should be noted that in crypto-refresh, adding a non-v4 subkey to a v4 primary key is explicitly forbidden: > Every subkey for a v4 primary key MUST be a v4 subkey. https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-crypto-refresh-13#section-10.1.3 I notice in the LibrePGP draft that there is no specification of this hybrid v4/v5 construction. The corresponding section of the spec doesn’t even mention v5 TPKs at all, just v3 and v4: https://datatracker.ietf.org/doc/html/draft-koch-librepgp#name-key-structures This appears to be a verbatim copy of the corresponding section from RFC4880 that has not (yet) been updated to take account of v5: https://datatracker.ietf.org/doc/html/rfc4880#section-12.1 So a few questions arise: is this a deliberate design decision, and if so what considerations were taken into account in that design, and how should an implementation behave if it wants to support both the librepgp and crypto-refresh specs? A signature.asc Description: Message signed with OpenPGP ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: x488 vs all other : keyid flip
On Thu, 28 Mar 2024 13:54, Christian Sommer said: > Likewise by telling GnuPG you really want the short keyID displayed > (gpg --keyid-format short) it takes the LAST 32 bytes of the FIRST 64 > bytes of the fingerprint. The thing here is that the short keyid is not from the specification but a convenience thing PGP-2 implemented (which actually did not compute the keyid from the fingerprint). Yes, it would indeed be nicer if we could work with the keyid in the same way as git handles a commit id. Unfortunately it will be pretty hard to change how the short keyid is derived from the long keyid or even use arbitrary sized keyids of fingerprints. In GnuPG the keyid is a "u32 kid[2]" and this is used a lot all over the code, for example: fprint ("long keyid: %08lX%08lX\n", (ulong)kid[0], (ulong)kid[1]); fprint ("short keyid: %08lX\n", (ulong)kid[1]); > discovered GnuPG for myself. so i'm completley new to this community > what's the preferred development model? i guess filing an issue, See doc/HACKING for hints. Please also be aware that for any unattended use you need to use the --with-colons and --status-fd interfaces. Some ignore this advice and thus we are nice and try to minimize all changes even to the human readable output format. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein openpgp-digital-signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: x488 vs all other : keyid flip
you are absolutely right: when explicitly telling GnuPG to display x448 fingerprints (gpg --fingerprint) it just spits out the "abbreviated hex format" by takes the first 50 bytes and sweeping the rest under the rug! Not very nice. Likewise by telling GnuPG you really want the short keyID displayed (gpg --keyid-format short) it takes the LAST 32 bytes of the FIRST 64 bytes of the fingerprint. i prefer getting what i ordered. of course it's a trivial thing for my self counting the first eight hexadecimal characters to fulfill my particular use-case (i'd like to have matching mail-addresses and short key-IDs). although you gave the impression nobody would use those command line options (plainly because of that ?"fingerprint-forgery-attack" occurring on short key-IDs) why then don't ditch it? on the other hand, until it's here i feel inclined on fixing it. so if there are no objectiions i'd like to try myself on both errorneous outputs. as you may have notices it's just a few weeks ago when i discovered GnuPG for myself. so i'm completley new to this community what's the preferred development model? i guess filing an issue, forking the repository, making a pull-request, but there are also those T-numbers linked by releases. ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: x488 vs all other : keyid flip
On Thu, 28 Mar 2024 00:49, Christian Sommer said: > on the other hand a x488 fingerprint is 50 hex characters long. let's say > it's 1 2 3 4 0 0 A B C D then its > long keyid is 1 2 3 4 and its short keyid is 22 3 4. x448 keys are created as version 5 keys and version 5 keys come with a 32 byte fingerprint (v4 has 20 bytes). Also the way the keyid is computed has changed: For v5 keys the keyid are the left most 32 or 64 bits. For display purposes an abbreviated hex format is used. It might be that the keyid is then display wrongly - frankly I have not checked because keyids are rarely used. Even the formatted fingerprint ("gpg --fingerprint") is not very useful anymore because the majority of users just copy+paste the fingerprint and thus the straight hex format as displayed by "gpg -k" is more useful. Here is an example: pub ed25519 2016-02-02 [SC] FD8FEC4F8595AB1B6F60D43FC2CED0800E50ACF1 uid [ unknown] chicago sub cv25519 2016-02-02 [E] 532D5C7677B4D806B50B0E0F11E7BF9EE1034B1C sub cv448 2024-03-27 [E] FB6A3BC5EB92C8AA9F3807A9B4C79C38F16E9AA4CF9384B07485923574773DCF where a v5 subkey has been added. Note also that I use the --with-subkey-fongerprint option which will eventually be the default. Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein openpgp-digital-signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: x488 vs all other : keyid flip
excuse me sirs. when i wrote that question i was already very tired. so in the meantime i realized that there are different code paths for ed/x448 goldilocks. one of them distinguishes the Endiannes on behalf of the algorithm (e.g. sets is_little_endian to true | false in g10/ecdh.c). i haven't found the time to go much deeper yet, but this and the read_16 / 32 in g10/parse-packet.c as well as the convert_le_u16 / 32 functions in scd/ccid-driver.c / tools/ccidmon.c seem to play a role. i guess key-IDs are calculated on demand and not stored separately along fingerprints. based on what i've seen until now i tend to accept that the short keyid 22 3 4 of above example is in fact right. on the next occasion my search will go on, but if anybody can confirm and tell even more about that observation, i'd be very grateful. ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users