Aug 28 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 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
Since it was handled in T4908, this task is merged into that.
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
I have run into an interoperability issue between BouncyCastle PGP (Java) library and gpg which seems to caused by key obfuscation.
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.)
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 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
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
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:
Apr 17 2020
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
I can't find any places where it is interpreted as signed integer.
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
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
It is easy to explain:
Mar 13 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
Dec 23 2019
Dec 4 2019
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).
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
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 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 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.