- User Since
- Sep 29 2018, 10:37 AM (42 w, 1 d)
I applied the following with gpg-connect-agent --hex:
Fri, Jul 19
I do not wonder, that you face difficulties to reproduce it. It happened only with one card from my six cards; so five cards working fine. Therefore, I thought that this particular card was may dead at arrival and I contacted the vendor. They refused to replace it with the comment, it would be a well known issue. Do you know a test where I can demonstrate that the card is dead at arrival?
Thu, Jul 18
I use the internal driver.
All my keys are RSA 4096. It worked fine with OpenPGP smart cards and with two Yubikey 5. On all devices a set of RSA 4096 keys were geneated on the device itself. Only one card failed. But even the card which failed, generated at least the signature key in RSA 4096.
Wed, Jul 17
I should may add, that on the card which failed, only the signature key was generated and written to the card. The authentication and encryption keys could not be generated..
Tue, Jul 16
Wed, Jul 10
Tue, Jul 2
Thanks, this is excellent news! I´ll check it, if the new Mailvelope version is available and I´ll let you know about the outcome. If the new version is released, let me know!
May 16 2019
The problem could be narrowed as follows: According to Mailvelope Add-on, GnuPG must be installed for smart card support. Screenshots show that GnuPG is not recognized by Mailvelope. Of course actual versions off all programs were installed. Therefore, e-mails sent out ecrypted with public key work fine, because the public key is stored in Mailvelope. Is the encrypted message arrives and should be decrypted. Mailvelope does not find GnuPG and therefore, no private key. I´ll send some screenshots to you.
May 15 2019
May 2 2019
On think should be mentioned. Both accounts are IMAP, but the Posteo account has one particular feature. All inbound traffic from their server to my client (receiving e-mails) is encrypted with my own public S/MIME certificate (they call it "Eingangsverschlüsselung") so all non-encrypted e-mail will be treated between Posteo server and my client as S/MIME end-to -end encrypted e-mails. This is not the case with the t-online account (there it is just TLS encrypted). However, I believe a PGP signature verification should happen after S/MIME decryption on the client.
This account is IMAP, nothing special, I´ll send a screenshot from the add-ins by e-mail.
Well, I deinstalled gpg 3.1.7 and reinstalled it. For some reason my two gnupg smart cards work fine, but my two Yubikeys cannot be detected anymore (no such device). But in the last weeks, they were deteced, only the switching between Yubikey and Smart Card made some trouble. That they cannot be recognized is new and makes real trouble. If you think it would maybe helpful, I can submit a scdaemon.log file by e-mail.
The debug file will be sent by e-mail to you immediately. THANKS
Apr 30 2019
So long I change between smart cards, I can do it multiple times. If a Yubikey is recognized and a smart card follows next it will not work. Most recently I face also problems to detect the Yubikey (Message: no such device), but Smart Cards still working fine.
Did you get the screenshots from Thunderbird (works fine in both accounts) and Outlook (failure in one account)? If not, please provide e-mail address.
Apr 24 2019
Screenshots were sent by e-mail to you. Thunderbird and Outlook screenshots are different.
I am quite sure! Because, (1) I opened both mails on another computer were Thunderbird is installed. Both signatures can be verified on both accounts with Thunderbird. Both mails were sent out with PGP signature by HPI Identity Leak Checker Team, so the signature generally works fine. (2) If I save the key which is as asc file in the attachment (in the account which does not work) on computer and perform then a check of the signature, I receive a input / output error in Kleopatra. I will make some screenshots, and I´ll send it by mail to you.
Apr 18 2019
Apr 13 2019
By installation from version 2.3 an error occurred, I´ll send you a screenshot by e-mail. However, I have some comments to the current version which may also help: I have three keys, two on smart cards and one on a Yubikey. So long as only smart cards are used, it is no problem to change between the cards and they work fine. Problems occur, if a Yubikey comes in. (i) Not always a Yubikey is recognized by pressing F5. (ii) It the Yubikey is recognized and next a key from a smart card is needed, a computer restart is required.
I tried also command: gpgconf --kill gpg-agent
It was possible to change from smart card to Yubikey with the command. However, if the Yubikey 5 NFC was recognized, the only way to change back to the smart card was a restart of the computer.
Apr 8 2019
I´ll give it a try for sure! Probaly next weekend, so my feedback will be sent next week. Please, keep the file open. THANKS
After re-start, the smart card will be recognized in proper way and it works. I assume it has something to do with using Yubikey and smart cards with different keys alternatively. The Yubikey was not found originally, so I modified the following:
Kleopatra recognizes the smart card, shows the correct version number and keys in the "smart card - management" window. In the Keylist I can´t find the key. Currently GnuPG 2.2.15 is installed. Do you know then version 2.3. will be released?
Well, I can narrow the root case. A Yubikey 5 was successfull installed and can be used. Then I started to test the OpenPGP card. I recognized, that by pressing F5 in Kleopatara a change between YubiKey and Smart Card happens. However, if I test it via command line, Yubikey does not change, although it is dismounted and the smart card is inserted. Probably therefore, the private key cannot be found. It should be mentioned that I have a computer with integrated smart card reader. First I configured the card, then the Yubikey. I started to test the Yubikey first. Therefore, I believe it is a mess in detection of smart card / Yubikey if used parallel.
Apr 7 2019
Feb 27 2019
I agree! THANKS
Jan 9 2019
Indeed in view of this data, it seems to be that the problem occurs by Microsoft. It fits also with the fact, that all other signatures are working fine from my experience.
A pristine file I do not have, because every file passes GpgOL before displayed. I suggest, you subscribe to the service and if you de-install GpgOL, you should obtain a pristine file.
No, I can´t confirm it, I get no reason displayed. The key which I use is shown in my screenshot (I´ll send by e-mail)
I must make a correction of my earlier statement from today. The three Microsoft messages were not displayed in the same order on the screen on both machines. I must say, that on Outlook 2016 AND Thunderbird PGP verification still fails by "Microsoft Security Update Releases". It is the same situation as last year, nothing has been changed. I sent two files in EML format and some screenshots to A.Heinecke today.
Yesterday Microsoft issued three PGP signed mails. It is the first communication after MSRC confirmed failure of verification and promised to have internal procedures changed. I received those mails on two different machines, one equipped with Outlook 2016, the other with Thunderbird. Last year all messages failed on Outlook and Thunderbird, if the were issued from "Microsoft Security Update Releases".
Jan 7 2019
Please, provide e-mail address, then I´ll send it asap
Very strange, but I tried it by myself, after your mail. The same for me. However, I can offer you to send two mails to you as EML files, one works, the other not. I using GnuPG also for verification from BSI newsletter, it works fine there. The problem is only with newsletters from "Microsoft security update releases", other Microsoft security notifications can be verified as well.
Yes, GpgOL in version 2.3.2 fails to verify the original message, it is labeled as "not-secure". But it happens only to "Microsoft security update releases", not to other Microsoft Security Notifications which I receive on regular base. I contacted Microsoft Security Responce Center (MSRC) and they confirmed the failure of signature verification in this case. They were not aware about it, but checked it by them self after my mail. They had no explanation for that. Labeling the message as "not-secure" would may indicate that it would be altered in transport, but MSRC did not say that. Therefore, I still assume, that we have a bug in GnuPG.
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
Sure, I zipped the eml which failed and I´ll send it by e-mail to you
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.
Nov 18 2018
My problem isn´t linked to forwarding encrypted e-mails and / or attachments. It occurs by ordinary PGP mails WITH attachments which are not ASCII format. Encrypted e-mails without attachmoments or in ASCII format will be delivered.
Nov 13 2018
Default settings in Outlook are as following: (i) S/MIME encryption disabled, (ii) S/MIME signature enabled.
Nov 10 2018
Indeed, I use a S/MIME certificate in Outlook for signing by default all e-mails. However, if I intend to send a PGP mail, I manually disable this feature and I manually opt for PGP signature & encryption. I am sure, that this standard procedure applied in this case. Therefore, I am surprised, that the message appears.
Oct 22 2018
Thanks for the quick reply!
Oct 16 2018
I decided today to install the beta version and give it a try, because the final version is not yet released. I still facing major problems, see attachment. The mail will not be delivered, but Outlook does not crash as before.