From robbat2 at gentoo.org Sat Sep 2 18:59:43 2023 From: robbat2 at gentoo.org (Robin H. Johnson) Date: Sat, 2 Sep 2023 09:59:43 -0700 Subject: [PATCH gnupg] gpg: Add --list-filter properties sig_expires/sig_expires_d Message-ID: <20230902165950.15045-1-robbat2@gentoo.org> Modelled after key_expires/key_expires_d. This should be useful to detect upcoming certification expiry, so the certifications can be renewed in advance of the expiry. Signed-off-by: Robin H. Johnson --- doc/gpg.texi | 6 ++++++ g10/import.c | 14 ++++++++++++++ 2 files changed, 20 insertions(+) diff --git a/doc/gpg.texi b/doc/gpg.texi index 15b3243d0..6ba944edb 100644 --- a/doc/gpg.texi +++ b/doc/gpg.texi @@ -2715,6 +2715,12 @@ The available properties are: second is the same but given as an ISO date string, e.g. "2016-08-17". (drop-sig) + @item sig_expires + @itemx sig_expires_d + The expiration time of a signature packet or 0 if it does not + expire. The second is the same but given as an ISO date string or + an empty string e.g. "2038-01-19". + @item sig_algo A number with the public key algorithm of a signature packet. (drop-sig) diff --git a/g10/import.c b/g10/import.c index d84a083cc..c1e76c3f0 100644 --- a/g10/import.c +++ b/g10/import.c @@ -1509,6 +1509,20 @@ impex_filter_getval (void *cookie, const char *propname) { result = dateonlystr_from_sig (sig); } + else if (!strcmp (propname, "sig_expires")) + { + snprintf (numbuf, sizeof numbuf, "%lu", (ulong)sig->expiredate); + result = numbuf; + } + else if (!strcmp (propname, "sig_expires_d")) + { + static char exdatestr[MK_DATESTR_SIZE]; + + if (sig->expiredate) + result = mk_datestr (exdatestr, sizeof exdatestr, sig->expiredate); + else + result = ""; + } else if (!strcmp (propname, "sig_algo")) { snprintf (numbuf, sizeof numbuf, "%d", sig->pubkey_algo); -- 2.42.0 From nathbappai at gmail.com Thu Sep 7 07:05:03 2023 From: nathbappai at gmail.com (Biswapriyo Nath) Date: Thu, 7 Sep 2023 05:05:03 +0000 Subject: [PATCH pinentry] w32: Fix return value of dlg_proc callback function Message-ID: <20230907050503.27365-1-nathbappai@gmail.com> The return type of dlg_proc function was changed in abbecc67d9a9b007b77295c599c90b37ddee275c commit. Signed-off-by: Biswapriyo Nath --- w32/main.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/w32/main.c b/w32/main.c index 922e9c4..e9b35a3 100644 --- a/w32/main.c +++ b/w32/main.c @@ -395,12 +395,12 @@ dlg_proc (HWND dlg, UINT msg, WPARAM wparam, LPARAM lparam) /* Display the error prompt in red. */ SetTextColor ((HDC)wparam, RGB (255, 0, 0)); SetBkMode ((HDC)wparam, TRANSPARENT); - return (BOOL)GetStockObject (NULL_BRUSH); + return (INT_PTR)GetStockObject (NULL_BRUSH); } break; } - return FALSE; + return 0; } -- 2.42.0 From marmarek at invisiblethingslab.com Tue Sep 12 17:45:05 2023 From: marmarek at invisiblethingslab.com (Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?=) Date: Tue, 12 Sep 2023 17:45:05 +0200 Subject: gpg --export produces invalid EdDSA output - regression Message-ID: Hello, GnuPG 2.4.0 produces invalid output when exporting EdDSA key. Specifically, there is extra padding in the signature. This causes Sequoia (and maybe others) to reject such key (GnuPG itself accepts it). The problem does not affect 2.2.40, so this is a regression in some later version. This can be reproduced as follows: wget https://github.com/QubesOS/qubes-qubes-release/raw/main/RPM-GPG-KEY-qubes-4.2-templates-community mkdir ~/test gpg --homedir ~/test --import RPM-GPG-KEY-qubes-4.2-templates-community With 2.2.4: [user at disp6884 gnupg-2.2.40]$ g10/gpg --homedir ~/test --export |sq packet dump -x Public-Key Packet, old CTB, 2 header bytes + 51 bytes Version: 4 Creation time: 2023-03-14 14:35:36 UTC Pk algo: EdDSA Pk size: 256 bits Fingerprint: 8F24D388C9DA21A55D7DBC8F08D08ABE6D5C71B3 KeyID: 08D08ABE6D5C71B3 00000000 98 CTB 00000001 33 length 00000002 04 version 00000003 64 10 86 38 creation_time 00000007 16 pk_algo 00000008 09 curve_len 00000009 2b 06 01 04 01 da 47 curve 00000010 0f 01 00000012 01 07 eddsa_public_len 00000014 40 a8 b6 69 8c 05 70 46 52 b5 2d 5d eddsa_public 00000020 08 e7 71 d8 b9 5f a6 e5 24 5b 33 e5 35 1c 5c 0b 00000030 d9 96 ad bc c7 User ID Packet, old CTB, 2 header bytes + 52 bytes Value: Qubes OS Release 4.2 Community Templates Signing Key 00000000 b4 CTB 00000001 34 length 00000002 51 75 62 65 73 20 4f 53 20 52 65 6c 65 61 value 00000010 73 65 20 34 2e 32 20 43 6f 6d 6d 75 6e 69 74 79 00000020 20 54 65 6d 70 6c 61 74 65 73 20 53 69 67 6e 69 00000030 6e 67 20 4b 65 79 Signature Packet, old CTB, 2 header bytes + 146 bytes Version: 4 Type: PositiveCertification Pk algo: EdDSA Hash algo: SHA512 Hashed area: Issuer Fingerprint: 8F24D388C9DA21A55D7DBC8F08D08ABE6D5C71B3 Signature creation time: 2023-03-14 15:17:16 UTC Key flags: CS Symmetric algo preferences: AES256, AES192, AES128, TripleDES AEAD preferences: OCB Hash preferences: SHA512, SHA384, SHA256, SHA224, SHA1 Compression preferences: Zlib, BZip2, Zip Features: MDC, AEAD, #2 Keyserver preferences: no modify Unhashed area: Issuer: 08D08ABE6D5C71B3 Digest prefix: 1631 Level: 0 (signature over data) 00000000 88 CTB 00000001 92 length 00000002 04 version 00000003 13 type 00000004 16 pk_algo 00000005 0a hash_algo 00000006 00 3b hashed_area_len 00000008 16 subpacket length 00000009 21 subpacket tag 0000000a 04 version 0000000b 8f 24 d3 88 c9 issuer fp 00000010 da 21 a5 5d 7d bc 8f 08 d0 8a be 6d 5c 71 b3 0000001f 05 subpacket length 00000020 02 subpacket tag 00000021 64 10 8f fc sig creation time 00000025 02 subpacket length 00000026 1b subpacket tag 00000027 03 key flags 00000028 05 subpacket length 00000029 0b subpacket tag 0000002a 09 08 07 02 pref sym algos 0000002e 02 subpacket length 0000002f 22 subpacket tag 00000030 02 pref aead algos 00000031 06 subpacket length 00000032 15 subpacket tag 00000033 0a 09 08 0b 02 pref hash algos 00000038 04 subpacket length 00000039 16 subpacket tag 0000003a 02 03 01 pref compression algos 0000003d 02 subpacket length 0000003e 1e subpacket tag 0000003f 07 features 00000040 02 subpacket length 00000041 17 subpacket tag 00000042 80 key server pref 00000043 00 0a unhashed_area_len 00000045 09 subpacket length 00000046 10 subpacket tag 00000047 08 d0 8a be 6d 5c 71 b3 issuer 0000004f 16 digest_prefix1 00000050 31 digest_prefix2 00000051 01 00 eddsa_sig_r_len 00000053 87 ab 4e 3a a8 4b 13 19 7f 39 21 4a ef eddsa_sig_r 00000060 7e 87 10 74 27 82 50 9b 14 54 c3 1c 1f 58 34 09 00000070 b5 2f 27 00000073 00 f8 eddsa_sig_s_len 00000075 b2 c7 d6 0d 3e 23 40 41 fe 8e 9c eddsa_sig_s 00000080 51 28 21 a0 31 b7 ca 55 9c b3 a3 6a 70 d9 ca d0 00000090 c7 bd eb 0f With 2.4.0: [user at disp6884 gnupg-2.4.0]$ g10/gpg --homedir ~/test --export |sq packet dump -x Public-Key Packet, old CTB, 2 header bytes + 51 bytes Version: 4 Creation time: 2023-03-14 14:35:36 UTC Pk algo: EdDSA Pk size: 256 bits Fingerprint: 8F24D388C9DA21A55D7DBC8F08D08ABE6D5C71B3 KeyID: 08D08ABE6D5C71B3 00000000 98 CTB 00000001 33 length 00000002 04 version 00000003 64 10 86 38 creation_time 00000007 16 pk_algo 00000008 09 curve_len 00000009 2b 06 01 04 01 da 47 curve 00000010 0f 01 00000012 01 07 eddsa_public_len 00000014 40 a8 b6 69 8c 05 70 46 52 b5 2d 5d eddsa_public 00000020 08 e7 71 d8 b9 5f a6 e5 24 5b 33 e5 35 1c 5c 0b 00000030 d9 96 ad bc c7 User ID Packet, old CTB, 2 header bytes + 52 bytes Value: Qubes OS Release 4.2 Community Templates Signing Key 00000000 b4 CTB 00000001 34 length 00000002 51 75 62 65 73 20 4f 53 20 52 65 6c 65 61 value 00000010 73 65 20 34 2e 32 20 43 6f 6d 6d 75 6e 69 74 79 00000020 20 54 65 6d 70 6c 61 74 65 73 20 53 69 67 6e 69 00000030 6e 67 20 4b 65 79 Unknown or Unsupported Packet, old CTB, 2 header bytes + 147 bytes Tag: Signature Packet Error: Malformed MPI: leading bit is not set: expected bit 8 to be set in 0 (0) 00000000 88 CTB 00000001 93 length 00000002 04 version 00000003 13 type 00000004 16 pk_algo 00000005 0a hash_algo 00000006 00 3b hashed_area_len 00000008 16 subpacket length 00000009 21 subpacket tag 0000000a 04 version 0000000b 8f 24 d3 88 c9 issuer fp 00000010 da 21 a5 5d 7d bc 8f 08 d0 8a be 6d 5c 71 b3 0000001f 05 subpacket length 00000020 02 subpacket tag 00000021 64 10 8f fc sig creation time 00000025 02 subpacket length 00000026 1b subpacket tag 00000027 03 key flags 00000028 05 subpacket length 00000029 0b subpacket tag 0000002a 09 08 07 02 pref sym algos 0000002e 02 subpacket length 0000002f 22 subpacket tag 00000030 02 pref aead algos 00000031 06 subpacket length 00000032 15 subpacket tag 00000033 0a 09 08 0b 02 pref hash algos 00000038 04 subpacket length 00000039 16 subpacket tag 0000003a 02 03 01 pref compression algos 0000003d 02 subpacket length 0000003e 1e subpacket tag 0000003f 07 features 00000040 02 subpacket length 00000041 17 subpacket tag 00000042 80 key server pref 00000043 00 0a unhashed_area_len 00000045 09 subpacket length 00000046 10 subpacket tag 00000047 08 d0 8a be 6d 5c 71 b3 issuer 0000004f 16 digest_prefix1 00000050 31 digest_prefix2 00000051 01 00 eddsa_sig_r_len 00000053 87 ab 4e 3a a8 4b 13 19 7f 39 21 4a ef eddsa_sig_r 00000060 7e 87 10 74 27 82 50 9b 14 54 c3 1c 1f 58 34 09 00000070 b5 2f 27 00000073 01 00 00 b2 c7 d6 0d 3e 23 40 41 fe 8e .......>#@A.. 00000080 9c 51 28 21 a0 31 b7 ca 55 9c b3 a3 6a 70 d9 ca .Q(!.1..U...jp.. 00000090 d0 c7 bd eb 0f ..... Some more details about similar/related issues can be found at: https://gitlab.com/sequoia-pgp/sequoia/-/issues/1053 https://github.com/rpm-software-management/dnf/issues/1974 -- Best Regards, Marek Marczykowski-G?recki Invisible Things Lab -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From wk at gnupg.org Thu Sep 14 14:11:52 2023 From: wk at gnupg.org (Werner Koch) Date: Thu, 14 Sep 2023 14:11:52 +0200 Subject: gpg --export produces invalid EdDSA output - regression In-Reply-To: ("Marek =?utf-8?Q?Marczykowski-G?= =?utf-8?Q?=C3=B3recki=22's?= message of "Tue, 12 Sep 2023 17:45:05 +0200") References: Message-ID: <874jjxj6nr.fsf@jacob.g10code.de> Hi! The issue you mention has been discussed in length and Gniibe actually took over my place in the "crypto-refresh" design team to help clarify the interpretation of the MPI (which they unfortunatley ignored). MPIs in OpenPGP are signed and thus may need a zero prefix byte because negative numbers are nowhere used. The solution is to specify a new type (SOS) at least in certain parts of the protocol. This must of course be done in a backward compatible way given that ed25519 is in use since 2014. GnuPG 2.2 is older and and does not yet use the SOS which is the reason for the different encodings you see. In short, there is no bug but implementations need to follow this advice 1. OpenPGP implementations should implement: Recovery of leading zero octets for Ed25519 key handling (secret part) and Ed25519 signature 2. OpenPGP implementations are expected to accept: Malformed MPI (with leading zero octet(s)), which is valid in SOS For secret part of Ed25519/Curve25519/X448/Ed448 key and for signature value S. (see https://dev.gnupg.org/T4954) 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 marmarek at invisiblethingslab.com Thu Sep 14 14:34:20 2023 From: marmarek at invisiblethingslab.com (Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?=) Date: Thu, 14 Sep 2023 14:34:20 +0200 Subject: gpg --export produces invalid EdDSA output - regression In-Reply-To: <874jjxj6nr.fsf@jacob.g10code.de> References: <874jjxj6nr.fsf@jacob.g10code.de> Message-ID: On Thu, Sep 14, 2023 at 02:11:52PM +0200, Werner Koch wrote: > Hi! Hi! Thanks for the answer! > The issue you mention has been discussed in length and Gniibe actually > took over my place in the "crypto-refresh" design team to help clarify > the interpretation of the MPI (which they unfortunatley ignored). MPIs > in OpenPGP are signed and thus may need a zero prefix byte because > negative numbers are nowhere used. Hmm, but the RFC seems to specify it as unsigned, not signed: https://datatracker.ietf.org/doc/html/rfc4880#section-3.2 Multiprecision integers (also called MPIs) are unsigned integers used to hold large integers such as the ones used in cryptographic calculations. ... Additional rules: The size of an MPI is ((MPI.length + 7) / 8) + 2 octets. The length field of an MPI describes the length starting from its most significant non-zero bit. Thus, the MPI [00 02 01] is not formed correctly. It should be [00 01 01]. > The solution is to specify a new > type (SOS) at least in certain parts of the protocol. This must of > course be done in a backward compatible way given that ed25519 is in use > since 2014. Given the above, I'm not sure if that's really necessary. But even if it is, it isn't "backward compatible" change, since standard respecting-compliant implementation is expected to treat leading zeroes as malformed. > GnuPG 2.2 is older and and does not yet use the SOS which is the reason > for the different encodings you see. In short, there is no bug but > implementations need to follow this advice > > 1. OpenPGP implementations should implement: > > Recovery of leading zero octets for Ed25519 key handling (secret > part) and Ed25519 signature > > 2. OpenPGP implementations are expected to accept: > > Malformed MPI (with leading zero octet(s)), which is valid in SOS > For secret part of Ed25519/Curve25519/X448/Ed448 key and for > signature value S. My reading of the above is rather "an OpenPGP implementation that wants to be compatible with GnuPG should also accept MPI that is not compliant with the OpenPGP specification"... Have I missed some part of the spec? Is this new "SOS" type described in some specification? > (see https://dev.gnupg.org/T4954) -- Best Regards, Marek Marczykowski-G?recki Invisible Things Lab -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From wk at gnupg.org Thu Sep 14 15:49:47 2023 From: wk at gnupg.org (Werner Koch) Date: Thu, 14 Sep 2023 15:49:47 +0200 Subject: gpg --export produces invalid EdDSA output - regression In-Reply-To: ("Marek =?utf-8?Q?Marczykowski-G?= =?utf-8?Q?=C3=B3recki=22's?= message of "Thu, 14 Sep 2023 14:34:20 +0200") References: <874jjxj6nr.fsf@jacob.g10code.de> Message-ID: <87led8j24k.fsf@jacob.g10code.de> On Thu, 14 Sep 2023 14:34, Marek Marczykowski-G?recki said: > Hmm, but the RFC seems to specify it as unsigned, not signed: Sure - mail edit error on my part. > Given the above, I'm not sure if that's really necessary. But even if it > is, it isn't "backward compatible" change, since standard > respecting-compliant implementation is expected to treat leading zeroes > as malformed. The problem here is that this is not a number. The MPI requirement has been ignored since the introduction of RFC-6637 (ECC for OpenPGP) in PGP, GnuPG and other implementation with support for ECC. > My reading of the above is rather "an OpenPGP implementation that wants > to be compatible with GnuPG should also accept MPI that is not compliant > with the OpenPGP specification"... Have I missed some part of the spec? A specification and the actual practise almost always differ. Even if the author of RFC-6637 also did the implementation for PGP and GnuPG. It is a specification bug and newer implementations need to cope with the reality. > Is this new "SOS" type described in some specification? See >> (see https://dev.gnupg.org/T4954) and of course the code. 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 marmarek at invisiblethingslab.com Thu Sep 14 16:10:06 2023 From: marmarek at invisiblethingslab.com (Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?=) Date: Thu, 14 Sep 2023 16:10:06 +0200 Subject: gpg --export produces invalid EdDSA output - regression In-Reply-To: <87led8j24k.fsf@jacob.g10code.de> References: <874jjxj6nr.fsf@jacob.g10code.de> <87led8j24k.fsf@jacob.g10code.de> Message-ID: On Thu, Sep 14, 2023 at 03:49:47PM +0200, Werner Koch wrote: > On Thu, 14 Sep 2023 14:34, Marek Marczykowski-G?recki said: > > > Hmm, but the RFC seems to specify it as unsigned, not signed: > > Sure - mail edit error on my part. > > > Given the above, I'm not sure if that's really necessary. But even if it > > is, it isn't "backward compatible" change, since standard > > respecting-compliant implementation is expected to treat leading zeroes > > as malformed. > > The problem here is that this is not a number. The MPI requirement has > been ignored since the introduction of RFC-6637 (ECC for OpenPGP) in > PGP, GnuPG and other implementation with support for ECC. But GnuPG 2.2 did produced standard-compliant output, it stopped doing so only later, no? So, where it was "ignored" that prompted changing what output is produced? In the discussion I see that SSH uses signed numbers there, but I don't see how it's relevant for `gpg --export` which deals with OpenPGP format, not SSH format. > > My reading of the above is rather "an OpenPGP implementation that wants > > to be compatible with GnuPG should also accept MPI that is not compliant > > with the OpenPGP specification"... Have I missed some part of the spec? > > A specification and the actual practise almost always differ. Even if > the author of RFC-6637 also did the implementation for PGP and GnuPG. > It is a specification bug and newer implementations need to cope with > the reality. While it may be desirable to have _optional_ workarounds for some misbehaving implementation, IMO the goal should be to converge at the specified behavior. The change we are discussing here "forces" already compliant implementations to diverge from the spec, which is step backward. And I'm not surprised that some projects refuse to go into that direction... If there is a need for this padding to workaround some bug in another implementation (can you name specific software and version when it's actually required?), maybe make it configurable with a switch? > > Is this new "SOS" type described in some specification? > > See > > >> (see https://dev.gnupg.org/T4954) > > and of course the code. Well, issue tracker of a specific implementation is not really specification that others should follow when implementing an IETF standard... -- Best Regards, Marek Marczykowski-G?recki Invisible Things Lab -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From robbat2 at gentoo.org Thu Sep 14 20:30:28 2023 From: robbat2 at gentoo.org (robbat2 at gentoo.org) Date: Thu, 14 Sep 2023 11:30:28 -0700 Subject: [PATCH gnupg] gpg: Add --list-filter properties sig_expires/sig_expires_d Message-ID: <20230914183028.8638-1-robbat2@gentoo.org> From: "Robin H. Johnson" Modelled after key_expires/key_expires_d. This should be useful to detect upcoming certification expiry, so the certifications can be renewed in advance of the expiry. Signed-off-by: Robin H. Johnson --- doc/gpg.texi | 6 ++++++ g10/import.c | 14 ++++++++++++++ 2 files changed, 20 insertions(+) diff --git a/doc/gpg.texi b/doc/gpg.texi index 15b3243d0..6ba944edb 100644 --- a/doc/gpg.texi +++ b/doc/gpg.texi @@ -2715,6 +2715,12 @@ The available properties are: second is the same but given as an ISO date string, e.g. "2016-08-17". (drop-sig) + @item sig_expires + @itemx sig_expires_d + The expiration time of a signature packet or 0 if it does not + expire. The second is the same but given as an ISO date string or + an empty string e.g. "2038-01-19". + @item sig_algo A number with the public key algorithm of a signature packet. (drop-sig) diff --git a/g10/import.c b/g10/import.c index d84a083cc..c1e76c3f0 100644 --- a/g10/import.c +++ b/g10/import.c @@ -1509,6 +1509,20 @@ impex_filter_getval (void *cookie, const char *propname) { result = dateonlystr_from_sig (sig); } + else if (!strcmp (propname, "sig_expires")) + { + snprintf (numbuf, sizeof numbuf, "%lu", (ulong)sig->expiredate); + result = numbuf; + } + else if (!strcmp (propname, "sig_expires_d")) + { + static char exdatestr[MK_DATESTR_SIZE]; + + if (sig->expiredate) + result = mk_datestr (exdatestr, sizeof exdatestr, sig->expiredate); + else + result = ""; + } else if (!strcmp (propname, "sig_algo")) { snprintf (numbuf, sizeof numbuf, "%d", sig->pubkey_algo); -- 2.42.0 From pgut001 at cs.auckland.ac.nz Fri Sep 15 01:56:38 2023 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Thu, 14 Sep 2023 23:56:38 +0000 Subject: gpg --export produces invalid EdDSA output - regression In-Reply-To: References: <874jjxj6nr.fsf@jacob.g10code.de> <87led8j24k.fsf@jacob.g10code.de> Message-ID: Marek Marczykowski-G?recki writes: >In the discussion I see that SSH uses signed numbers there, but I don't see >how it's relevant for `gpg --export` which deals with OpenPGP format, not SSH >format. A data point from the ASN.1 world, they also use signed integers and in 100.0% of all cases where the sign bit is set (at least in crypto usage) it's an encoding error, not an attempt to encode a negative number. So all implementations treat the values as unsigned no matter what they're actually supposed to be. Which has in turn led to a tolerance of new implementations that get the encoding wrong, but that's another issue. However, if the whole world treats your values as unsigned anyway then it seems a bit risky to break the encoding to accommodate something that doesn't exist. Peter. From wk at gnupg.org Fri Sep 15 10:35:29 2023 From: wk at gnupg.org (Werner Koch) Date: Fri, 15 Sep 2023 10:35:29 +0200 Subject: gpg --export produces invalid EdDSA output - regression In-Reply-To: ("Marek =?utf-8?Q?Marczykowski-G?= =?utf-8?Q?=C3=B3recki=22's?= message of "Thu, 14 Sep 2023 16:10:06 +0200") References: <874jjxj6nr.fsf@jacob.g10code.de> <87led8j24k.fsf@jacob.g10code.de> Message-ID: <87sf7fhm0e.fsf@jacob.g10code.de> On Thu, 14 Sep 2023 16:10, Marek Marczykowski-G?recki said: > misbehaving implementation, IMO the goal should be to converge at the > specified behavior. The change we are discussing here "forces" already The question is just which specification. GnuPG was the first to implement ed25519 and then cross-tested this with RNP. Other implementions showed up only later and thus need to follow existing praxis. That we decided to change our implementations in a compatible(!) way had practical reasons for better inperoperability between other protocols and hardware implementations. The folks from the other implementation knew about that (after all they used to be employed for working GnuPG). > Well, issue tracker of a specific implementation is not really > specification that others should follow when implementing an IETF > standard... The only specification/standard here is RFC6637 (ECC for OpenPGP) which states: This document only defines the uncompressed point format. The point is encoded in the Multiprecision Integer (MPI) format [RFC4880]. The content of the MPI is the following: B = 04 || x || y [...] This encoding is compatible with the definition given in [SEC1]. If other conversion methods are defined in the future, a compliant application MUST NOT use a new format when in doubt that any recipient can support it. Consider, for example, that while both the public key and the per-recipient ECDH data structure, respectively defined in Sections 9 and 10, contain an encoded point field, the format changes to the field in Section 10 only affect a given recipient of a given message. For ed25519 we needed another conversion methods. 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 look at my.amazin.horse Fri Sep 15 11:38:31 2023 From: look at my.amazin.horse (Vincent Breitmoser) Date: Fri, 15 Sep 2023 11:38:31 +0200 Subject: gpg --export produces invalid EdDSA output - regression In-Reply-To: <87sf7fhm0e.fsf@jacob.g10code.de> References: <874jjxj6nr.fsf@jacob.g10code.de> <87led8j24k.fsf@jacob.g10code.de> <87sf7fhm0e.fsf@jacob.g10code.de> Message-ID: <65b5e716-7b36-1dd6-9c1a-9ba4bacb583f@my.amazin.horse> Hey Werner and list, On 15.09.23 10:35, Werner Koch via Gnupg-devel wrote: > The question is just which specification. GnuPG was the first to > implement ed25519 and then cross-tested this with RNP. You say "cross-testing" here to convey rigor, can you give some more insight on how exactly the cross-testing was performed? Did these tests produce any artifacts or documentation available to other developers? Cheers - V From heiko at schaefer.name Sun Sep 17 11:06:24 2023 From: heiko at schaefer.name (=?UTF-8?Q?Heiko_Sch=c3=a4fer?=) Date: Sun, 17 Sep 2023 11:06:24 +0200 Subject: gpg --export produces invalid EdDSA output - regression In-Reply-To: <87sf7fhm0e.fsf@jacob.g10code.de> References: <874jjxj6nr.fsf@jacob.g10code.de> <87led8j24k.fsf@jacob.g10code.de> <87sf7fhm0e.fsf@jacob.g10code.de> Message-ID: Hello Werner, list, On 9/15/23 10:35, Werner Koch via Gnupg-devel wrote: > That we decided to change our implementations in a > compatible(!) way had practical reasons for better inperoperability > between other protocols and hardware implementations. I'd be very interested to learn more about this. Could you point me to a resource where I can read more about what those interoperability issues were? Thanks and regards, :) Heiko From heiko at schaefer.name Sun Sep 17 10:57:04 2023 From: heiko at schaefer.name (=?UTF-8?Q?Heiko_Sch=c3=a4fer?=) Date: Sun, 17 Sep 2023 10:57:04 +0200 Subject: gpg --export produces invalid EdDSA output - regression In-Reply-To: <87sf7fhm0e.fsf@jacob.g10code.de> References: <874jjxj6nr.fsf@jacob.g10code.de> <87led8j24k.fsf@jacob.g10code.de> <87sf7fhm0e.fsf@jacob.g10code.de> Message-ID: Hello Werner, list, On 9/15/23 10:35, Werner Koch via Gnupg-devel wrote: > That we decided to change our implementations in a > compatible(!) way had practical reasons for better inperoperability > between other protocols and hardware implementations. I'd be very interested to learn more about this. Could you point me to a resource where I can read more about what those interoperability issues were? Thanks and regards, :) Heiko From gniibe at fsij.org Thu Sep 28 06:13:04 2023 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 28 Sep 2023 13:13:04 +0900 Subject: [PATCH v2] agent: fix tpm2d keytotpm handling In-Reply-To: <1a531df6c5ae6c6e8a4a9a5530733055948e5283.camel@HansenPartnership.com> References: <1a531df6c5ae6c6e8a4a9a5530733055948e5283.camel@HansenPartnership.com> Message-ID: <87il7vc4vj.fsf@akagi.fsij.org> Hello, James Bottomley wrote: > commit: 2783b786a ("agent: Do not overwrite a key file by a shadow key > file.") broke keytotpm because you can no longer overwrite a > non-shadowed secret key, now you must first delete it. Fix KEYTOTPM > by deleting the key before writing it. > > Signed-off-by: James Bottomley > --- > v2: update the logic around replacing the private key to actually do > the replacement. > > agent/divert-tpm2.c | 33 ++++++++++++++++++++++++++++----- > 1 file changed, 28 insertions(+), 5 deletions(-) Applied to master. --