Mailing List Archive

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
33333 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.

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 11111 22222 33333 44444 00000 00000 AAAAA BBBBB CCCCC DDDDD then its
> long keyid is 11111 22222 33333 4 and its short keyid is 22 33333 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 <test@example.net>
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

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

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

On 28 Mar 2024, at 09:47, Werner Koch via Gnupg-users <gnupg-users@gnupg.org> 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 <test@example.net>
> 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

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

On 2 Apr 2024, at 11:58, Werner Koch <wk@gnupg.org> 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

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

On 2 Apr 2024, at 15:24, Werner Koch <wk@gnupg.org> 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

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

On 3 Apr 2024, at 10:32, Werner Koch <wk@gnupg.org> 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

On 28 Mar 2024, at 12:54, Christian Sommer via Gnupg-users <gnupg-users@gnupg.org> 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.

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 <andrewg@andrewg.com> wrote:
>
> On 28 Mar 2024, at 12:54, Christian Sommer via Gnupg-users <gnupg-users@gnupg.org> 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

On 17 Apr 2024, at 15:43, Christian Sommer <code.soma.kurisu@gmail.com> 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

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

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

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