Page MenuHome GnuPG

OpenPGPProject
ActivePublic

Members

  • This project does not have any members.
  • View All

Recent Activity

Tue, Sep 14

werner added a comment to T5464: Failure to import Curve25519 ECDH secret subkey to the GnupG..

Thanks. I meanwhile pushed a fix to 2.3 so that a warning is shown if the low bits are set.

Tue, Sep 14, 3:01 PM · Support, gnupg, OpenPGP
onickolay added a comment to T5464: Failure to import Curve25519 ECDH secret subkey to the GnupG..

Thanks for the replies, this makes things clear. We'll update RNP to correctly set/unset those bits while saving a generated secret key and a way to fix up previously generated keys.

Tue, Sep 14, 2:18 PM · Support, gnupg, OpenPGP
werner added a comment to T5464: Failure to import Curve25519 ECDH secret subkey to the GnupG..

Right, as long as there is only one format in widespread use (based on a long existing 4880bis draft) only this format should go over the wire.
Thus, it is a matter how the key is exported. In cryptography you should never have several options - one clearly defined format is what you want. We have had enough trouble with PGP5 peculiarities but in that case their implementation had more users and thus GnuPG had to work around it. Not good, but there was no standard at all at this time.

Tue, Sep 14, 11:14 AM · Support, gnupg, OpenPGP
gniibe added a comment to T5464: Failure to import Curve25519 ECDH secret subkey to the GnupG..

@onickolay No sorry needed. It was me, who cannot answer promptly.

Tue, Sep 14, 9:23 AM · Support, gnupg, OpenPGP

Mon, Sep 13

onickolay added a comment to T5464: Failure to import Curve25519 ECDH secret subkey to the GnupG..

