In T5783#153879, @werner wrote:Sending a private key with just the local protection is not a good idea.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Feed Advanced Search
Advanced Search
Advanced Search
Mar 7 2022
Mar 7 2022
Jan 17 2022
Jan 17 2022
Sending a private key with just the local protection is not a good idea. It is better to export the key and then send it in an encrypted mail - for example in symmetric mode with a strong password.
• werner changed the edit policy for T5783: All s2k hardenings silently ignored when exporting private keys.
Jan 16 2022
Jan 16 2022
vitusb renamed T5783: All s2k hardenings silently ignored when exporting private keys from All s2k hardenings silently ignored when doin an export of private keys to All s2k hardenings silently ignored when exporting private keys.
vitusb raised the priority of T5783: All s2k hardenings silently ignored when exporting private keys from High to Needs Triage.
Jan 15 2022
Jan 15 2022
vitusb triaged T5783: All s2k hardenings silently ignored when exporting private keys as High priority.
Oct 13 2021
Oct 13 2021
Fixed in GnuPG 2.3.3.
I should have explained the context.
No, there is no discussion about this in the WG.
Oct 12 2021
Oct 12 2021
Is that really required? Should we wait what the conlusion of the WG will be?
I'm reading RFC5297, which says:
SIV can be used as a drop-in replacement for any specification that uses [RFC3394] or [RFC3217], including the aforementioned use. It is a more general purpose solution as it allows for associated data to be specified.
Oct 11 2021
Oct 11 2021
• werner renamed T5649: Issue better error message for invalid OpenPGP RSA keys from GnuPG randomly generates invalid RSA signatures if secret key has P > Q. to Issue better error message for invalid OpenPGP RSA keys.
Fix for this issue landed RNP master, and will be included to the RNP v0.16.0 release.
Within fix:
- new keys will be generated with correctly tweaked bits
- using secret key with non-tweaked bits would issue a warning
- CLI command --edit-key [--check-cv25519-bits | --fix-cv25519-bits] added, allowing to fix older key
Oct 10 2021
Oct 10 2021
As long as we can't replicate this, it does not make sense to keep this bug open. Please re-open it if you run into it again in a replicatable way.
Oct 6 2021
Oct 6 2021
Sep 29 2021
Sep 29 2021
Use of version 5 format for Ed448/X448 was pushed by rG86cb04a23d2b: gpg: Ed448 and X448 are only for v5 (for subkey)..
Sep 28 2021
Sep 28 2021
Bug in creating such a blob is fixed in rG08a3a4db27dc: kbx: A 20 byte fingerprint is right filled in version 2 blob..
Sep 22 2021
Sep 22 2021
Sep 20 2021
Sep 20 2021
• werner renamed T5609: keydb_get_keyblock failed with cv448 key from gpg: keydb_get_keyblock failed: Invalid object to keydb_get_keyblock failed with cv448 key .
Thanks for clarification, indeed attempt to decrypt data returns an error afterwards.
Well, while importing you get the warning:
Yes, for migration from GnuPG 2.0 reasons, a batch import delays the key checking (i.e. converting from OpenPGP to GnuPG internal format) to the first use. Thus you don't see an error immediately. But if you encrypt something , you won't be able to decrypt it again:
Thanks, Werner.
During further work on this got another issue:
Sep 17 2021
Sep 17 2021
Sep 14 2021
Sep 14 2021
Thanks. I meanwhile pushed a fix to 2.3 so that a warning is shown if the low bits are set.
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.
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.
@onickolay No sorry needed. It was me, who cannot answer promptly.
Sep 13 2021
Sep 13 2021
@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)?
Aug 13 2021
Aug 13 2021
Aug 3 2021
Aug 3 2021
• werner added a project to T5539: Key generation on OpenPGP Version 3.4 card fails: can't replicate.
Jun 29 2021
Jun 29 2021
Do I correctly understand that issue will be resolved on GnuPG side by tweaking key bits before private-key import/and/or/operations?
Jun 25 2021
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 24 2021
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 2 2021
Jun 2 2021
@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):
• 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.
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; }
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".
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.
investigating the subkey in python:
looks to me like you've got the byte ordering of the Curve25519 secret subkey reversed from the way that GnuPG expects it.
fwiw, gpg-agent complains that the keys don't match:
Jun 1 2021
Jun 1 2021
• werner triaged T5464: Failure to import Curve25519 ECDH secret subkey to the GnupG. as High priority.
May 17 2021
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,
Apr 27 2021
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.
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?
• 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 20 2021
Apr 20 2021
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.
Aug 28 2020
Aug 28 2020
• gniibe added projects to T4710: Cannot use Secure PIN Entry for Reset Code: Documentation, Not A Bug.
Aug 25 2020
Aug 25 2020
I implemented subkey collapsing in 2.3. It is enabled by default but you can disable it it with
Aug 20 2020
Aug 20 2020
• werner edited projects for T4879: GnuPG treats reordered OpenPGP certificates differently, added: gnupg (gpg23); removed gnupg (gpg22).
Aug 11 2020
Aug 11 2020
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 5 2020
Aug 5 2020
Since it was handled in T4908, this task is merged into that.
Jul 15 2020
Jul 15 2020
@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 14 2020
Jul 14 2020
I have run into an interoperability issue between BouncyCastle PGP (Java) library and gpg which seems to caused by key obfuscation.
May 27 2020
May 27 2020
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.)
• 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.
• gniibe updated the task description for T4956: agent: Discrepancy of handling MPI for the interpretation of signed and unsigned.
May 26 2020
May 26 2020
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.
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.
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 25 2020
May 25 2020
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 21 2020
May 21 2020
Important interoperability issue:
OpenPGP implementations should implement:
- Recovery of leading zero octets for Ed25519 key handling (secret part) and Ed25519 signature
Better to paste directly:
# SOS representation # # Initially, it was intended as "Simply, Octet String", but # it is actually "Strange" Octet String. #
I wrote this:
sos_representation.py3 KBDownload
Apr 17 2020
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 13 2020
Apr 13 2020
• gniibe added a comment to T4669: Key expiration time sometimes improperly interpreted as a signed 32-bit value.
I can't find any places where it is interpreted as signed integer.
Apr 8 2020
Apr 8 2020
It seems that the reference to PKCS#5 is correct. It is an issue of how to describe the case of more than 8-byte padding in OpenPGP.
Your example data is malformed, I suppose.
Apr 6 2020
Apr 6 2020
• werner added a project to T3763: ECDH - encryption with obfuscated size of the symmetric key: OpenPGP.
I also don't think that key size obfuscation is useful, after all the preferences of the key demand a certain key size.
Mar 16 2020
Mar 16 2020
• werner lowered the priority of T4879: GnuPG treats reordered OpenPGP certificates differently from High to Low.
It is easy to explain:
Mar 13 2020
Mar 13 2020
Jan 30 2020
Jan 30 2020
That means that the GnuPG Backend does not work. I do not think that the office update is the reason, me and others use GpgOL with the most recent versions of Office Pro Plus without issue.
Have you possibly modified you gnupg config files? If there is a bad value in there it would result in such an error.
Jan 9 2020
Jan 9 2020
Dec 23 2019
Dec 23 2019
• werner added a subtask for T4795: GUI to manage first party attestations: T4694: manage first-party attestations.
Dec 4 2019
Dec 4 2019
• werner triaged T4767: gpgme_signature_t exp_timestamp behaves differently for OpenPGP vs. CMS as Low priority.
dkg added a comment to T4767: gpgme_signature_t exp_timestamp behaves differently for OpenPGP vs. CMS.
Very few OpenPGP data signatures have an expiration time either, fwiw. I have never actually seen one in the wild, and no one that i know uses --ask-sig-expire or --default-sig-expire (it shows up in the cupt test suite and the apt test suite, but doesn't appear to be actually used by anything).
• werner added a comment to T4767: gpgme_signature_t exp_timestamp behaves differently for OpenPGP vs. CMS.
CMS signatures do not have a expiration time. Further the meaning of the expiration time of one of the certificates also depends on the validation model (shell or chain); thus a one-to-one relationship between these times is not possible.
Oct 15 2019
Oct 15 2019
Sep 25 2019
Sep 25 2019
For pinpadtest.py, you need to offer an option --add (adding dummy byte), when you are using Cherry ST-2xxx.
For pinpadtest.py, you need to offer an option --add (adding dummy byte), when you are using Cherry ST-2xxx.
It is not supported, by CCID protocol itself. So, it is not supported by scdaemon, and by any of card readers (which I know of), either.
It is not supported, by CCID protocol itself. So, it is not supported by scdaemon, and by any of card readers (which I know of), either.
Aug 23 2019
Aug 23 2019
• werner moved T4681: Allow non-OpenPGP cards with gpg 2.2 from Backlog to For next release on the gnupg (gpg22) board.
Aug 22 2019
Aug 22 2019
Note that rGd3f5d8544fdb needs to be backported to 2.2 but we will wait until we have better tested it.
Aug 21 2019
Aug 21 2019
Aug 12 2019
Aug 12 2019
I am in charge of editing the current OpenPGP draft, so I will for sure keep an eye on that issue. If would appreciate if you can post your report also to openpgp at ietf org.