I wrote this:
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
May 21 2020
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.
Aug 5 2019
Jul 19 2019
I am trying to reproduce your problem with my 3.3 card using my TTXS card reader.
Jul 18 2019
I use the internal driver.
Are you using pcscd (is that process running) or the internal driver.? Please try the latter if you are not already using it.
Jul 16 2019
It was rG07250279e7ec: * keyedit.c (keyedit_menu): Invisible alias "passwd" as "password". in 2004, which set default to rfc2440-text behavior.
And in 2007, the commit rGb550330067b6: * gpg.c (main): Disable --rfc2440-text and --force-v3-sigs by default. changed the default to no-rfc2440-text.
Jun 25 2019
I see. Thanks for your explanation.
Jun 24 2019
I see. Thus the problem is that IPWorksOpenPGP does not create proper OpenPGP private keys. I guess they use OpenSSL with their different CRT parameter style and do not convert them correctly. RFC-4880 says this in 5.5.3:
The secret key is this series of multiprecision integers: o MPI of RSA secret exponent d; o MPI of RSA secret prime value p; o MPI of RSA secret prime value q (p < q); o MPI of u, the multiplicative inverse of p, mod q.
May 17 2019
At the time the verification is done some output has already been written to the file 'signed'. When checking whether the deprecated abbreviated format
May 9 2019
May 6 2019
The digest algorithm used is computed based on the preferences in the key if encryption is also used. Thus this should always work and any decent key has sha256 in its preferences. In case sha1 has a higher precedence, as seen on old keys, --personal-digest-preferences can be used to prefer sha256. However, it is way better to fix the key. The easisies way to do that is to change the expiration date - then the new standard preferences will be used.
Apr 3 2019
Mar 28 2019
Thanks so much your helps.
With new version 3.1.6, I can generate key on Kleopatra tool and use key stored in smartcard.
Mar 27 2019
Mar 26 2019
There was indeed a problem. With a test card I could reproduce the issue and fix it.
Feb 22 2019
Jan 29 2019
Dec 28 2018
I contacted Microsoft Security Response Center (MSRC) in regard to this matter. They confirmed the failed PGP key verification, but have not yet any explanation for that.
Dec 21 2018
What are MS doing when they get it right, though? I'd look at the differences between those two to identify what they've messed up here.
Thanks. The mail is a standard, non-crypto mail with one attachment. That attachment is a TNEF file which has according to ytnef(1) just one file. That file has the name gpgolPGP.dat and contains a clearsigned message.
Sure, I zipped the eml which failed and I´ll send it by e-mail to you
Is it possible that you upload or send me a copy of such a mail (wk gnupg.org)? ZIP or tar the eml file and send it in an encrypted mail to me to make sure it won't be modified on the transport.
Dec 20 2018
I checked my mails in detail, and I can confirm that the error occurs only with "Microsoft security update releases". Indeed "Microsoft security advisory notification" and "Microsoft security update summary for..." will be verified correctly.
I agree. It also happens to me. But only with mails coming from "Microsoft security update releases". Mails coming form "Microsoft security advisory notification" and Microsoft security update summary for..." are ok and are signed by the same key. It could be some trouble in MS automated email treatment.
Nov 8 2018
Fair enough. Let's wait and see what others think.
Also consider that it is possible to change the key usage flags. Thus it will never be clear whether one has a fixed or unfixed public key. I'd like to close this bug because it is currently also discussed in the IETF WG.
Nov 5 2018
No info received.
Oct 30 2018
There is another argument for respecting the usage flags: it trims the admissible key space, if key ID in the PKESK packet is zero ('wild card') and thus all private keys have to be considered for decryption.
Oct 29 2018
I disagree, and you don't have to try to convince me, the decision is with werner. I just want to give my opinion:
Bug compatibility is nothing esoteric or bad especially for a general purpose backend tool like gnupg. Being open to accepting broken input is a good thing because it will mean that we can get people out of a "broken tool vendor lock in".
i agree with @Valodim that it would be better to not have a warning at all for an attempt to decrypt from secret key whose public key has never been marked as valid for encryption. A strict failure there (as with a strict failure for lack of mdc) is a better scenario than a warning. If the user controls the secret key and they decide they want to be able to decrypt with it, they should be able to mark it as decryption-capable (if that's really what they want) and retry. But this is an action only for experts.
The same *cannot* be said for a subkey that is marked specifically for certification or signing, and not for decryption.
I understand the real world requirement for decrypting messages that have been encrypted to a revoked or expired key.
I don't see a problem. If you have the private key you can and will use it. I guess your concern is an oracle?
Oct 18 2018
Dear aheinecke,
Hi Adam,
Oct 17 2018
Jun 24 2018
Feb 22 2018
Feb 6 2018
Nov 20 2017
To compute the key validity (trust) more information may be needed and we can only do that after the changes have been saved. Further, no-auto-chec-trustdb will anyway delay that computation until "gpg --check-trustdb" is run (e.g. by a cron job).
Sep 8 2017
success, thank you for the help!
In GnuPG 2.1, secret keys are under control of gpg-agent. Currently, it is not deleted by gpg frontend.
Please run:
$ gpg -K --with-keygrip
Sep 7 2017
Aug 27 2017
IIRC, rfc2440 did not forbid partial length encoding for key-material so gpg could use that. rfc4880 limits partial length encoding to non-key-material which causes this error message.
Aug 26 2017
Well, I'd expect gpg not to alter my digest/compression preferences when changing my cipher preferences and vice versa. So if a user's going to have to lose his previously set preferences for a key in this manner because that's the only reasonably viable way of maintaining backwards compatibility, I think it would be appropriate to let him know beforehand and also suggest that he set it all up at once (as I've so described above) so that nothing is lost in the process.
The way the setpref command works is implementation specific and thus the OpenPGP standard is irrelevant here
.
Are you requesting a change in the behaviour of the setpref command? That would not be easy to implement for backward compatibility.
Jul 27 2017
Well, iff we implement that for gpg we also need to implement it for gpgsm.
Jul 24 2017
A decision must be made what the desired behaviour should be.
Jun 22 2017
- marcus (Marcus Brinkmann) <noreply@dev.gnupg.org> [20170622 16:41]:
So, the default change 7y ago and the world didn't end. Closing this.
So, the default change 7y ago and the world didn't end. Closing this.
May 17 2017
Apr 7 2017
Mar 30 2017
Feb 14 2017
Tested this again with 2.1.18 and it works now as expected. Export secret key
just exports a key if it has no passphrase. So I think this issue can be marked
as resolved.
Sep 7 2016
It is a hack in OpenKeychain to allow the use of several devices. Frankly, I am
not sure whether this is really a good idea: The security is limited by the key
for the least secure device.
Sep 6 2016
So i've tested this locally with:
export GNUPGHOME=$(mktemp -d) gpg --quick-gen-key 'test user <test@example.org>' gpg --armor --export-secret-key 'test user <test@example.org>'
(choosing no passphrase during the prompts that come up during the quick-gen-key
step). The final export step works fine.
Can you show what steps you're taking that fail for you, Andre?
Sep 5 2016
I'm using latest master and I still can't export a secret key without passphrase.
And Justus also has not closed this bug or wrote that he commited something
more. So I think the 2.1.13 announcement was mistaken and this problem still
exists. (Or am I missing some option / need a different pinentry mode?)
Jul 14 2016
Jul 6 2016
We got it for 2.1: -f or --recipient-file