@gniibe sorry for pinging, but this issue gets attention as TB users (with RNP OpenPGP backend) cannot import to GnuPG EdDSA secret key which was generated by RNP since it doesn't tweak bits when storing or exporting a secret key.
Should we update RNP to tweak those bits during storage to be more compatible (given that those bits doesn't make any difference)?

Mon, Sep 13, 11:36 AM · Support, gnupg, OpenPGP

Aug 13 2021

werner changed the edit policy for OpenPGP.
Aug 13 2021, 11:11 PM

Aug 3 2021

werner added a project to T5539: Key generation on OpenPGP Version 3.4 card fails: can't replicate.
Aug 3 2021, 11:52 AM · can't replicate, OpenPGP, scd, Bug Report, gpg4win
werner triaged T5539: Key generation on OpenPGP Version 3.4 card fails as Normal priority.
Aug 3 2021, 11:48 AM · can't replicate, OpenPGP, scd, Bug Report, gpg4win

Jun 29 2021

onickolay added a comment to T5464: Failure to import Curve25519 ECDH secret subkey to the GnupG..

Do I correctly understand that issue will be resolved on GnuPG side by tweaking key bits before private-key import/and/or/operations?

Jun 29 2021, 11:19 AM · Support, gnupg, OpenPGP

Jun 25 2021

werner lowered the priority of T5464: Failure to import Curve25519 ECDH secret subkey to the GnupG. from High to Normal.

We should not support a different OID or representation of 22519 which will only lead to incompatibilities and trouble existing users. 25519 is in too widespread use than to allow for any changes.

Jun 25 2021, 9:15 AM · Support, gnupg, OpenPGP

Jun 24 2021

werner moved T5438: gpgme_op_keylist_from_data_start ignores GPGME_KEYLIST_MODE_SIGS from Backlog to For a future release on the gpgme board.
Jun 24 2021, 6:21 PM · OpenPGP, Bug Report, gpgme

Jun 2 2021

onickolay added a comment to T5464: Failure to import Curve25519 ECDH secret subkey to the GnupG..

@werner isn't it used just for the public key? The secret x25519 key, exported by GnuPG, looks as following (in the way it is stored in file):

Jun 2 2021, 5:11 PM · Support, gnupg, OpenPGP
werner updated subscribers of T5464: Failure to import Curve25519 ECDH secret subkey to the GnupG..

We invented the 0x40 compression flag to declare that as native curve point format. With the introduction of 448 things got more complicated due to the new IETF statdards for this curev. This is the reason for @gniibe's proposal for a Simple Octet String (SOS) as a new data type in OpenPGP.

Jun 2 2021, 5:06 PM · Support, gnupg, OpenPGP
onickolay added a comment to T5464: Failure to import Curve25519 ECDH secret subkey to the GnupG..

Investigated it more, and it looks problem is not in incorrect endianness. Exporting x25519 secret subkey from the GnuPG showed up that we still need to change byte order.
After some experiments I ended up with the following self-explaining code piece, which makes RNP-generated keys to work with GnuPG for import:

repeat:
    if (botan_privkey_create(&pr_key, "Curve25519", "", rng_handle(rng))) {
        goto end;
    }
    /* botan returns key in little-endian, while mpi is big-endian */
    if (botan_privkey_x25519_get_privkey(pr_key, keyle.data())) {
        goto end;
    }
    if ((keyle[31] != 0x45) || (keyle[0] != 0x40)) {
        botan_privkey_destroy(pr_key);
        goto repeat;
    }
    if (botan_privkey_export_pubkey(&pu_key, pr_key)) {
        goto end;
    }
Jun 2 2021, 5:04 PM · Support, gnupg, OpenPGP
onickolay added a comment to T5464: Failure to import Curve25519 ECDH secret subkey to the GnupG..

Thanks for investigations! Indeed, we do change byte order when storing/loading private key, as MPI should be big-endian, while curve25519 private key is little endian.
Do I correctly understand that we should store it in the MPI as it is (like with Ed25519)? It would be nice to clarify that in the RFC draft.
Another thing is that in my test even if byte order is not reversed in the secret key (including the attached test key), GnuPG still asks for password, reporting "error sending to agent: Bad passphrase".

Jun 2 2021, 11:47 AM · Support, gnupg, OpenPGP
dkg added a comment to T5464: Failure to import Curve25519 ECDH secret subkey to the GnupG..

The problem here appears to be that the "MPI" of the curve25519 secret key is not actually a standard-issue big-endian OpenPGP MPI -- it's an opaque bytestring expected to be passed to the underlying "native" implementation of x25519, in the same way that the secret key is handled for Ed25519.

Jun 2 2021, 1:35 AM · Support, gnupg, OpenPGP
dkg added a comment to T5464: Failure to import Curve25519 ECDH secret subkey to the GnupG..

investigating the subkey in python:

Jun 2 2021, 1:20 AM · Support, gnupg, OpenPGP
dkg added a comment to T5464: Failure to import Curve25519 ECDH secret subkey to the GnupG..

looks to me like you've got the byte ordering of the Curve25519 secret subkey reversed from the way that GnuPG expects it.

Jun 2 2021, 1:16 AM · Support, gnupg, OpenPGP
dkg added a comment to T5464: Failure to import Curve25519 ECDH secret subkey to the GnupG..

fwiw, gpg-agent complains that the keys don't match:

Jun 2 2021, 1:06 AM · Support, gnupg, OpenPGP

Jun 1 2021

werner triaged T5464: Failure to import Curve25519 ECDH secret subkey to the GnupG. as High priority.
Jun 1 2021, 3:46 PM · Support, gnupg, OpenPGP

May 17 2021

werner triaged T5438: gpgme_op_keylist_from_data_start ignores GPGME_KEYLIST_MODE_SIGS as High priority.

Due to tax issues, we can't accept a donation as return on service. However, we will fix bugs anyway if possible,

May 17 2021, 11:50 AM · OpenPGP, Bug Report, gpgme

Apr 27 2021

werner added a comment to T5412: Getting "Invalid digest algorithm", when trying to generate ECDH keys, in batch mode.

The curve is not defined to be used for ECDH (encryption); in fact it should in general only be used with the EdDSA
algorithm. You need to use "Key-Type: eddsa". Note that the EdDSA signing algorithm is different than the commonly used ECDSA signing algorithm.

Apr 27 2021, 2:39 PM · FAQ, gnupg, OpenPGP
masoudbahar added a comment to T5412: Getting "Invalid digest algorithm", when trying to generate ECDH keys, in batch mode.

Thanks for the quick response Werner. I knew I could use it with quick-gen-key and I’ve updated my config file to have it as default.
But, just for my understanding, is there a reason ed25519 cannot be used with full-gen-key and gen-key in batch mode?

Apr 27 2021, 12:13 PM · FAQ, gnupg, OpenPGP
werner closed T5412: Getting "Invalid digest algorithm", when trying to generate ECDH keys, in batch mode as Resolved.
Apr 27 2021, 8:34 AM · FAQ, gnupg, OpenPGP
werner edited projects for T5412: Getting "Invalid digest algorithm", when trying to generate ECDH keys, in batch mode, added: gnupg, FAQ; removed gnupg (gpg23), Bug Report.

You can't use ecdh with ed25519.

Apr 27 2021, 8:33 AM · FAQ, gnupg, OpenPGP
werner claimed T5412: Getting "Invalid digest algorithm", when trying to generate ECDH keys, in batch mode.
Apr 27 2021, 8:14 AM · FAQ, gnupg, OpenPGP

Apr 20 2021

neal closed T5403: Consider all Issuer subpackets when validating a signature as Invalid.
Apr 20 2021, 11:54 AM · OpenPGP, Feature Request
neal added a comment to T5403: Consider all Issuer subpackets when validating a signature.

I just realized that my example is incorrect. It doesn't make sense to support multiple issuer subpackets on self signatures. But it is useful to do so on binary signatures and third-party certifications. Here's a better example, which gpg correctly supports. As such, this issue should be closed. Sorry for the noise.

Apr 20 2021, 11:54 AM · OpenPGP, Feature Request
werner triaged T5403: Consider all Issuer subpackets when validating a signature as Low priority.
Apr 20 2021, 11:48 AM · OpenPGP, Feature Request

Aug 28 2020

gniibe added projects to T4710: Cannot use Secure PIN Entry for Reset Code: Documentation, Not A Bug.
Aug 28 2020, 6:48 AM · Not A Bug, Documentation, OpenPGP, scd, Bug Report

Aug 25 2020

werner closed T4421: import-export does not remove duplicated subkeys as Resolved.

I implemented subkey collapsing in 2.3. It is enabled by default but you can disable it it with

Aug 25 2020, 10:42 AM · Feature Request, OpenPGP, gnupg (gpg23)

Aug 20 2020

werner edited projects for T4879: GnuPG treats reordered OpenPGP certificates differently, added: gnupg (gpg23); removed gnupg (gpg22).
Aug 20 2020, 11:10 AM · gnupg (gpg23), OpenPGP, Bug Report

Aug 11 2020

werner closed T5020: Exclude 3DES Cipher and SHA1 Digest as Resolved.

OpenPGP (RFC-4880) requires support for 3DES and SHA-1 thus you can't disable them. However, they are not used in practice because the key preference guarantee the use of more modern algorithms,

Aug 11 2020, 1:59 PM · OpenPGP, gnupg, Not A Bug

Aug 5 2020

gniibe merged task T3763: ECDH - encryption with obfuscated size of the symmetric key into T4908: ECDH with AES-128 decryption failure when fully padded.
Aug 5 2020, 7:22 AM · OpenPGP, gnupg (gpg23)
gniibe added a comment to T3763: ECDH - encryption with obfuscated size of the symmetric key.

Since it was handled in T4908, this task is merged into that.

Aug 5 2020, 7:22 AM · OpenPGP, gnupg (gpg23)

Jul 15 2020

gniibe added a comment to T3763: ECDH - encryption with obfuscated size of the symmetric key.

@mbrinkers : I think that it was fixed in GnuPG 2.2.21 by T4908: ECDH with AES-128 decryption failure when fully padded.
It was unfortunate that this bug report didn't work to solve problem, with malformed data and discussion went to unrelated thing.

Jul 15 2020, 2:01 AM · OpenPGP, gnupg (gpg23)

Jul 14 2020

mbrinkers added a comment to T3763: ECDH - encryption with obfuscated size of the symmetric key.

I have run into an interoperability issue between BouncyCastle PGP (Java) library and gpg which seems to caused by key obfuscation.

Jul 14 2020, 2:59 PM · OpenPGP, gnupg (gpg23)

May 27 2020

gniibe added a comment to T4954: SOS representation and improvements in GnuPG.

In the SOS branch, rG1c4291c3951d: ecc-sos: Add special leading zero octet removal. should be reverted.
Instead, the S_KEY should be fixed up in read_key_file in findkey.c,
and merge_lists in protect.c.
(Then, no need to be fixed up in extract_private_key.)

May 27 2020, 11:57 AM · OpenPGP, gnupg
gniibe added a comment to T4956: agent: Discrepancy of handling MPI for the interpretation of signed and unsigned.

Exactly same problem is there in libgcrypt.
In the definitions of curves, it uses negative constant internally in some specific places, but for other parts, we have same problems.

May 27 2020, 3:08 AM · gpgagent, gnupg
gniibe updated the task description for T4956: agent: Discrepancy of handling MPI for the interpretation of signed and unsigned.
May 27 2020, 3:03 AM · gpgagent, gnupg
gniibe created T4956: agent: Discrepancy of handling MPI for the interpretation of signed and unsigned.
May 27 2020, 3:03 AM · gpgagent, gnupg

May 26 2020

gniibe added a comment to T4954: SOS representation and improvements in GnuPG.

I should concentrate the case of ECC, in particular, ECC with modern curves.
Removing leading zero from RSA/ECC/ELGamal assuming unsigned integer would result more work.

May 26 2020, 8:23 AM · OpenPGP, gnupg
gniibe added a comment to T4954: SOS representation and improvements in GnuPG.

In libgcrypt, we have another problem of GCRYSEXP_FMT_ADVANCED formatting, which is used by gpg-agent of GnuPG 2.3 with name-value list.

May 26 2020, 7:07 AM · OpenPGP, gnupg
gniibe added a comment to T4954: SOS representation and improvements in GnuPG.

Confusingly, in the SSH specification, it is signed MPI.
See RFC4251, for the definition of "mpint": https://tools.ietf.org/html/rfc4251#page-8

May 26 2020, 3:59 AM · OpenPGP, gnupg

May 25 2020

gniibe added a comment to T4954: SOS representation and improvements in GnuPG.

There are more places for clean up in GnuPG.
While "MPI" in OpenPGP specification is based on unsigned integer, the default "MPI" handling of GnuPG/Libgcrypt is signed. This difference matters internally.
Formatting by "%m" with libgcrypt, it may result prefixed by 0x00 (so that it represents unsigned value, even if scanned as signed).
And because of this, existing private keys in private-keys-v1.d may have this leading zero-byte.
But the counting bits don't count this byte.

May 25 2020, 7:27 AM · OpenPGP, gnupg

May 21 2020

gniibe added a comment to T4954: SOS representation and improvements in GnuPG.

Important interoperability issue:
OpenPGP implementations should implement:

  • Recovery of leading zero octets for Ed25519 key handling (secret part) and Ed25519 signature
May 21 2020, 7:01 AM · OpenPGP, gnupg
gniibe added a comment to T4954: SOS representation and improvements in GnuPG.

Better to paste directly:

# SOS representation
#
# Initially, it was intended as "Simply, Octet String", but 
# it is actually "Strange" Octet String.
#
May 21 2020, 6:52 AM · OpenPGP, gnupg
gniibe added a comment to T4954: SOS representation and improvements in GnuPG.

I wrote this:

May 21 2020, 6:51 AM · OpenPGP, gnupg
gniibe created T4954: SOS representation and improvements in GnuPG.
May 21 2020, 6:50 AM · OpenPGP, gnupg

Apr 17 2020

werner closed T4918: GnuPG cannot decrypt an ECDH-AES128 message encrypted to Alice's Key from draft-bre-openpgp-samples-00 as Resolved.

Sorry, I don't know what kind of sample data that is. The reference keys have been provided by the RFC6637 author and are part of GnuPG's test suite; see (gnupg/tests/openpgp/samplekeys/ecc-sample-*).

Apr 17 2020, 12:10 PM · OpenPGP