From spam.trap.mailing.lists at gmail.com Sun Nov 1 00:45:32 2020 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Sat, 31 Oct 2020 23:45:32 +0000 Subject: ping - Governikus In-Reply-To: <5ACDAF2A-02CE-4337-852C-DDCFA76D9793@andrewg.com> References: <5ACDAF2A-02CE-4337-852C-DDCFA76D9793@andrewg.com> Message-ID: It is required and also automatically checked that my name 'Stefan Claas' in the UID matches the name in my ID-card. If I would enter in my pub key for example 'Paul Claas' or 'Stefan Class' as UID then my pub key would not be signed. They use the email address IMHO only to submit your certified pub key to your email account. I am aware that there is a second 'Stefan Claas' living in Germany but he would not have the same fingerprint as I would have. In case of doubt people could always prove to third parties, if requested, that one is the actual key holder, with a simple challenge/response. Regards Stefan On Sat, Oct 31, 2020 at 10:31 PM Andrew Gallagher wrote: > > > > On 31 Oct 2020, at 18:46, Stefan Claas via Gnupg-users wrote: > > > > I would like to make the following proposal that users using > > your certification service have the ability to upload pub keys > > for signing, which do not require an email address in the UID > > and that such public keys can be mailed on digital media > > to the (in a provided submission form) postal address. > > What is governikus certifying if there?s nothing identifiable in the user id? What use is it to a third party to see such a signature on a key? > > A > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From andrewg at andrewg.com Mon Nov 2 13:06:15 2020 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 2 Nov 2020 12:06:15 +0000 Subject: ping - Governikus In-Reply-To: References: <5ACDAF2A-02CE-4337-852C-DDCFA76D9793@andrewg.com> Message-ID: On 31/10/2020 23:45, Stefan Claas wrote: > I am aware that there is a second 'Stefan Claas' living in Germany > but he would not have the same fingerprint as I would have. In case > of doubt people could always prove to third parties, if requested, > that one is the actual key holder, with a simple challenge/response. This may be an acceptable edge case for one Stefan Claas, but maybe not for Stefan M?ller or Stefan Schmidt. Or even the other Stefan Claas, who may not appreciate you being able to more easily impersonate him. :-) If Governikus (or anyone else for that matter) were to start certifying ambiguous identities, it would devalue their name across the board. Why would they do that? -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Mon Nov 2 13:49:36 2020 From: wk at gnupg.org (Werner Koch) Date: Mon, 02 Nov 2020 13:49:36 +0100 Subject: Avoid recipient-compatibility SHA1 In-Reply-To: <20201030041054.GA959448@fullerene.field.pennock-tech.net> (Phil Pennock via Gnupg-users's message of "Fri, 30 Oct 2020 00:10:54 -0400") References: <20201030041054.GA959448@fullerene.field.pennock-tech.net> Message-ID: <874km7vs7z.fsf@wheatstone.g10code.de> On Fri, 30 Oct 2020 00:10, Phil Pennock said: > I just sent a message to N recipients, and I think one of them probably > has some preference algorithm in their key details, because this one > mail was signed using SHA1, not my defaults. Fixed: commit 15746d60d492f5792e4a179ab0a08801b4049695 Author: Werner Koch Date: Mon Nov 2 13:39:58 2020 +0100 gpg: Do not use weak digest algos if selected by recipient prefs. * g10/misc.c (is_weak_digest): New. (print_digest_algo_note): Use it here. * g10/sig-check.c (check_signature_end_simple): Use it. * g10/sign.c (hash_for): Do not use recipient_digest_algo if it is in the least of weak digest algorithm. -- If a message is signed and encrypted to several recipients, the to be used digest algorithm is deduced from the preferences of the recipient. This is so that all recipients are able to check the the signature. However, if the sender has a declared an algorithm as week, that algorithm shall not be used - in this case we fallback to the standard way of selecting an algorithm. Note that a smarter way of selecting the algo is to check this while figuring out the algorithm - this needs more testing and thus we do it the simple way. or in short if any of the preferences would lead to a weak algo the feature of selecting the digest algo from the preferences is disabled. I intend to put this also in to 2.2.24. > recipient. That's fine. I'd rather create pressure for people to fix > their systems to use modern cryptography than cater to their brokenness > with sensitive messages. People won't update their keys - that just does not work. Ignoring the preferences is a better way here. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From gnupg-users at spodhuis.org Mon Nov 2 14:15:32 2020 From: gnupg-users at spodhuis.org (Phil Pennock) Date: Mon, 2 Nov 2020 08:15:32 -0500 Subject: Avoid recipient-compatibility SHA1 In-Reply-To: <874km7vs7z.fsf@wheatstone.g10code.de> References: <20201030041054.GA959448@fullerene.field.pennock-tech.net> <874km7vs7z.fsf@wheatstone.g10code.de> Message-ID: <20201102131532.GA1475874@fullerene.field.pennock-tech.net> On 2020-11-02 at 13:49 +0100, Werner Koch via Gnupg-users wrote: > On Fri, 30 Oct 2020 00:10, Phil Pennock said: > > recipient. That's fine. I'd rather create pressure for people to fix > > their systems to use modern cryptography than cater to their brokenness > > with sensitive messages. > > People won't update their keys - that just does not work. Ignoring the > preferences is a better way here. First: thank you for the code changes! As to the people part: for a generic call to action, you're right. But that's not the social dynamic in play here. For a specific set of people who know each other, trying to communicate securely, if someone says "hey your key is too broken to use, please fix it, here's a command to run (which you should check for yourself), please do so and send us your new public key" ... then that works. In the generic case, there's a hypothetical reward requiring work now. In the specific case, it's a case of "you're getting cut out of this ongoing conversation which presumably matters to you, do this now to get back in". If the conversation really does matter to that person, then they will fix their key. I have gotten people to fix various problems on exactly this basis. For everyone I am not talking to? Not my business, not my problem. I can only issue advice and shrug when people ignore it. Now I just need a sane way to figure out which key caused this. :) Thanks, -Phil From spam.trap.mailing.lists at gmail.com Mon Nov 2 20:12:21 2020 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Mon, 2 Nov 2020 19:12:21 +0000 Subject: ping - Governikus In-Reply-To: References: <5ACDAF2A-02CE-4337-852C-DDCFA76D9793@andrewg.com> Message-ID: On Mon, Nov 2, 2020 at 12:10 PM Andrew Gallagher wrote: > > On 31/10/2020 23:45, Stefan Claas wrote: > > I am aware that there is a second 'Stefan Claas' living in Germany > > but he would not have the same fingerprint as I would have. In case > > of doubt people could always prove to third parties, if requested, > > that one is the actual key holder, with a simple challenge/response. > > This may be an acceptable edge case for one Stefan Claas, but maybe not > for Stefan M?ller or Stefan Schmidt. Or even the other Stefan Claas, who > may not appreciate you being able to more easily impersonate him. :-) > > If Governikus (or anyone else for that matter) were to start certifying > ambiguous identities, it would devalue their name across the board. Why > would they do that? You are correct, they would not do that. While I thought also about the possibility that here in Germany are for example thousands of M?ller or Meier etc. I could imagine that not only two of them bear the same first name. It would be interesting to get hold of them and then convince them to use a shared email account, while everybody of them would then have to generate their own key pair and then let it sign by Governikus. I think a solution to this problem could be PBKDF2 hashed data in the UID, but developing an OpenPGP certifying workflow could be a bit tricky. https://www.freecodeformat.com/pbkdf2.php Regards Stefan From spam.trap.mailing.lists at gmail.com Mon Nov 2 20:53:55 2020 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Mon, 2 Nov 2020 19:53:55 +0000 Subject: ping - Governikus In-Reply-To: References: <5ACDAF2A-02CE-4337-852C-DDCFA76D9793@andrewg.com> Message-ID: On Mon, Nov 2, 2020 at 7:12 PM Stefan Claas wrote: > I think a solution to this problem could be PBKDF2 hashed data > in the UID, but developing an OpenPGP certifying workflow could > be a bit tricky. > > https://www.freecodeformat.com/pbkdf2.php To be more precise, the name 'Stefan Claas' would be still readable in the UID but the additional hashed data would be displayed as a hash, like in the code example and it would have hashed additional data from my ID-card. Because the other Stefan Claas would not have the same hash string in the UID this could be a working solution. Regards Stefan From andrewg at andrewg.com Tue Nov 3 01:06:38 2020 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 3 Nov 2020 00:06:38 +0000 Subject: ping - Governikus In-Reply-To: References: Message-ID: <241B6B17-A294-4DCE-8F81-CABCCF661C4C@andrewg.com> > On 2 Nov 2020, at 19:55, Stefan Claas wrote: > > ?On Mon, Nov 2, 2020 at 7:12 PM Stefan Claas > wrote: > >> I think a solution to this problem could be PBKDF2 hashed data >> in the UID, but developing an OpenPGP certifying workflow could >> be a bit tricky. >> >> https://www.freecodeformat.com/pbkdf2.php > > To be more precise, the name 'Stefan Claas' would be still readable in the > UID but the additional hashed data would be displayed as a hash, like in > the code example and it would have hashed additional data from my ID-card. > > Because the other Stefan Claas would not have the same hash string in the > UID this could be a working solution. Aha, so what you?re looking for is a signature over a nonced, hashed ID but without the plaintext ID being attached - in which case do you even need the plaintext ?real name? at all? After all, if there are only two Stefan Claases in Germany you?ve already leaked far too much information for the subterfuge to be worth the effort. What?s the use case? A From spam.trap.mailing.lists at gmail.com Tue Nov 3 17:44:08 2020 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Tue, 3 Nov 2020 16:44:08 +0000 Subject: ping - Governikus In-Reply-To: <241B6B17-A294-4DCE-8F81-CABCCF661C4C@andrewg.com> References: <241B6B17-A294-4DCE-8F81-CABCCF661C4C@andrewg.com> Message-ID: On Tue, Nov 3, 2020 at 12:10 AM Andrew Gallagher wrote: > > > > On 2 Nov 2020, at 19:55, Stefan Claas wrote: > > > > ?On Mon, Nov 2, 2020 at 7:12 PM Stefan Claas > > wrote: > > > >> I think a solution to this problem could be PBKDF2 hashed data > >> in the UID, but developing an OpenPGP certifying workflow could > >> be a bit tricky. > >> > >> https://www.freecodeformat.com/pbkdf2.php > > > > To be more precise, the name 'Stefan Claas' would be still readable in the > > UID but the additional hashed data would be displayed as a hash, like in > > the code example and it would have hashed additional data from my ID-card. > > > > Because the other Stefan Claas would not have the same hash string in the > > UID this could be a working solution. > > Aha, so what you?re looking for is a signature over a nonced, hashed ID but without the plaintext ID being attached - in which case do you even need the plaintext ?real name? at all? After all, if there are only two Stefan Claases in Germany you?ve already leaked far too much information for the subterfuge to be worth the effort. What?s the use case? As we know OpenPGP compatible public key cryptography usually requires a UID, whether the ones we are used to or a freeform UID. My goal is to have a CA certified pubkey with only one UID and without an email address, so that the key pair can be universally been used, besides classic email, ie. Fax, Telephone, Radio, Blog post discussions, Bitmessage, File Transfer, Postcards, Letters, Social Media chats, Messengers and what not which all do not require an email address. In case of email it should be possible to use it for multiple email accounts or if email accounts change, to not edit the key or create a new key. Simply said, a certified multipurpose OpenPGP key for long term usage. Why the included Name and hash string? GnuPG users, I assume, are used to public keys including a name in the UID, for their keyring management and selecting keys with their MUA/NUA plug-ins. Since we mentioned that it can happen that many people bear the same name I thought/think it could be useful for certifying purposes that an additional hash string, composed from additional ID-card data, which can't be easily reversed, would be useful. Let's assume the following ... In case gnupg.com would expand their business and would also run a CA, I could simply send them per postal mail a CD, containing my pub key, with my name and the hash string and a photo of my ID-card. They simply could then compare the name on the key and photo plus in case of many Stefan Claases they could also verify the hash string by rehashing the data which I hashed from my ID-card, thus guaranteeing to third parties with their CA sig. that this universal public key, without an email address, belongs to me and not the other Stefan Claas. In case this would be not enough proof for the CA I could include on the CD an additional eIDAS signed .pdf document, including the fingerprint of my pub key. I also think that maybe many people would like to have a CA certified universal OpenPGP public key, without an email address. Regards Stefan From oz.tiram at gmail.com Tue Nov 3 22:28:28 2020 From: oz.tiram at gmail.com (Oz Tiram) Date: Tue, 3 Nov 2020 22:28:28 +0100 Subject: GPG agent forward on Debian: setting pinentry mode 'loopback' failed: Forbidden Message-ID: Apologies, I accidentally posted the complete SO question in my previous email. That was not my intention. I hope I can still find some answers with the help from subscribers of this list. Best wishes Oz -- --- Imagine there's no countries it isn't hard to do Nothing to kill or die for And no religion too Imagine all the people Living life in peace -------------- next part -------------- An HTML attachment was scrubbed... URL: From oz.tiram at gmail.com Tue Nov 3 21:29:23 2020 From: oz.tiram at gmail.com (Oz Tiram) Date: Tue, 3 Nov 2020 21:29:23 +0100 Subject: GPG agent forward on Debian: setting pinentry mode 'loopback' failed: Forbidden Message-ID: Hi, I spend quite sometime trying to set up gpg agent forwarding between two machines (running debian). But I can't get this work with the instructions from the gpg wiki. My ssh config: Host debian-remote Hostname 192.168.122.72 RemoteForward /run/user/1000/gnupg/S.gpg-agent /run/user/1000/gnupg/S.gpg-agent.extra ExitOnForwardFailure yes $ ssh -v -A debian-remote ... debug1: Remote connections from /run/user/1000/gnupg/S.gpg-agent:-2 forwarded to local address /run/user/1000/gnupg/S.gpg-agent.extra:-2 debug1: ssh_init_forwarding: expecting replies for 1 forwards debug1: channel 0: new [client-session] debug1: Requesting no-more-sessions at openssh.com debug1: Entering interactive session. debug1: pledge: network debug1: client_input_global_request: rtype hostkeys-00 at openssh.com want_reply 0 debug1: Remote: /home/debian/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding debug1: Remote: /home/debian/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding debug1: remote forward success for: listen /run/user/1000/gnupg/S.gpg-agent:-2, connect /run/user/1000/gnupg/S.gpg-agent.extra:-2 debug1: forwarding_success: all expected forwarding replies received debug1: Requesting authentication agent forwarding. ... Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Tue Nov 3 18:45:13 2020 from 192.168.122.202 $ Looks OK, so far. *Closed.* This question does not meet Stack Overflow guidelines . It is not currently accepting answers. ------------------------------ We don?t allow questions about general computing hardware and software on Stack Overflow. You can edit the question so it?s on-topic for Stack Overflow or post a new one on Super User . Closed 15 mins ago. (Private feedback for you) Background I spent quite some time trying to solve this problem without success. I have 2 Debian testing machine with GPG version: ~$ gpg --version gpg (GnuPG) 2.2.20 libgcrypt 1.8.6 GPG agent should be forwarded from one machine (local) to the other (remote). On the local machine, I have the following settings: ~$ cat .gnupg/gpg.conf use-agent pinentry-mode loopback ~$ cat .gnupg/gpg-agent.conf pinentry-program /usr/bin/pinentry no-grab default-cache-ttl 1800 enable-ssh-support allow-loopback-pinentry And also: Host debian-remote Hostname 192.168.122.72 RemoteForward /run/user/1000/gnupg/S.gpg-agent /run/user/1000/gnupg/S.gpg-agent.extra ExitOnForwardFailure yes On the remote machine: I set in /etc/ssh/sshd_config: StreamLocalBindUnlink yes I copied over pubring.kbx with: scp .gnupg/pubring.kbx 192.168.122.72:/home/debian/.gnupg/ Finally, I created an encrypted file with and copied it over: $ echo TEST | gpg --encrypt -r myUserId > out $ scp out debian-remote:~/out When I ssh to remote machine, I see the following: $ ssh -v -A debian-remote ... debug1: Remote connections from /run/user/1000/gnupg/S.gpg-agent:-2 forwarded to local address /run/user/1000/gnupg/S.gpg-agent.extra:-2 debug1: ssh_init_forwarding: expecting replies for 1 forwards debug1: channel 0: new [client-session] debug1: Requesting no-more-sessions at openssh.com debug1: Entering interactive session. debug1: pledge: network debug1: client_input_global_request: rtype hostkeys-00 at openssh.com want_reply 0 debug1: Remote: /home/debian/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding debug1: Remote: /home/debian/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding debug1: remote forward success for: listen /run/user/1000/gnupg/S.gpg-agent:-2, connect /run/user/1000/gnupg/S.gpg-agent.extra:-2 debug1: forwarding_success: all expected forwarding replies received debug1: Requesting authentication agent forwarding. ... Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Tue Nov 3 18:45:13 2020 from 192.168.122.202 $ Seems OK so far. However, I can't decrypt secrets using this agent: $ gpg --decrypt out debug1: client_input_channel_open: ctype forwarded-streamlocal at openssh.com rchan 3 win 2097152 max 32768 debug1: client_request_forwarded_streamlocal: request: /run/user/1000/gnupg/S.gpg-agent debug1: connect_next: host /run/user/1000/gnupg/S.gpg-agent.extra ([unix]:/run/user/1000/gnupg/S.gpg-agent.extra) in progress, fd=7 debug1: channel 1: new [forwarded-streamlocal] debug1: confirm forwarded-streamlocal at openssh.com debug1: channel 1: connected to /run/user/1000/gnupg/S.gpg-agent.extra port -2 gpg: encrypted with 2048-bit RSA key, ID 268570EF8062F280, created 2013-11-23 ... gpg: public key decryption failed: Inappropriate ioctl for device gpg: decryption failed: No secret key When I forward the regular socket with: Host debian-remote Hostname 192.168.122.72 RemoteForward /run/user/1000/gnupg/S.gpg-agent /run/user/1000/gnupg/S.gpg-agent ExitOnForwardFailure yes I can decrypt secrets as expected. However, I guess I should not be doing that. Hence, I'm still struggling what should be done to allow decrypting with GPG agents and extra socket on the remote hosts. Oddly, the above settings for gpg.conf and gpg-agent.conf are taken from the first result on DDG for: gpg Inappropriate ioctl for device, but I still get this error. I would appreciate any help here. Best regards, Oz -------------- next part -------------- An HTML attachment was scrubbed... URL: From stakanov at disroot.org Tue Nov 3 10:41:22 2020 From: stakanov at disroot.org (Stakanov) Date: Tue, 03 Nov 2020 10:41:22 +0100 Subject: A question about the status of the keyserver structure Message-ID: <8587313.y1p07l5mTE@roadrunner> I hope this is the correct list for this question: I tried to follow the instructions of https://www.mageia.org/it/downloads/get/?q=Mageia-7.1-x86_64.iso[1] were it says you can import the key to verify the iso. But kleopatra stays without reaction (no matter how many pools I join) and entropia at roadrunner:~> gpg --keyserver pool.sks-keyservers.net --recv-keys EDCA7A90 Now I remember time ago there was an issue of keyservers abused and the structure was halted. What is the current status and how can one download a signature as of today? Manually or with a "keyserverpage" on https or how does it work now? Thank you in advance. -------- [1] https://www.mageia.org/it/downloads/get/?q=Mageia-7.1-x86_64.iso -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrewg at andrewg.com Wed Nov 4 11:32:01 2020 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 4 Nov 2020 10:32:01 +0000 Subject: GPG agent forward on Debian: setting pinentry mode 'loopback' failed: Forbidden In-Reply-To: References: Message-ID: <3628b26a-6753-390e-9f6f-c2841951fc30@andrewg.com> Hi, Oz. Does /run/user/1000/gnupg/S.gpg-agent.extra exist on your local machine? To make it exist I had to add `extra-socket` to my gpg-agent.conf (I'm on gpg 2.2.12 from vanilla debian): ``` $ cat ~/.gnupg/gpg-agent.conf enable-ssh-support extra-socket /run/user/1000/gnupg/S.gpg-agent.extra ``` A. On 03/11/2020 20:29, Oz Tiram via Gnupg-users wrote: > ~$ cat .gnupg/gpg.conf > use-agent > pinentry-mode loopback > ~$ cat .gnupg/gpg-agent.conf > pinentry-program /usr/bin/pinentry > no-grab > default-cache-ttl 1800 > enable-ssh-support > allow-loopback-pinentry > > And also: > > Host debian-remote > Hostname 192.168.122.72 > RemoteForward /run/user/1000/gnupg/S.gpg-agent /run/user/1000/gnupg/S.gpg-agent.extra > ExitOnForwardFailure yes -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From andrewg at andrewg.com Wed Nov 4 12:38:46 2020 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 4 Nov 2020 11:38:46 +0000 Subject: ping - Governikus In-Reply-To: References: <241B6B17-A294-4DCE-8F81-CABCCF661C4C@andrewg.com> Message-ID: <2cbc198c-f484-f05a-9eda-a8fed4f725cf@andrewg.com> On 03/11/2020 16:44, Stefan Claas wrote: > My goal is to have a CA > certified pubkey with > only one UID and without an email address, so that the key pair can be > universally been > used, besides classic email, ie. Fax, Telephone, Radio, Blog post > discussions, Bitmessage, File Transfer, Postcards, Letters, Social > Media chats, Messengers and what not which all do not require an email > address. In case of email it should be possible to use it for multiple > email accounts or if email accounts change, to not edit the key or > create a new key. OK, but what is the meaning of a certification in this context? Taking just the email section of the above, if I want to send you an email, I can either get the key from you by some private means, or I can look up your key on e.g. a keyserver and check whether somebody I trust (e.g. Governikus) has certified that your key is valid for your email address. AIUI, you propose that Governikus certify that your key is valid for someone called "Stefan Claas", that they know which one, but they won't disclose that identity to me. How does that help me decide whether your key is valid? If I have to perform a second (manual?) verification step no matter what Governikus says, then it's a better use of my time to try that method first, and Governikus's sig has added nothing of value. The same argument can be repeated for the other communications methods above. If third-party certifications are not sufficient in your security model, then what's the point of them at all? Considering that the only reason we use third-party sigs is to cover the cases where other, stronger, verification schemes (physical meeting, phone calls etc.) are inappropriate or inconvenient. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From spam.trap.mailing.lists at gmail.com Wed Nov 4 16:33:28 2020 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Wed, 4 Nov 2020 15:33:28 +0000 Subject: ping - Governikus In-Reply-To: <2cbc198c-f484-f05a-9eda-a8fed4f725cf@andrewg.com> References: <241B6B17-A294-4DCE-8F81-CABCCF661C4C@andrewg.com> <2cbc198c-f484-f05a-9eda-a8fed4f725cf@andrewg.com> Message-ID: On Wed, Nov 4, 2020 at 11:42 AM Andrew Gallagher wrote: > > On 03/11/2020 16:44, Stefan Claas wrote: > > My goal is to have a CA > > certified pubkey with > > only one UID and without an email address, so that the key pair can be > > universally been > > used, besides classic email, ie. Fax, Telephone, Radio, Blog post > > discussions, Bitmessage, File Transfer, Postcards, Letters, Social > > Media chats, Messengers and what not which all do not require an email > > address. In case of email it should be possible to use it for multiple > > email accounts or if email accounts change, to not edit the key or > > create a new key. > > OK, but what is the meaning of a certification in this context? Taking > just the email section of the above, if I want to send you an email, I > can either get the key from you by some private means, or I can look up > your key on e.g. a keyserver and check whether somebody I trust (e.g. > Governikus) has certified that your key is valid for your email address. > > AIUI, you propose that Governikus certify that your key is valid for > someone called "Stefan Claas", that they know which one, but they won't > disclose that identity to me. How does that help me decide whether your > key is valid? If I have to perform a second (manual?) verification step > no matter what Governikus says, then it's a better use of my time to try > that method first, and Governikus's sig has added nothing of value. > > The same argument can be repeated for the other communications methods > above. If third-party certifications are not sufficient in your security > model, then what's the point of them at all? Considering that the only > reason we use third-party sigs is to cover the cases where other, > stronger, verification schemes (physical meeting, phone calls etc.) are > inappropriate or inconvenient. If people meet at a key signing party, or we both would meet in person, they/we usually check the name of the key holder and compare it with ID-cards and fingerprints of the keys. The email address has no certification value, because in case of a freeform UID they/we would not refuse to sign a key, I strongly assume. Regards Stefan From spam.trap.mailing.lists at gmail.com Wed Nov 4 16:56:11 2020 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Wed, 4 Nov 2020 15:56:11 +0000 Subject: ping - Governikus In-Reply-To: References: <241B6B17-A294-4DCE-8F81-CABCCF661C4C@andrewg.com> <2cbc198c-f484-f05a-9eda-a8fed4f725cf@andrewg.com> Message-ID: P.S. we should also think about these things, to make it more clear why no email address should be required. If people use primarily 'social' media for their communications, like facebook which has a profile option for a GnuPG pub key, why should that pub key bear an email address, once certified? Or take as another security example a YubiKey for 2FA. The key does not need an email address, if I log-in to facebook, Twitter, Google etc. with the same key(s). Or as an extreme example, my credit card, bank card, ID-card etc. have no email address either, when I authenticate with them globally. Regards Stefan From spam.trap.mailing.lists at gmail.com Wed Nov 4 17:21:30 2020 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Wed, 4 Nov 2020 16:21:30 +0000 Subject: A question about the status of the keyserver structure In-Reply-To: <8587313.y1p07l5mTE@roadrunner> References: <8587313.y1p07l5mTE@roadrunner> Message-ID: Hi, attached is the (hopefully proper) key. Regards Stefan On Tue, Nov 3, 2020 at 10:44 PM Stakanov via Gnupg-users wrote: > > I hope this is the correct list for this question: > > > > I tried to follow the instructions of > > https://www.mageia.org/it/downloads/get/?q=Mageia-7.1-x86_64.iso > > were it says you can import the key to verify the iso. > > But kleopatra stays without reaction (no matter how many pools I join) and > > entropia at roadrunner:~> gpg --keyserver pool.sks-keyservers.net --recv-keys EDCA7A90 > gpg: using character set 'utf-8' > gpg: ricezione dal keyserver fallita: Connessione rifiutata > > which is: reception of keyserver failed: connection refused. > > > > Now I remember time ago there was an issue of keyservers abused and the structure was halted. > > > > What is the current status and how can one download a signature as of today? Manually or with a "keyserverpage" on https or how does it work now? > > Thank you in advance. > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- A non-text attachment was scrubbed... Name: mageia.asc Type: application/octet-stream Size: 7727 bytes Desc: not available URL: From andrewg at andrewg.com Wed Nov 4 17:29:33 2020 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 4 Nov 2020 16:29:33 +0000 Subject: ping - Governikus In-Reply-To: References: <241B6B17-A294-4DCE-8F81-CABCCF661C4C@andrewg.com> <2cbc198c-f484-f05a-9eda-a8fed4f725cf@andrewg.com> Message-ID: On 04/11/2020 15:33, Stefan Claas wrote: > The email address has no certification value, because in > case of a freeform > UID they/we would not refuse to sign a key, I strongly assume. You could sign it if you want, that's not the issue. The issue is what value a third party would place on such a signature. > If people use primarily 'social' media for their communications, like > facebook which has a profile option for a GnuPG pub key, why should > that pub key bear an email address, once certified? It does not need to bear an email address, no. But it should bear a unique identifier of some kind. That could be a URL, or a Twitter handle, or anything sufficiently distinctive for the purposes for which a third party would expect to use the key. > Or take as another security example a YubiKey for 2FA. The key does > not need an email address, if I log-in to facebook, Twitter, Google etc. > with the same key(s). But Facebook, Twitter etc. verify your yubikey themselves. They are not relying upon a strange yubikey with a certification from a third party saying "this yubikey belongs to one Stefan Claas". > Or as an extreme example, my credit card, bank card, ID-card etc. > have no email address either, when I authenticate with them globally. Again, your credit card is certified by your bank because your bank owns your physical credit card. They *made* your credit card. When you use chip and pin in some shop, the card machine in the shop talks (indirectly) to your bank, which certifies its own property. This is not comparable to a third-party signature. The key phrase I keep repeating in all these arguments is "third party". For secure communication between two individuals who already have an established relationship, there is no need for third-party certification. I still don't see an actual use case for this. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From spam.trap.mailing.lists at gmail.com Wed Nov 4 17:54:18 2020 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Wed, 4 Nov 2020 16:54:18 +0000 Subject: ping - Governikus In-Reply-To: References: <241B6B17-A294-4DCE-8F81-CABCCF661C4C@andrewg.com> <2cbc198c-f484-f05a-9eda-a8fed4f725cf@andrewg.com> Message-ID: On Wed, Nov 4, 2020 at 4:32 PM Andrew Gallagher wrote: > > On 04/11/2020 15:33, Stefan Claas wrote: > > The email address has no certification value, because in > > case of a freeform > > UID they/we would not refuse to sign a key, I strongly assume. > > You could sign it if you want, that's not the issue. The issue is what > value a third party would place on such a signature. Well, If someone I know, or a CA, would sign such a key from you I would know that the key belongs to you, regardless for what the key is used for, i.e. in case you would sign here on the ML and with the option that your email account changes in the future. > > If people use primarily 'social' media for their communications, like > > facebook which has a profile option for a GnuPG pub key, why should > > that pub key bear an email address, once certified? > > It does not need to bear an email address, no. But it should bear a > unique identifier of some kind. That could be a URL, or a Twitter > handle, or anything sufficiently distinctive for the purposes for which > a third party would expect to use the key. For me a unique identifier would be the included hash, which I can't reverse, but which was signed along my name from the CA. [...] > The key phrase I keep repeating in all these arguments is "third party". > For secure communication between two individuals who already have an > established relationship, there is no need for third-party > certification. I still don't see an actual use case for this. Not sure why you don't see this, but let's say you or I would run a popular crypto etc. blog on a web page and people would be allowed to reply encrypted and you only provide a postal address (P.O.box address) instead of a spamable email address, I and probably the majority of readers would not need an email address in your UID and they would most likely trust your certified pub key more, like I would, compared to a pub key which bears no CA signature. There are more examples, but I think my point should be clear why people should have the option to get a CA certified public key without an email address, so that they can use the pub key as a multipurpose key, not bound to an email address, which can always change. Regards Stefan From oz.tiram at gmail.com Wed Nov 4 22:09:43 2020 From: oz.tiram at gmail.com (Oz Tiram) Date: Wed, 4 Nov 2020 22:09:43 +0100 Subject: GPG agent forward on Debian: setting pinentry mode 'loopback' failed: Forbidden In-Reply-To: References: <60006AB0-E311-4371-B55C-6EA7C33C2EE8@andrewg.com> Message-ID: Hi Andrew! I solved this issue finally! What a weird UI ... So ..., apparently, it's not enough to tell the gpg-agent which tty needs to be used via GPG_TTY! You also have to do: > I guess something is wrong on the local machine. > export GPG_TTY=$(tty) gpg-connect-agent updatestartuptty /bye >/dev/null Now, when I try to decrypt a file on the remote machine, pinentry opens a dialog on the local machine. If the password is properly typed, the decrypted file is printed out on the remote machine! This took quite a while to figure out! THANK YOU! Oz -- --- Imagine there's no countries it isn't hard to do Nothing to kill or die for And no religion too Imagine all the people Living life in peace -------------- next part -------------- An HTML attachment was scrubbed... URL: From spam.trap.mailing.lists at gmail.com Wed Nov 4 23:15:17 2020 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Wed, 4 Nov 2020 22:15:17 +0000 Subject: ping - Governikus In-Reply-To: References: <241B6B17-A294-4DCE-8F81-CABCCF661C4C@andrewg.com> <2cbc198c-f484-f05a-9eda-a8fed4f725cf@andrewg.com> Message-ID: On Wed, Nov 4, 2020 at 4:54 PM Stefan Claas wrote: [...] > Not sure why you don't see this, but let's say you or I would run a popular > crypto etc. blog on a web page and people would be allowed to reply > encrypted and you only provide a postal address (P.O.box address) instead > of a spamable email address, I and probably the majority of readers would > not need an email address in your UID and they would most likely trust > your certified pub key more, like I would, compared to a pub key which > bears no CA signature. There are more examples, but I think my point > should be clear why people should have the option to get a CA certified > public key without an email address, so that they can use the pub key > as a multipurpose key, not bound to an email address, which can always > change. Ok. as PoC I created such a key and used NIST guidelines to create the pbkdf2 hash and also saved as reference the parameters used, in case I had to send the pub key to another CA. Since Governikus needs an email address for returning the certified pub key, I used a 'noreply' disposal email address which (hopefully) everybody can use too. Additionally I can create a secp256k1 sub key so that I can also do Bitcoin transactions with my multi purpose key. :-) I am attaching the key to this message. The good thing now is in case I had to sign a message here on the ML I can use this key with this spam address and not get spam with my new real email address. :-) Regards Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: stefan_claas_multi_purpose_key.asc Type: application/octet-stream Size: 1247 bytes Desc: not available URL: From bangchuishan at outlook.com Fri Nov 6 14:51:33 2020 From: bangchuishan at outlook.com (Gao Xiaohui) Date: Fri, 6 Nov 2020 13:51:33 +0000 Subject: How to change the protect cipher algorithm and the digest algorithm of the secret key? In-Reply-To: References: , Message-ID: Hello, Excuse me,When using "gpg --list-packets [private secret key file]",it print "iter+salt S2K, algo: 7, SHA1 protection, hash: 2, salt: ****************", how to change "algo:7" and "hash:2"? I searched on Google, it use the "gpg --gen-key" or "gpg --edit-key" command with "--s2k-cipher-algo AES256" and "--s2k-digest-algo SHA512" options could change them, but I tested,It could not change them. Tell me the correct way please.Thank you very much. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jscott at posteo.net Sun Nov 8 02:27:57 2020 From: jscott at posteo.net (John Scott) Date: Sat, 07 Nov 2020 20:27:57 -0500 Subject: Clarification on getting a validity reason in GPGME Message-ID: <2919903.yKVeVyVuyW@t450> Hi I'm writing a tool using GPGSM and want to print signature validation information without reinventing the wheel with case statements, also for the sake of localization. These members in gpgme_signature_t [1] seem to be what I'm looking for: gpgme_validity_t validity The validity of the signature. gpgme_error_t validity_reason If a signature is not valid, this provides a reason why. so I can get a string from the gpgme_error_t, although it appears to be conditional on the signature being invalid. That's not clear since gpgme_validity_t is an enumeration of GPGME_VALIDITY_{UNKNOWN, UNDEFINED, NEVER, MARGINAL,FULL, ULTIMATE} I wonder if this is the case already and it's just a documentation quirk, but it'd be helpful if validity_reason were set to some value for good signatures, although this isn't technically an error. [1] https://www.gnupg.org/documentation/manuals/gpgme/Verify.html#Verify -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From pavel.hora at yandex.com Sat Nov 7 18:55:58 2020 From: pavel.hora at yandex.com (pavel hora) Date: Sat, 07 Nov 2020 18:55:58 +0100 Subject: cannot verify .sig Message-ID: <147211604771090@mail.yandex.com> An HTML attachment was scrubbed... URL: From johndoe65534 at mail.com Sun Nov 8 16:38:24 2020 From: johndoe65534 at mail.com (john doe) Date: Sun, 8 Nov 2020 16:38:24 +0100 Subject: cannot verify .sig In-Reply-To: <147211604771090@mail.yandex.com> References: <147211604771090@mail.yandex.com> Message-ID: <2d95f9c0-4079-c6e8-99ce-23e37307c841@mail.com> On 11/7/2020 6:55 PM, pavel hora via Gnupg-users wrote: > Hi, > I would like to use GPG to verify installation files (True Crypt this time to be > specific) that come with a signature .sig and PGP public key .asc. You should use veracrypt instead. > I have installed GPG 4 Win 3.1.13. > I have imported the public key. I have tried to verify the .exe with .sig, but > Kleopatra tells me the public key is not certified, so I try to certify it > myself, but I need my own key pair for that. So I try to build it, only it ends > with error, because "No agent running". > Now I assume that these issues happen because I prevent Kleopatra or GPG from > accessing the net, but then again, why should it do so for the tasks specified > above? I have used PGP in the past, long time ago, and it was always offline. > So my question is - can I still use GPG to check the signature of the file, pls? > And perhaps, why does GPG so desire the net access for my tasks? Does it work if you do: $ gpg --verify <*.sig> -- John Doe From kloecker at kde.org Sun Nov 8 16:50:33 2020 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Sun, 08 Nov 2020 16:50:33 +0100 Subject: Clarification on getting a validity reason in GPGME In-Reply-To: <2919903.yKVeVyVuyW@t450> References: <2919903.yKVeVyVuyW@t450> Message-ID: <3223422.C68FoQFQi0@breq> On Sonntag, 8. November 2020 02:27:57 CET John Scott via Gnupg-users wrote: > Hi > > I'm writing a tool using GPGSM and want to print signature validation > information without reinventing the wheel with case statements, also for the > sake of localization. These members in gpgme_signature_t [1] seem to be > what I'm looking for: > > gpgme_validity_t validity > The validity of the signature. > gpgme_error_t validity_reason > If a signature is not valid, this provides a reason why. > > so I can get a string from the gpgme_error_t, although it appears to be > conditional on the signature being invalid. That's not clear since > gpgme_validity_t is an enumeration of > GPGME_VALIDITY_{UNKNOWN, UNDEFINED, NEVER, MARGINAL,FULL, ULTIMATE} In the C++ bindings the equivalent for validity_reason is, more appropriately, called nonValidityReason. Also, validity refers to the (local) validity of the certificate that was used to make the signature. As far as I can see, in case of gpgsm validitity can take only three of the above mentioned 6 values: * FULL (if the signature is good; the signature cannot be good if there is a problem or an untrusted key in the certificate chain; in this case validity_reason is 0) * NEVER (if the certificate chain is invalid; in this case validity_reason gives more details) * UNDEFINED (if there was some other problem while validating the certificate chain). > I wonder if this is the case already and it's just a documentation quirk, > but it'd be helpful if validity_reason were set to some value for good > signatures, although this isn't technically an error. As mentioned above the variable is just named badly. It would better have been called non_validity_reason (as in the C++ binding). I'm wondering what kind of reason do you expect for a good signature? I mean there's exactly one reason for a good signature: The signature is "cryptographically correct" and the certificate that was used to make the signature is valid. In all other cases the signature is not good and then it makes sense to ask for the reason why it's not good. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: From kloecker at kde.org Sun Nov 8 16:57:53 2020 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Sun, 08 Nov 2020 16:57:53 +0100 Subject: cannot verify .sig In-Reply-To: <147211604771090@mail.yandex.com> References: <147211604771090@mail.yandex.com> Message-ID: <7855050.VAL3zy08H2@breq> On Samstag, 7. November 2020 18:55:58 CET pavel hora via Gnupg-users wrote: > Hi, > I would like to use GPG to verify installation files (True Crypt this time > to be specific) that come with a signature .sig and PGP public key .asc. I > have installed GPG 4 Win 3.1.13. > I have imported the public key. I have tried to verify the .exe with .sig, > but Kleopatra tells me the public key is not certified, so I try to certify > it myself, but I need my own key pair for that. So I try to build it, only > it ends with error, because "No agent running". Now I assume that these > issues happen because I prevent Kleopatra or GPG from accessing the net, > but then again, why should it do so for the tasks specified above? I have > used PGP in the past, long time ago, and it was always offline. So my > question is - can I still use GPG to check the signature of the file, pls? > And perhaps, why does GPG so desire the net access for my tasks? GnuPG consists of several applications (e.g. gpg as frontend called by Kleopatra and gpg-agent as backend) that talk to each other. I'm not sure whether this communication requires local network connections on Windows. On Linux it's done via socket connections. Anyway, maybe blocking network access also blocks the local communication between gpg and gpg-agent. You may have to allow local network access for gpg. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: From spam.trap.mailing.lists at gmail.com Sun Nov 8 22:08:25 2020 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Sun, 8 Nov 2020 21:08:25 +0000 Subject: GnuPG 'Lottery' - 'fun' with 256 bit keys Message-ID: Hi all, while reading about how many possible 256bit keys can be generated and and also reading about collisions I thought why not check with a Bitcoin blockchain explorer when one sees a 256 bit data string in HEX notation if it would have some balance? While looking at Werner's signatures, in postings here on the ML, I could see that his signature contains such data, when one checks his signature with a tool like this one: https://github.com/ConradIrwin/gpg-decoder and extracts the 'data:' string in the last row and feeds then the string in a program like this: https://github.com/matja/bitcoin-tool in order to generate the keys for checking. I already checked a couple of Werner's sigs but the balance from his signatures was always zero. Maybe someone of you will have luck in the future to find a proper 256 bit string. (chances however are *very very very* minimal to almost zero) P.S. this procedure means that if you have a publicity available 256bit string (in HEX notation) that you simply use it as a secret key to generate the proper keys for checking ... Regards Stefan From spam.trap.mailing.lists at gmail.com Sun Nov 8 23:08:17 2020 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Sun, 8 Nov 2020 22:08:17 +0000 Subject: GnuPG 'Lottery' - 'fun' with 256 bit keys In-Reply-To: References: Message-ID: On Sun, Nov 8, 2020 at 9:08 PM Stefan Claas wrote: > and extracts the 'data:' string in the last row and feeds correction, 'signature:' string. > then the string in a program like this: > > https://github.com/matja/bitcoin-tool In case people are Windows users and like to have an .exe, I compiled one: https://anonfiles.com/H4P7Xbncpd/bitcoin-tool_zip Regards Stefan From franek.wiertara at onet.eu Sun Nov 8 16:20:36 2020 From: franek.wiertara at onet.eu (franek.wiertara at onet.eu) Date: Sun, 08 Nov 2020 16:20:36 +0100 Subject: cannot verify .sig Message-ID: <111175881-b0ac1820736306e1ae0c517c17b072b7@pmq3v.m5r2.onet> Run "Perform Self-test" in "Settings" menu and make sure everything there is OK and running. One of the tests fails on my computer, that is "scdaemon" but I don't use smart cards and I believe I don't have to worry about it. I could probably turn it off in settings. If everything is OK, then you should be able to create a new key pair and then sign the public key. > Hi, > I would like to use GPG to verify installation files (True Crypt this time to be specific) that come with a signature .sig and PGP public key .asc. > I have installed GPG 4 Win 3.1.13. > I have imported the public key. I have tried to verify the .exe with .sig, but Kleopatra tells me the public key is not certified, so I try to certify it myself, but I need my own key pair for that. So I try to build it, only it ends with error, because "No agent running". > Now I assume that these issues happen because I prevent Kleopatra or GPG from accessing the net, but then again, why should it do so for the tasks specified above? I have used PGP in the past, long time ago, and it was always offline. > So my question is - can I still use GPG to check the signature of the file, pls? > And perhaps, why does GPG so desire the net access for my tasks? > > > Many thanks in advance for your kind help! > > > Best regards, > PH From stefanclaas at riseup.net Wed Nov 11 19:59:16 2020 From: stefanclaas at riseup.net (Stefan Claas) Date: Wed, 11 Nov 2020 10:59:16 -0800 Subject: GnuPG 'Lottery' - 'fun' with 256 bit keys In-Reply-To: References: Message-ID: <79560c4b73f91b8f0d57455509a65d9a@riseup.net> On 2020-11-08 22:08, Stefan Claas via Gnupg-users wrote: > P.S. this procedure means that if you have a publicity available > 256bit string (in HEX notation) that you simply use it as a secret > key to generate the proper keys for checking ... P.S. according to Bitcoin specs the 256bit HEX values needs to be in a proper range. And another idea, to expand the GnuPG 'Lottery'. How about this: Some cool GnuPG hackers write a program which checks publicity available SKS key server dumps for signature packets #2, the once that are only 256bit long, then saves those values in a text file, convert these values to Bitcoin key pairs and then uses a balance checker program, to see if a key has a balance (in the future)? Well, just a thought. At least it would give publicity available key server dumps an additional research value. Regards Stefan From wangtianjiao.wang959 at gmail.com Thu Nov 12 15:48:48 2020 From: wangtianjiao.wang959 at gmail.com (A NiceBoy) Date: Thu, 12 Nov 2020 09:48:48 -0500 Subject: How to change the protect cipher algorithm and the digest algorithm of the secret key? In-Reply-To: References: Message-ID: Hello Gao, Your question could be stated more clearly as in this bug report: https://dev.gnupg.org/T1800 1. The solution is also in this report. Just install gpg version 2.0.x, which prior to version 2.1, then run the following command to generate the key: > gpg2 --s2k-cipher-algo AES256 --s2k-digest-algo SHA512 --s2k-mode 3 --s2k-count 65000000 --gen-key Then export, using the s2k options in case they're needed here instead: > gpg2 --s2k-cipher-algo AES256 --s2k-digest-algo SHA512 --s2k-mode 3 --s2k-count 65000000 --export-secret-keys | gpg2 --list-packets Then you can see the algo changed to AES256 and digest changed to SHA512. 2. To modify the existing key, you still have to install gpg version 2.0.x first, which prior to version 2.1, then add the following options into your gpg.conf: > #----------------------------- > # algorithm and ciphers > #----------------------------- > # Limits the algorithms used > personal-cipher-preferences AES256 > personal-digest-preferences SHA512 > default-preference-list SHA512 SHA384 SHA256 RIPEMD160 AES256 TWOFISH BLOWFISH ZLIB BZIP2 ZIP Uncompressed > cipher-algo AES256 > digest-algo SHA512 > cert-digest-algo SHA512 > compress-algo ZLIB > disable-cipher-algo 3DES > #weak-digest SHA1 > s2k-cipher-algo AES256 > s2k-digest-algo SHA512 > s2k-mode 3 > s2k-count 65011712 Then reset the passphrase of the private key, using the above settings, then export the private key to file. Here is the output of command of --list-packets : > iter+salt S2K, algo: 9, SHA1 protection, hash: 10, salt: 12d208a128163024 > protect count: 65011712 (255) This idea comes from the links: https://blog.eleven-labs.com/en/openpgp-almost-perfect-key-pair-part-1 , https://security.stackexchange.com/a/90617 3. There is a small tool along with the command of --list-packets, called pgpdump which is available at http://www.mew.org/~kazu/proj/pgpdump/en/ , to provide more details of the private key file. Best regards On Fri, 6 Nov 2020 at 16:27, Gao Xiaohui via Gnupg-users wrote: > > Hello, > Excuse me,When using "gpg --list-packets [private secret key file]",it print "iter+salt S2K, algo: 7, SHA1 protection, hash: 2, salt: ****************", how to change "algo:7" and "hash:2"? > I searched on Google, it use the "gpg --gen-key" or "gpg --edit-key" command with "--s2k-cipher-algo AES256" and "--s2k-digest-algo SHA512" options could change them, but I tested,It could not change them. Tell me the correct way please.Thank you very much. > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From wangtianjiao.wang959 at gmail.com Thu Nov 12 15:27:26 2020 From: wangtianjiao.wang959 at gmail.com (A NiceBoy) Date: Thu, 12 Nov 2020 09:27:26 -0500 Subject: How to change the protect cipher algorithm and the digest algorithm of the secret key? In-Reply-To: References: Message-ID: Hello Gao, Your question could be stated more clearly as in this bug report: https://dev.gnupg.org/T1800 1. The solution is also in this report. Just install gpg version 2.0.x, which prior to version 2.1, then run the following command to generate the key: > gpg2 --s2k-cipher-algo AES256 --s2k-digest-algo SHA512 --s2k-mode 3 --s2k-count 65000000 --gen-key Then export, using the s2k options in case they're needed here instead: > gpg2 --s2k-cipher-algo AES256 --s2k-digest-algo SHA512 --s2k-mode 3 --s2k-count 65000000 --export-secret-keys | gpg2 --list-packets Then you can see the algo changed to AES256 and digest changed to SHA512. 2. To modify the existing key, you still have to install gpg version 2.0.x first, which prior to version 2.1, then add the following options into your gpg.conf: > #----------------------------- > # algorithm and ciphers > #----------------------------- > # Limits the algorithms used > personal-cipher-preferences AES256 > personal-digest-preferences SHA512 > default-preference-list SHA512 SHA384 SHA256 RIPEMD160 AES256 TWOFISH BLOWFISH ZLIB BZIP2 ZIP Uncompressed > cipher-algo AES256 > digest-algo SHA512 > cert-digest-algo SHA512 > compress-algo ZLIB > disable-cipher-algo 3DES > #weak-digest SHA1 > s2k-cipher-algo AES256 > s2k-digest-algo SHA512 > s2k-mode 3 > s2k-count 65011712 Then reset the passphrase of the private key, using the above settings, then export the private key to file. Here is the output of command of --list-packets : > iter+salt S2K, algo: 9, SHA1 protection, hash: 10, salt: 12d208a128163024 > protect count: 65011712 (255) This idea comes from the links: https://blog.eleven-labs.com/en/openpgp-almost-perfect-key-pair-part-1 , https://security.stackexchange.com/a/90617 3. There is a small tool along with the command of --list-packets, called pgpdump which is available at https://www.mew.org/~kazu/proj/pgpdump/en/ , to provide more details of the private key file. Best regards On Fri, 6 Nov 2020 at 16:27, Gao Xiaohui via Gnupg-users < gnupg-users at gnupg.org> wrote: > Hello, > Excuse me,When using "gpg --list-packets [private secret key file]",it > print "iter+salt S2K, algo: 7, SHA1 protection, hash: 2, salt: > ****************", how to change "algo:7" and "hash:2"? > I searched on Google, it use the "gpg --gen-key" or "gpg --edit-key" > command with "--s2k-cipher-algo AES256" and "--s2k-digest-algo SHA512" > options could change them, but I tested,It could not change them. Tell me > the correct way please.Thank you very much. > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Fri Nov 13 09:48:40 2020 From: wk at gnupg.org (Werner Koch) Date: Fri, 13 Nov 2020 09:48:40 +0100 Subject: How to change the protect cipher algorithm and the digest algorithm of the secret key? In-Reply-To: (A. NiceBoy via Gnupg-users's message of "Thu, 12 Nov 2020 09:27:26 -0500") References: Message-ID: <87v9e9prpz.fsf@wheatstone.g10code.de> On Thu, 12 Nov 2020 09:27, A NiceBoy said: > 1. The solution is also in this report. Just install gpg version 2.0.x, Don't! 2.0 reached end-of-life 3 years ago - there are no security fixes etc. You shall not use that version anymore. > Then you can see the algo changed to AES256 and digest changed to SHA512. If you want to convey secret keys do not rely on the passphrase protection of OpenPGP but use a secure transport channel. Which may be just a gpg encrypted file. The problem with the passphrase is that you need to transport a secure passphrase via another secured medium and in this case you can also a transport the secret key with a "weaker" passphrase. Whether you use SHA256 or SHA512 does not matter. The iteration count matters more but in any case you can't create better security from a weak passphrase - the iteration count is a failstop thing but not a proper cryptographic replacement for a weak passphrase. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From sirisha.gopigiri at ericsson.com Fri Nov 13 12:52:44 2020 From: sirisha.gopigiri at ericsson.com (Sirisha Gopigiri) Date: Fri, 13 Nov 2020 11:52:44 +0000 Subject: GPG Encryption/Decryption Failing Message-ID: Hi, We are trying to use SOPS+GPG to encrypt/decrypt yaml files and we have written some go wrapper using sops library to perform the required encryption/decryption. However when trying to execute this code the gpg library seems to be failing at keygeneration most of the time with the following error. failed to encrypt new data key with master key "681E3A89EB1DAFD36EB883120A73BB48E26694D8": could not encrypt data key with PGP key: golang.org/x/crypto/openpgp error: key with fingerprint 681E3A89EB1DAFD36EB883120A73BB48E26694D8 is not available in keyring and could not be retrieved from keyserver; GPG binary error: gpg binary failed with error: exit status 2, gpg: 681E3A89EB1DAFD36EB883120A73BB48E26694D8: skipped: No public key ?Seems like it is unable to fetch the public key, we are executing the code locally, so we are using the local public and private keys only. Though we can list the public key locally, we keep getting the above error quite frequently. However, the encryption/decryption is happening successfully the other times. Kindly let us know if we are missing anything. We are facing this error only with gpg 2.1.x version, gpg 1.4.x version seems to be working fine. Thank you in advance! Best Regards Sirisha Gopigiri -------------- next part -------------- An HTML attachment was scrubbed... URL: From 22h39 at tutanota.com Fri Nov 13 20:22:21 2020 From: 22h39 at tutanota.com (22h39) Date: Fri, 13 Nov 2020 20:22:21 +0100 (CET) Subject: Major problems with gpg and scdaemon, help highly appriciated Message-ID: I have been for the life of me unable to get gpg working with the contactless interface in my reader. How to reproduce: I'm using a REINERSCT Cyberjack standard RFID dual interface class 3 reader Simply take a Openpgp card and try to sign anything using the contactless interface. The drivers for the reader are here: https://www.reiner-sct.com/support/support-anfrage/?productGroup=77304735&product=77304820&q=driver&os=Linux#choice5 This is the card's list command that works on both interfaces: ``` Reader ...........: REINER SCT cyberJack RFID standard (9934036502) 00 00Application ID ...: D276000124010304BEEF000000000007Application type .: OpenPGPVersion ..........: 3.4Manufacturer .....: unknownSerial number ....: 00000000Name of cardholder: bac Language prefs ...: enSalutation .......: URL of public key : [not set]Login data .......: [not set]Signature PIN ....: not forcedKey attributes ...: rsa4096 rsa4096 rsa3072Max. PIN lengths .: 127 127 127PIN retry counter : 3 0 3Signature counter : 4KDF setting ......: offSignature key ....: 0353 CB0B 67EA AADE 39A5 B54F E8D6 EC89 1A92 2CE4 created ....: 2020-11-13 18:32:45Encryption key....: 03FC FCB0 49FF E397 337B 4B3F F9BE BBC9 CCB3 DEA9 created ....: 2020-11-13 18:32:45Authentication key: 526C E0A2 9AC4 F6B3 F6D1 2B67 BADC ADFD C2AC 5D9F created ....: 2020-11-13 18:32:45General key info..: pub rsa4096/E8D6EC891A922CE4 2020-11-13 Test keysec> rsa4096/E8D6EC891A922CE4 created: 2020-11-13 expires: never card-no: BEEF 00000000ssb> rsa3072/BADCADFDC2AC5D9F created: 2020-11-13 expires: never card-no: BEEF 00000000ssb> rsa4096/F9BEBBC9CCB3DEA9 created: 2020-11-13 expires: never card-no: BEEF 00000000``` This is pcsc_scan's output when I take out the card and insert it into the other slot ``` 0: REINER SCT cyberJack RFID standard (9934036502) 00 00 Fri Nov 13 19:43:53 2020 Reader 0: REINER SCT cyberJack RFID standard (9934036502) 00 00 Event number: 2 Card state: Card removed, Fri Nov 13 19:43:57 2020 Reader 0: REINER SCT cyberJack RFID standard (9934036502) 00 00 Event number: 3 Card state: Card inserted, ATR: 3B 94 95 81 01 46 54 56 01 C4ATR: 3B 94 95 81 01 46 54 56 01 C4+ TS = 3B --> Direct Convention+ T0 = 94, Y(1): 1001, K: 4 (historical bytes) TA(1) = 95 --> Fi=512, Di=16, 32 cycles/ETU 125000 bits/s at 4 MHz, fMax for Fi = 5 MHz => 156250 bits/s TD(1) = 81 --> Y(i+1) = 1000, Protocol T = 1 ----- TD(2) = 01 --> Y(i+1) = 0000, Protocol T = 1 -----+ Historical bytes: 46 54 56 01 Category indicator byte: 46 (proprietary format)+ TCK = C4 (correct checksum)Possibly identified card (using /usr/share/pcsc/smartcard_list.txt):3B 94 95 81 01 46 54 56 01 C4 blank J3H145 card (Other) Fri Nov 13 19:43:59 2020 Reader 0: REINER SCT cyberJack RFID standard (9934036502) 00 00 Event number: 4 Card state: Card removed, Fri Nov 13 19:44:02 2020 Reader 0: REINER SCT cyberJack RFID standard (9934036502) 00 00 Event number: 5 Card state: Card inserted, ATR: 3B 80 80 01 01ATR: 3B 80 80 01 01+ TS = 3B --> Direct Convention+ T0 = 80, Y(1): 1000, K: 0 (historical bytes) TD(1) = 80 --> Y(i+1) = 1000, Protocol T = 0 ----- TD(2) = 01 --> Y(i+1) = 0000, Protocol T = 1 -----+ Historical bytes: + TCK = 01 (correct checksum)Possibly identified card (using /usr/share/pcsc/smartcard_list.txt):3B 80 80 01 01 ISO 14443 Type B without historical bytes Electronic Passport Spanish passport (2012) Canadian Passport Venez_Prox ``` This is an attempt to sign on both of the interfaces. On contact it asks for the PIN using the reader's pinentry Contact: ``` h39 at Auriel ~/Downloads > gpg -vvv -s testfilegpg: using character set 'utf-8'gpg: writing to 'testfile.gpg'gpg: pinentry launched (51412 gnome3 1.1.0 /dev/pts/0 xterm-256color :1)gpg: RSA/SHA512 signature from: "E8D6EC891A922CE4 Test key" Contactless: h39 at Auriel ~/Downloads> gpg -vvv -s testfilegpg: using character set 'utf-8'File 'testfile.gpg' exists. Overwrite? (y/N) ygpg: writing to 'testfile.gpg'gpg: pinentry launched (51454 gnome3 1.1.0 /dev/pts/0 xterm-256color :1)gpg: signing failed: Conditions of use not satisfiedgpg: signing failed: Conditions of use not satisfied And finally here are pcscd's logs using --debug and first trying to sign on contacts then on contactless, the card PIN is 123456 03900506 [140366865852160] hotplug_libudev.c:655:HPEstablishUSBNotifications() USB Device add00000234 [140366865852160] hotplug_libudev.c:299:get_driver() Looking for a driver for VID: 0x0C4B, PID: 0x0500, path: /dev/bus/usb/001/01400000016 [140366865852160] hotplug_libudev.c:440:HPAddDevice() Adding USB device: REINER SCT cyberJack RFID standard00000054 [140366865852160] readerfactory.c:1074:RFInitializeReader() Attempting startup of REINER SCT cyberJack RFID standard (9934036502) 00 00 using /usr/lib/pcsc/drivers/libifd-cyberjack.bundle/Contents/Linux/libifd-cyberjack.so CYBERJACK: Started00001790 [140366865852160] readerfactory.c:950:RFBindFunctions() Loading IFD Handler 3.002092822 [140366865852160] readerfactory.c:391:RFAddReader() Using the pcscd polling thread07477005 [140366770595584] eventhandler.c:406:EHStatusHandlerThread() powerState: POWER_STATE_POWERED00000032 [140366770595584] eventhandler.c:423:EHStatusHandlerThread() Card inserted into REINER SCT cyberJack RFID standard (9934036502) 00 0000000026 [140366770595584] Card ATR: 3B 80 80 01 01 00400366 [140366770595584] eventhandler.c:482:EHStatusHandlerThread() powerState: POWER_STATE_UNPOWERED02424729 [140366770595584] eventhandler.c:358:EHStatusHandlerThread() Card Removed From REINER SCT cyberJack RFID standard (9934036502) 00 0001587089 [140366770595584] eventhandler.c:406:EHStatusHandlerThread() powerState: POWER_STATE_POWERED00000022 [140366770595584] eventhandler.c:423:EHStatusHandlerThread() Card inserted into REINER SCT cyberJack RFID standard (9934036502) 00 0000000010 [140366770595584] Card ATR: 3B 94 95 81 01 46 54 56 01 C4 00400575 [140366770595584] eventhandler.c:482:EHStatusHandlerThread() powerState: POWER_STATE_UNPOWERED03735577 [140366874249152] winscard_msg_srv.c:256:ProcessEventsServer() Common channel packet arrival00000031 [140366874249152] winscard_msg_srv.c:267:ProcessEventsServer() ProcessCommonChannelRequest detects: 1400000012 [140366874249152] pcscdaemon.c:133:SVCServiceRunLoop() A new context thread creation is requested: 1400000176 [140366762202880] winscard_svc.c:340:ContextThread() Authorized PC/SC client00000013 [140366762202880] winscard_svc.c:343:ContextThread() Thread is started: dwClientID=14, threadContext @0x560a0ee01f2000000011 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_VERSION from client 1400000007 [140366762202880] winscard_svc.c:373:ContextThread() Client is protocol version 4:400000004 [140366762202880] winscard_svc.c:396:ContextThread() CMD_VERSION rv=0x0 for client 1400000086 [140366762202880] winscard_svc.c:361:ContextThread() Received command: ESTABLISH_CONTEXT from client 1400000114 [140366762202880] winscard.c:215:SCardEstablishContext() Establishing Context: 0xA6D81FD00000006 [140366762202880] winscard_svc.c:461:ContextThread() ESTABLISH_CONTEXT rv=0x0 for client 1400000085 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_GET_READERS_STATE from client 1400000071 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_GET_READERS_STATE from client 1400000140 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CONNECT from client 1400000023 [140366762202880] winscard_svc.c:499:ContextThread() Authorized client for 'REINER SCT cyberJack RFID standard (9934036502) 00 00'00000009 [140366762202880] winscard.c:258:SCardConnect() Attempting Connect to REINER SCT cyberJack RFID standard (9934036502) 00 00 using protocol: 300000012 [140366762202880] readerfactory.c:821:RFReaderInfo() RefReader() count was: 100044154 [140366762202880] winscard.c:332:SCardConnect() power up complete.00000026 [140366762202880] Card ATR: 3B 94 95 81 01 46 54 56 01 C4 00000008 [140366762202880] winscard.c:352:SCardConnect() powerState: POWER_STATE_IN_USE00000007 [140366762202880] prothandler.c:107:PHSetProtocol() Attempting PTS to T=100011078 [140366762202880] winscard.c:430:SCardConnect() Active Protocol: T=100000023 [140366762202880] winscard.c:456:SCardConnect() hCard Identity: 5ed3ae4700000009 [140366762202880] winscard.c:518:SCardConnect() UnrefReader() count was: 200000010 [140366762202880] winscard_svc.c:513:ContextThread() CONNECT rv=0x0 for client 1400000135 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CONTROL from client 1400000018 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000025 [140366762202880] winscard.c:1359:SCardControl() UnrefReader() count was: 200000005 [140366762202880] winscard_svc.c:735:ContextThread() CONTROL rv=0x0 for client 1400000102 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_GET_READERS_STATE from client 1400000108 [140366762202880] winscard_svc.c:361:ContextThread() Received command: STATUS from client 1400000012 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000004 [140366762202880] winscard.c:1300:SCardStatus() UnrefReader() count was: 200000004 [140366762202880] winscard_svc.c:632:ContextThread() STATUS rv=0x0 for client 1400000073 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 1400000008 [140366762202880] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 1400000077 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 1400000009 [140366762202880] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 1400000076 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000011 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000007 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000007 [140366762202880] APDU: 00 A4 00 0C 02 3F 00 00184823 [140366762202880] SW: 6A 86 00000020 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000007 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000135 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000021 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000006 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000006 [140366762202880] APDU: 00 A4 04 00 06 D2 76 00 01 24 01 00015298 [140366762202880] SW: 90 00 00000020 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000006 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000136 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000021 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000006 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000006 [140366762202880] APDU: 00 CA 00 4F 00 00016731 [140366762202880] SW: D2 76 00 01 24 01 03 04 BE EF 00 00 00 00 00 07 90 00 00000022 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000013 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000113 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000023 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000008 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000008 [140366762202880] APDU: 00 CA 5F 52 00 00015652 [140366762202880] SW: 00 C1 C5 73 C0 01 80 05 90 00 90 00 00000019 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000011 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000147 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000025 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000010 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000010 [140366762202880] APDU: 00 CA 00 C4 00 00017123 [140366762202880] SW: 01 7F 7F 7F 03 00 03 90 00 00000019 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000007 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000114 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000021 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000005 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000006 [140366762202880] APDU: 00 CA 00 6E 00 00047584 [140366762202880] SW: 6E 81 D9 4F 10 D2 76 00 01 24 01 03 04 BE EF 00 00 00 00 00 07 5F 52 0A 00 C1 C5 73 C0 01 80 05 90 00 73 81 B7 C0 0A FF 03 00 20 04 80 00 FF 00 00 C1 06 01 10 00 00 11 03 C2 06 01 10 00 00 11 03 C3 06 01 0C 00 00 11 03 C4 07 01 7F 7F 7F 03 00 03 C5 3C 03 53 CB 0B 67 EA AA DE 39 A5 B5 4F E8 D6 EC 89 1A 92 2C E4 03 FC FC B0 49 FF E3 97 33 7B 4B 3F F9 BE BB C9 CC B3 DE A9 52 6C E0 A2 9A C4 F6 B3 F6 D1 2B 67 BA DC AD FD C2 AC 5D 9F C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 5F AE D1 4D 5F AE D1 4D 5F AE D1 4D 90 00 00000022 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000009 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000115 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000014 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000005 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000004 [140366762202880] APDU: 00 CA 7F 74 00 00012896 [140366762202880] SW: 6A 88 00000018 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000006 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000097 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000021 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000006 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000005 [140366762202880] APDU: 00 CA 00 5E 00 00011747 [140366762202880] SW: 90 00 00000021 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000008 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000086 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000018 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000008 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000008 [140366762202880] APDU: 00 CA 00 6E 00 00047658 [140366762202880] SW: 6E 81 D9 4F 10 D2 76 00 01 24 01 03 04 BE EF 00 00 00 00 00 07 5F 52 0A 00 C1 C5 73 C0 01 80 05 90 00 73 81 B7 C0 0A FF 03 00 20 04 80 00 FF 00 00 C1 06 01 10 00 00 11 03 C2 06 01 10 00 00 11 03 C3 06 01 0C 00 00 11 03 C4 07 01 7F 7F 7F 03 00 03 C5 3C 03 53 CB 0B 67 EA AA DE 39 A5 B5 4F E8 D6 EC 89 1A 92 2C E4 03 FC FC B0 49 FF E3 97 33 7B 4B 3F F9 BE BB C9 CC B3 DE A9 52 6C E0 A2 9A C4 F6 B3 F6 D1 2B 67 BA DC AD FD C2 AC 5D 9F C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 5F AE D1 4D 5F AE D1 4D 5F AE D1 4D 90 00 00000039 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000019 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000196 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000037 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000013 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000013 [140366762202880] APDU: 00 CA 00 6E 00 00047564 [140366762202880] SW: 6E 81 D9 4F 10 D2 76 00 01 24 01 03 04 BE EF 00 00 00 00 00 07 5F 52 0A 00 C1 C5 73 C0 01 80 05 90 00 73 81 B7 C0 0A FF 03 00 20 04 80 00 FF 00 00 C1 06 01 10 00 00 11 03 C2 06 01 10 00 00 11 03 C3 06 01 0C 00 00 11 03 C4 07 01 7F 7F 7F 03 00 03 C5 3C 03 53 CB 0B 67 EA AA DE 39 A5 B5 4F E8 D6 EC 89 1A 92 2C E4 03 FC FC B0 49 FF E3 97 33 7B 4B 3F F9 BE BB C9 CC B3 DE A9 52 6C E0 A2 9A C4 F6 B3 F6 D1 2B 67 BA DC AD FD C2 AC 5D 9F C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 5F AE D1 4D 5F AE D1 4D 5F AE D1 4D 90 00 00000028 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000008 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000101 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000016 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000005 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000006 [140366762202880] APDU: 00 CA 00 6E 00 00047566 [140366762202880] SW: 6E 81 D9 4F 10 D2 76 00 01 24 01 03 04 BE EF 00 00 00 00 00 07 5F 52 0A 00 C1 C5 73 C0 01 80 05 90 00 73 81 B7 C0 0A FF 03 00 20 04 80 00 FF 00 00 C1 06 01 10 00 00 11 03 C2 06 01 10 00 00 11 03 C3 06 01 0C 00 00 11 03 C4 07 01 7F 7F 7F 03 00 03 C5 3C 03 53 CB 0B 67 EA AA DE 39 A5 B5 4F E8 D6 EC 89 1A 92 2C E4 03 FC FC B0 49 FF E3 97 33 7B 4B 3F F9 BE BB C9 CC B3 DE A9 52 6C E0 A2 9A C4 F6 B3 F6 D1 2B 67 BA DC AD FD C2 AC 5D 9F C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 5F AE D1 4D 5F AE D1 4D 5F AE D1 4D 90 00 00000025 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000007 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000208 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 1400000020 [140366762202880] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 1400001122 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 1400000018 [140366762202880] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 1400000052 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 1400000011 [140366762202880] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 1400000085 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 1400000018 [140366762202880] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 1400000618 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000024 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000009 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000009 [140366762202880] APDU: 00 CA 00 6E 00 00047574 [140366762202880] SW: 6E 81 D9 4F 10 D2 76 00 01 24 01 03 04 BE EF 00 00 00 00 00 07 5F 52 0A 00 C1 C5 73 C0 01 80 05 90 00 73 81 B7 C0 0A FF 03 00 20 04 80 00 FF 00 00 C1 06 01 10 00 00 11 03 C2 06 01 10 00 00 11 03 C3 06 01 0C 00 00 11 03 C4 07 01 7F 7F 7F 03 00 03 C5 3C 03 53 CB 0B 67 EA AA DE 39 A5 B5 4F E8 D6 EC 89 1A 92 2C E4 03 FC FC B0 49 FF E3 97 33 7B 4B 3F F9 BE BB C9 CC B3 DE A9 52 6C E0 A2 9A C4 F6 B3 F6 D1 2B 67 BA DC AD FD C2 AC 5D 9F C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 5F AE D1 4D 5F AE D1 4D 5F AE D1 4D 90 00 00000029 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000010 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400002711 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000022 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000008 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000008 [140366762202880] APDU: 00 CA 00 7A 00 00015633 [140366762202880] SW: 93 03 00 00 05 90 00 00000021 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000007 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000178 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000023 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000009 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000008 [140366762202880] APDU: 00 CA 00 C4 00 00017131 [140366762202880] SW: 01 7F 7F 7F 03 00 03 90 00 00000021 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000007 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000097 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000015 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000005 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000005 [140366762202880] APDU: 00 CA 00 65 00 00018460 [140366762202880] SW: 5B 10 74 65 73 74 3C 3C 63 61 72 64 68 6F 6C 64 65 72 5F 2D 02 65 6E 5F 35 01 30 90 00 00000021 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000007 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400054002 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CONTROL from client 1400000060 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 103264154 [140366762202880] winscard.c:1359:SCardControl() UnrefReader() count was: 200000010 [140366762202880] winscard_svc.c:735:ContextThread() CONTROL rv=0x0 for client 1400000625 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000009 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000002 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000007 [140366762202880] APDU: 00 2A 9E 9A 53 30 51 30 0D 06 09 60 86 48 01 65 03 04 02 03 05 00 04 40 D7 32 A1 3D FB 5D 89 B4 50 AD E8 59 02 54 FF D0 D6 B9 EE F6 AF 53 E7 9A A9 1E 6A CC 2B D4 A0 2E EB 7F 7A 9C EA 90 2E 0D 0D B3 8D 71 C4 A9 3B BB F0 53 4A 8F 58 D4 0E 2F 5B 12 23 8C A4 55 AF 63 00 01108360 [140366762202880] SW: 0A 09 22 41 94 1A C4 5C AC 26 D2 E7 60 83 5B A1 C4 4D 0C 5A 57 FD 3D EC E8 73 30 44 89 11 09 CE A6 0C 95 A7 6C 80 EC 7C 3A 9B 5F B6 70 C5 D1 01 F4 D6 2E D1 AB 84 58 F3 48 3D D2 9A 75 C7 F2 15 D3 B6 28 43 63 0F 7B 7F 8D 4F D6 6C 5A 83 69 80 8B 0C 98 66 8A 9D 08 BE 91 98 3A 65 BF FE 64 9B 4C 23 83 C4 26 C1 F7 8E F5 9A 46 10 FE 05 05 FD 97 C1 8C A3 80 A1 97 F5 C3 82 AA 80 CA D9 DE FB DE 4A 9F 0A 87 49 6B A7 CE E6 74 3B 53 8D 0A FC C9 64 72 FC FB 01 06 97 39 1B A3 8B CE A8 43 6C DD E6 F1 B4 C3 C8 99 FC AC 89 22 CB 2C E4 58 00 4F C4 9F 19 45 35 D9 47 98 07 F1 13 6F E9 86 1E B2 42 25 D3 EE C9 01 53 89 FC BD FE B6 96 8B 07 42 BE 1E 68 84 B4 E7 39 CA CA E2 62 AF DC 0A 2B 85 D5 99 CE 44 33 6A 93 AF D4 32 10 F2 F4 DB 57 46 C4 57 76 57 9F F2 7F D6 E4 F8 03 01 64 61 22 61 FF 00000026 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000012 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000150 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000025 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000006 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000007 [140366762202880] APDU: 00 C0 00 00 FF 00032566 [140366762202880] SW: 31 52 FF 43 66 DF 62 16 2E D1 50 91 18 4F B9 99 36 90 67 CC 9F A1 85 54 11 D4 4E 1A E5 F0 2E 88 E0 D1 CB 4F 45 9E 77 5D 1A 2C 8B 91 65 2D BB DA 97 92 F1 C3 17 87 43 52 06 EE FE FC B1 8B AC 48 C8 79 19 C0 C5 E6 3F C5 31 94 76 33 63 1D 1E B1 F5 8F CE 81 BA 49 3E 60 54 16 20 5E 9C 19 6F 6E 37 5E 96 81 9C 69 A2 E7 EF 5D E6 09 5D 42 C1 29 FC B6 90 7A 9D EA 91 89 16 4F 8E 1A F4 CB 3F 3D CE 9F 6B 72 6B A4 9A E9 25 DE AC AB 01 F7 82 F7 69 B3 B7 37 E9 2C 82 11 A1 51 03 22 FF 2A 12 B4 2D 54 E8 41 A8 63 F6 52 A4 AE 78 C3 26 A2 7F 50 0F 99 F7 A5 36 BD 44 94 0B 36 5C 9D DE CD 04 63 85 22 6E 8F 9A CB 98 18 3D 39 29 EC C6 4C 0C 7E AD 69 25 1E 1B 32 94 20 5F CA EE 1A C8 35 A6 2D C7 5D 6B 8A 46 FA C5 24 21 69 90 D5 64 4C 74 79 F2 C0 4E 12 5C EF 16 3E 9D 1F 65 E7 2C AF E2 61 01 00000033 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000020 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000174 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000036 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000010 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000009 [140366762202880] APDU: 00 C0 00 00 01 00010334 [140366762202880] SW: F6 90 00 00000019 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000007 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000191 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 1400000019 [140366762202880] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 1400001105 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 1400000019 [140366762202880] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 1400000107 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 1400000021 [140366762202880] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 1400000114 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 1400000020 [140366762202880] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 1400500705 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 1400000036 [140366762202880] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 1400001120 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 1400000028 [140366762202880] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 1400000135 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 1400000030 [140366762202880] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 1400000124 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 1400000021 [140366762202880] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 1400500611 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 1400000026 [140366762202880] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 1400001131 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 1400000021 [140366762202880] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 1400000129 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 1400000018 [140366762202880] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 1400000128 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 1400000019 [140366762202880] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 1400500680 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 1400000026 [140366762202880] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 1400001103 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 1400000020 [140366762202880] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 1400000058 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 1400000013 [140366762202880] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 1400000089 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 1400000019 [140366762202880] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 1400500656 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 1400000023 [140366762202880] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 1400001129 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 1400000018 [140366762202880] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 1400000123 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 1400000017 [140366762202880] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 1400000124 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 1400000018 [140366762202880] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 1400500619 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 1400000012 [140366762202880] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 1400001021 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 1400000005 [140366762202880] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 1400000080 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 1400000018 [140366762202880] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 1400000014 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 1400000003 [140366762202880] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 1400500696 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 1400000039 [140366762202880] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 1400001204 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 1400000027 [140366762202880] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 1400000177 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 1400000026 [140366762202880] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 1400000155 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 1400000026 [140366762202880] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 1400500638 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 1400000027 [140366762202880] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 1400001121 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 1400000026 [140366762202880] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 1400000062 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 1400000017 [140366762202880] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 1400000145 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 1400000029 [140366762202880] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 1400044124 [140366770595584] eventhandler.c:358:EHStatusHandlerThread() Card Removed From REINER SCT cyberJack RFID standard (9934036502) 00 0000456534 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 1400000027 [140366762202880] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 1400000106 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 1400000022 [140366762202880] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 1400000328 [140366762202880] winscard_svc.c:361:ContextThread() Received command: DISCONNECT from client 1400000024 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000007 [140366762202880] winscard.c:881:SCardDisconnect() Active Contexts: -100000005 [140366762202880] winscard.c:882:SCardDisconnect() dwDisposition: 000000005 [140366762202880] winscard.c:1017:SCardDisconnect() powerState: POWER_STATE_GRACE_PERIOD00000011 [140366762202880] winscard.c:1043:SCardDisconnect() UnrefReader() count was: 200000010 [140366762202880] winscard_svc.c:550:ContextThread() DISCONNECT rv=0x0 for client 1400000064 [140366762202880] winscard_svc.c:361:ContextThread() Received command: RELEASE_CONTEXT from client 1400000012 [140366762202880] winscard.c:229:SCardReleaseContext() Releasing Context: 0xA6D81FD00000005 [140366762202880] winscard_svc.c:476:ContextThread() RELEASE_CONTEXT rv=0x0 for client 1400000036 [140366762202880] winscard_svc.c:354:ContextThread() Client die: 1400000025 [140366762202880] winscard_svc.c:1055:MSGCleanupClient() Thread is stopping: dwClientID=14, threadContext @0x560a0ee01f2000000007 [140366762202880] winscard_svc.c:1063:MSGCleanupClient() Freeing SCONTEXT @0x560a0ee01f2000343238 [140366770595584] eventhandler.c:494:EHStatusHandlerThread() powerState: POWER_STATE_POWERED00400571 [140366770595584] eventhandler.c:482:EHStatusHandlerThread() powerState: POWER_STATE_UNPOWERED00170077 [140366770595584] eventhandler.c:406:EHStatusHandlerThread() powerState: POWER_STATE_POWERED00000017 [140366770595584] eventhandler.c:423:EHStatusHandlerThread() Card inserted into REINER SCT cyberJack RFID standard (9934036502) 00 0000000008 [140366770595584] Card ATR: 3B 80 80 01 01 00400587 [140366770595584] eventhandler.c:482:EHStatusHandlerThread() powerState: POWER_STATE_UNPOWERED01123888 [140366874249152] winscard_msg_srv.c:256:ProcessEventsServer() Common channel packet arrival00000021 [140366874249152] winscard_msg_srv.c:267:ProcessEventsServer() ProcessCommonChannelRequest detects: 1400000006 [140366874249152] pcscdaemon.c:133:SVCServiceRunLoop() A new context thread creation is requested: 1400000143 [140366762202880] winscard_svc.c:340:ContextThread() Authorized PC/SC client00000015 [140366762202880] winscard_svc.c:343:ContextThread() Thread is started: dwClientID=14, threadContext @0x560a0ee01f2000000011 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_VERSION from client 1400000006 [140366762202880] winscard_svc.c:373:ContextThread() Client is protocol version 4:400000004 [140366762202880] winscard_svc.c:396:ContextThread() CMD_VERSION rv=0x0 for client 1400000038 [140366762202880] winscard_svc.c:361:ContextThread() Received command: ESTABLISH_CONTEXT from client 1400000013 [140366762202880] winscard.c:215:SCardEstablishContext() Establishing Context: 0xF640E7B00000004 [140366762202880] winscard_svc.c:461:ContextThread() ESTABLISH_CONTEXT rv=0x0 for client 1400000031 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_GET_READERS_STATE from client 1400000037 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_GET_READERS_STATE from client 1400000066 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CONNECT from client 1400000011 [140366762202880] winscard_svc.c:499:ContextThread() Authorized client for 'REINER SCT cyberJack RFID standard (9934036502) 00 00'00000004 [140366762202880] winscard.c:258:SCardConnect() Attempting Connect to REINER SCT cyberJack RFID standard (9934036502) 00 00 using protocol: 300000004 [140366762202880] readerfactory.c:821:RFReaderInfo() RefReader() count was: 100170139 [140366762202880] winscard.c:332:SCardConnect() power up complete.00000016 [140366762202880] Card ATR: 3B 80 80 01 01 00000003 [140366762202880] winscard.c:352:SCardConnect() powerState: POWER_STATE_IN_USE00000007 [140366762202880] prothandler.c:107:PHSetProtocol() Attempting PTS to T=100000010 [140366762202880] winscard.c:430:SCardConnect() Active Protocol: T=100000005 [140366762202880] winscard.c:456:SCardConnect() hCard Identity: 6cc0d62600000007 [140366762202880] winscard.c:518:SCardConnect() UnrefReader() count was: 200000008 [140366762202880] winscard_svc.c:513:ContextThread() CONNECT rv=0x0 for client 1400000044 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CONTROL from client 1400000008 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000173 [140366762202880] winscard.c:1359:SCardControl() UnrefReader() count was: 200000010 [140366762202880] winscard_svc.c:735:ContextThread() CONTROL rv=0x0 for client 1400000031 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_GET_READERS_STATE from client 1400000036 [140366762202880] winscard_svc.c:361:ContextThread() Received command: STATUS from client 1400000008 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000003 [140366762202880] winscard.c:1300:SCardStatus() UnrefReader() count was: 200000002 [140366762202880] winscard_svc.c:632:ContextThread() STATUS rv=0x0 for client 1400000021 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 1400000005 [140366762202880] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 1400000019 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 1400000006 [140366762202880] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 1400000024 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000008 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000004 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000006 [140366762202880] APDU: 00 A4 00 0C 02 3F 00 00024905 [140366762202880] SW: 6A 86 00000032 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000018 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000169 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000044 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000014 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000015 [140366762202880] APDU: 00 A4 04 00 06 D2 76 00 01 24 01 00015151 [140366762202880] SW: 90 00 00000034 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000015 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000178 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000040 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000019 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000017 [140366762202880] APDU: 00 CA 00 4F 00 00015945 [140366762202880] SW: D2 76 00 01 24 01 03 04 BE EF 00 00 00 00 00 07 90 00 00000017 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000009 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000143 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000018 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000005 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000005 [140366762202880] APDU: 00 CA 5F 52 00 00015242 [140366762202880] SW: 00 C1 C5 73 C0 01 80 05 90 00 90 00 00000019 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000011 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000110 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000018 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000005 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000007 [140366762202880] APDU: 00 CA 00 C4 00 00016816 [140366762202880] SW: 01 7F 7F 7F 03 00 03 90 00 00000017 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000007 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000104 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000015 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000006 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000005 [140366762202880] APDU: 00 CA 00 6E 00 00032907 [140366762202880] SW: 6E 81 D9 4F 10 D2 76 00 01 24 01 03 04 BE EF 00 00 00 00 00 07 5F 52 0A 00 C1 C5 73 C0 01 80 05 90 00 73 81 B7 C0 0A FF 03 00 20 04 80 00 FF 00 00 C1 06 01 10 00 00 11 03 C2 06 01 10 00 00 11 03 C3 06 01 0C 00 00 11 03 C4 07 01 7F 7F 7F 03 00 03 C5 3C 03 53 CB 0B 67 EA AA DE 39 A5 B5 4F E8 D6 EC 89 1A 92 2C E4 03 FC FC B0 49 FF E3 97 33 7B 4B 3F F9 BE BB C9 CC B3 DE A9 52 6C E0 A2 9A C4 F6 B3 F6 D1 2B 67 BA DC AD FD C2 AC 5D 9F C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 5F AE D1 4D 5F AE D1 4D 5F AE D1 4D 90 00 00000025 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000008 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000098 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000017 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000006 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000006 [140366762202880] APDU: 00 CA 7F 74 00 00013046 [140366762202880] SW: 6A 88 00000015 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000006 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000127 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000019 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000005 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000005 [140366762202880] APDU: 00 CA 00 5E 00 00011872 [140366762202880] SW: 90 00 00000015 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000006 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000117 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000018 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000005 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000005 [140366762202880] APDU: 00 CA 00 6E 00 00032903 [140366762202880] SW: 6E 81 D9 4F 10 D2 76 00 01 24 01 03 04 BE EF 00 00 00 00 00 07 5F 52 0A 00 C1 C5 73 C0 01 80 05 90 00 73 81 B7 C0 0A FF 03 00 20 04 80 00 FF 00 00 C1 06 01 10 00 00 11 03 C2 06 01 10 00 00 11 03 C3 06 01 0C 00 00 11 03 C4 07 01 7F 7F 7F 03 00 03 C5 3C 03 53 CB 0B 67 EA AA DE 39 A5 B5 4F E8 D6 EC 89 1A 92 2C E4 03 FC FC B0 49 FF E3 97 33 7B 4B 3F F9 BE BB C9 CC B3 DE A9 52 6C E0 A2 9A C4 F6 B3 F6 D1 2B 67 BA DC AD FD C2 AC 5D 9F C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 5F AE D1 4D 5F AE D1 4D 5F AE D1 4D 90 00 00000026 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000008 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000103 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000016 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000007 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000006 [140366762202880] APDU: 00 CA 00 6E 00 00032934 [140366762202880] SW: 6E 81 D9 4F 10 D2 76 00 01 24 01 03 04 BE EF 00 00 00 00 00 07 5F 52 0A 00 C1 C5 73 C0 01 80 05 90 00 73 81 B7 C0 0A FF 03 00 20 04 80 00 FF 00 00 C1 06 01 10 00 00 11 03 C2 06 01 10 00 00 11 03 C3 06 01 0C 00 00 11 03 C4 07 01 7F 7F 7F 03 00 03 C5 3C 03 53 CB 0B 67 EA AA DE 39 A5 B5 4F E8 D6 EC 89 1A 92 2C E4 03 FC FC B0 49 FF E3 97 33 7B 4B 3F F9 BE BB C9 CC B3 DE A9 52 6C E0 A2 9A C4 F6 B3 F6 D1 2B 67 BA DC AD FD C2 AC 5D 9F C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 5F AE D1 4D 5F AE D1 4D 5F AE D1 4D 90 00 00000019 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000006 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000129 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000019 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000005 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000004 [140366762202880] APDU: 00 CA 00 6E 00 00032916 [140366762202880] SW: 6E 81 D9 4F 10 D2 76 00 01 24 01 03 04 BE EF 00 00 00 00 00 07 5F 52 0A 00 C1 C5 73 C0 01 80 05 90 00 73 81 B7 C0 0A FF 03 00 20 04 80 00 FF 00 00 C1 06 01 10 00 00 11 03 C2 06 01 10 00 00 11 03 C3 06 01 0C 00 00 11 03 C4 07 01 7F 7F 7F 03 00 03 C5 3C 03 53 CB 0B 67 EA AA DE 39 A5 B5 4F E8 D6 EC 89 1A 92 2C E4 03 FC FC B0 49 FF E3 97 33 7B 4B 3F F9 BE BB C9 CC B3 DE A9 52 6C E0 A2 9A C4 F6 B3 F6 D1 2B 67 BA DC AD FD C2 AC 5D 9F C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 5F AE D1 4D 5F AE D1 4D 5F AE D1 4D 90 00 00000022 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000006 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000104 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 1400000018 [140366762202880] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 1400001089 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 1400000015 [140366762202880] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 1400000040 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 1400000009 [140366762202880] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 1400000109 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 1400000014 [140366762202880] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 1400000567 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000019 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000005 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000005 [140366762202880] APDU: 00 CA 00 6E 00 00033060 [140366762202880] SW: 6E 81 D9 4F 10 D2 76 00 01 24 01 03 04 BE EF 00 00 00 00 00 07 5F 52 0A 00 C1 C5 73 C0 01 80 05 90 00 73 81 B7 C0 0A FF 03 00 20 04 80 00 FF 00 00 C1 06 01 10 00 00 11 03 C2 06 01 10 00 00 11 03 C3 06 01 0C 00 00 11 03 C4 07 01 7F 7F 7F 03 00 03 C5 3C 03 53 CB 0B 67 EA AA DE 39 A5 B5 4F E8 D6 EC 89 1A 92 2C E4 03 FC FC B0 49 FF E3 97 33 7B 4B 3F F9 BE BB C9 CC B3 DE A9 52 6C E0 A2 9A C4 F6 B3 F6 D1 2B 67 BA DC AD FD C2 AC 5D 9F C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 5F AE D1 4D 5F AE D1 4D 5F AE D1 4D 90 00 00000024 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000006 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400466806 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 1400000032 [140366762202880] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 1400001150 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 1400000028 [140366762202880] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 1400000146 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 1400000027 [140366762202880] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 1400000145 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 1400000027 [140366762202880] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 1400400686 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000045 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000018 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000017 [140366762202880] APDU: 00 CA 00 7A 00 00015576 [140366762202880] SW: 93 03 00 00 06 90 00 00000030 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000019 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000217 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000038 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000014 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000015 [140366762202880] APDU: 00 CA 00 C4 00 00016894 [140366762202880] SW: 01 7F 7F 7F 03 00 03 90 00 00000027 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000015 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400000141 [140366762202880] winscard_svc.c:361:ContextThread() Received command: TRANSMIT from client 1400000021 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000012 [140366762202880] winscard.c:1595:SCardTransmit() Send Protocol: T=100000014 [140366762202880] APDU: 00 CA 00 65 00 00017052 [140366762202880] SW: 5B 10 74 65 73 74 3C 3C 63 61 72 64 68 6F 6C 64 65 72 5F 2D 02 65 6E 5F 35 01 30 90 00 00000015 [140366762202880] winscard.c:1640:SCardTransmit() UnrefReader() count was: 200000005 [140366762202880] winscard_svc.c:685:ContextThread() TRANSMIT rv=0x0 for client 1400048211 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CONTROL from client 1400000016 [140366762202880] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 100000849 [140366762202880] winscard.c:1359:SCardControl() UnrefReader() count was: 200000013 [140366762202880] winscard_svc.c:735:ContextThread() CONTROL rv=0x0 for client 1400000718 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 1400000016 [140366762202880] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 1400001065 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 1400000012 [140366762202880] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 1400000026 [140366762202880] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 14``` Also there exists another issue, for example when my admin PIN is made up of characters I have no way of inputing it from the reader's pinentry and I know of no wha to switch to the on-screen pinentry Thank You for your help, 22h49 -------------- next part -------------- An HTML attachment was scrubbed... URL: From juergen at bruckner.email Sat Nov 14 11:22:22 2020 From: juergen at bruckner.email (Juergen Bruckner) Date: Sat, 14 Nov 2020 11:22:22 +0100 Subject: Major problems with gpg and scdaemon, help highly appriciated In-Reply-To: References: Message-ID: <31358caf-53ce-c083-4f26-9fcf9c33307a@bruckner.email> Hello 22h49 Am 13.11.20 um 20:22 schrieb 22h39 via Gnupg-users: > > I have been for the life of me unable to get gpg working with the contactless interface in my reader. > > > How to reproduce: > > I'm using a REINERSCT Cyberjack standard RFID dual interface class 3 reader > Simply take a Openpgp card and try to sign anything using the contactless interface. > As far as I know the OpenPGP function of the OpenPGP-Card cannot be used via NFC / RFID. You need to use the on card chip and a card reader for PGP operations. regards Juergen -- /?\ No | \ / HTML | Juergen Bruckner X in | juergen at bruckner.email / \ Mail | -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3894 bytes Desc: S/MIME Cryptographic Signature URL: From wk at gnupg.org Sat Nov 14 14:38:19 2020 From: wk at gnupg.org (Werner Koch) Date: Sat, 14 Nov 2020 14:38:19 +0100 Subject: Major problems with gpg and scdaemon, help highly appriciated In-Reply-To: <31358caf-53ce-c083-4f26-9fcf9c33307a@bruckner.email> (Juergen Bruckner via Gnupg-users's message of "Sat, 14 Nov 2020 11:22:22 +0100") References: <31358caf-53ce-c083-4f26-9fcf9c33307a@bruckner.email> Message-ID: <87lff4oy7o.fsf@wheatstone.g10code.de> On Sat, 14 Nov 2020 11:22, Juergen Bruckner said: > As far as I know the OpenPGP function of the OpenPGP-Card cannot be > used via NFC / RFID. You need to use the on card chip and a card In fact GnuPG does not support secure messaging and thus using the contactless interface iwould be a security problem. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From 22h39 at tutanota.com Sat Nov 14 19:45:54 2020 From: 22h39 at tutanota.com (22h39) Date: Sat, 14 Nov 2020 19:45:54 +0100 (CET) Subject: Major problems with gpg and scdaemon, help highly appriciated In-Reply-To: References: Message-ID: I don't understand, then how is OpenKeychain able to use OpenPGP cards via RFID? I can sucessfully sign using this card via my phone but It won't work with the reader connected to the computer. Looking at the logs, the card exchanges exactly the same apdus when using the contact and contactless interface so all points to some weird bug in gpg. Thanks for help, 22h49 -------------- next part -------------- An HTML attachment was scrubbed... URL: From juergen at bruckner.email Sat Nov 14 19:58:51 2020 From: juergen at bruckner.email (Juergen Bruckner) Date: Sat, 14 Nov 2020 19:58:51 +0100 Subject: Major problems with gpg and scdaemon, help highly appriciated In-Reply-To: References: Message-ID: <3acfebb5-7868-a111-b08f-b6fa2480c05d@bruckner.email> What kind of OpenPGP card do you use? The OpenPGP Smart Card V3.3 + MiFare DESFire [1] don't support PGP operations via RFID. regards Juergen [1] https://www.floss-shop.de/en/security-privacy/smartcards/4/openpgp-smart-card-v3.3-mifare-desfire -- /?\ No | \ / HTML | Juergen Bruckner X in | juergen at bruckner.email / \ Mail | Am 14.11.20 um 19:45 schrieb 22h39 via Gnupg-users: > I don't understand, then how is OpenKeychain able to use OpenPGP cards via RFID? > > I can sucessfully sign using this card via my phone but It won't work with the reader connected to the computer. > > Looking at the logs, the card exchanges exactly the same apdus when using the contact and contactless interface so all points to some weird bug in gpg. > > Thanks for help, > 22h49 > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3894 bytes Desc: S/MIME Cryptographic Signature URL: From 22h39 at tutanota.com Sat Nov 14 20:08:27 2020 From: 22h39 at tutanota.com (22h39) Date: Sat, 14 Nov 2020 20:08:27 +0100 (CET) Subject: Major problems with gpg and scdaemon, help highly appriciated In-Reply-To: <3acfebb5-7868-a111-b08f-b6fa2480c05d@bruckner.email> References: <3acfebb5-7868-a111-b08f-b6fa2480c05d@bruckner.email> Message-ID: Sorry Jorgen for the mail I missclicked. As can be seen in the logs I'm using a NXP J3H145 card with this applet: https://github.com/ANSSI-FR/SmartPGP which is compliant with OpenPGP spec V3.4. I can assure that this card __works__ via RFID since I can easily sign files using it and OpenKeychain on my phone, the problem here is created by GPG in conjunction with the reader. Thanks for help, 22h49 Nov 14, 2020, 19:58 by gnupg-users at gnupg.org: > What kind of OpenPGP card do you use? > The OpenPGP Smart Card V3.3 + MiFare DESFire [1] don't support PGP operations via RFID. > > regards > Juergen > > [1] https://www.floss-shop.de/en/security-privacy/smartcards/4/openpgp-smart-card-v3.3-mifare-desfire > -- > /?\ No | > \ / HTML | Juergen Bruckner > X in | juergen at bruckner.email > / \ Mail | > > Am 14.11.20 um 19:45 schrieb 22h39 via Gnupg-users: > >> I don't understand, then how is OpenKeychain able to use OpenPGP cards via RFID? >> >> I can sucessfully sign using this card via my phone but It won't work with the reader connected to the computer. >> >> Looking at the logs, the card exchanges exactly the same apdus when using the contact and contactless interface so all points to some weird bug in gpg. >> >> Thanks for help, >> 22h49 >> >> >> _______________________________________________ >> Gnupg-users mailing list >> Gnupg-users at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-users >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From juergen at bruckner.email Sat Nov 14 20:39:43 2020 From: juergen at bruckner.email (Juergen Bruckner) Date: Sat, 14 Nov 2020 20:39:43 +0100 Subject: Major problems with gpg and scdaemon, help highly appriciated In-Reply-To: References: <3acfebb5-7868-a111-b08f-b6fa2480c05d@bruckner.email> Message-ID: No problem! I see. Well I don't have any experiences with other cards than these from Zeitcontrol and the tokens from Yubikey and Nitrokey. I know that the Yubikey5 supports PGP operations via RFID as a few customers from me use it with their mobile devices. But as Werner stated in his e-mail before it may be a 'problem' specific with GnuPG as it doesn't support wireless operation for security reasons. And I really don't know if another OpenPGP implementation does support smartcards/token. This was already a big issue with Mozilla's Thunderbird 78 and it's native implementation of OpenPGP instead of Enigmail. Sorry that I can't help in a better way! best regards and a great weekend Juergen -- /?\ No | \ / HTML | Juergen Bruckner X in | juergen at bruckner.email / \ Mail | Am 14.11.20 um 20:08 schrieb 22h39 via Gnupg-users: > Sorry Jorgen for the mail I missclicked. > > As can be seen in the logs I'm using a NXP J3H145 card with this applet: https://github.com/ANSSI-FR/SmartPGP which is compliant with OpenPGP spec V3.4. > > I can assure that this card __works__ via RFID since I can easily sign files using it and OpenKeychain on my phone, the problem here is created by GPG in conjunction with the reader. > > Thanks for help, > 22h49 > > > > Nov 14, 2020, 19:58 by gnupg-users at gnupg.org: > >> What kind of OpenPGP card do you use? >> The OpenPGP Smart Card V3.3 + MiFare DESFire [1] don't support PGP operations via RFID. >> >> regards >> Juergen >> >> [1] https://www.floss-shop.de/en/security-privacy/smartcards/4/openpgp-smart-card-v3.3-mifare-desfire >> -- >> /?\ No | >> \ / HTML | Juergen Bruckner >> X in | juergen at bruckner.email >> / \ Mail | >> >> Am 14.11.20 um 19:45 schrieb 22h39 via Gnupg-users: >> >>> I don't understand, then how is OpenKeychain able to use OpenPGP cards via RFID? >>> >>> I can sucessfully sign using this card via my phone but It won't work with the reader connected to the computer. >>> >>> Looking at the logs, the card exchanges exactly the same apdus when using the contact and contactless interface so all points to some weird bug in gpg. >>> >>> Thanks for help, >>> 22h49 >>> >>> >>> _______________________________________________ >>> Gnupg-users mailing list >>> Gnupg-users at gnupg.org >>> http://lists.gnupg.org/mailman/listinfo/gnupg-users >>> > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3894 bytes Desc: S/MIME Cryptographic Signature URL: From 22h39 at tutanota.com Sat Nov 14 21:28:58 2020 From: 22h39 at tutanota.com (22h39) Date: Sat, 14 Nov 2020 21:28:58 +0100 (CET) Subject: Major problems with gpg and scdaemon, help highly appriciated In-Reply-To: References: <3acfebb5-7868-a111-b08f-b6fa2480c05d@bruckner.email> Message-ID: Thanks to everyone I have been able to resolve the problem by writing: disable-pinpad to: ~/.gnupg/scdaemon.conf The problem lies in Pinentry which for some reason can't hande ccid pin requests on the contactless interface, after this fix the interface works as expceted no problem with any feautures. Thank you, 22h49 Nov 14, 2020, 20:39 by gnupg-users at gnupg.org: > No problem! > > I see. > Well I don't have any experiences with other cards than these from Zeitcontrol and the tokens from Yubikey and Nitrokey. > I know that the Yubikey5 supports PGP operations via RFID as a few customers from me use it with their mobile devices. > > But as Werner stated in his e-mail before it may be a 'problem' specific with GnuPG as it doesn't support wireless operation for security reasons. > > And I really don't know if another OpenPGP implementation does support smartcards/token. > This was already a big issue with Mozilla's Thunderbird 78 and it's native implementation of OpenPGP instead of Enigmail. > > Sorry that I can't help in a better way! > > best regards and a great weekend > Juergen > > -- > /?\ No | > \ / HTML | Juergen Bruckner > X in | juergen at bruckner.email > / \ Mail | > > Am 14.11.20 um 20:08 schrieb 22h39 via Gnupg-users: > >> Sorry Jorgen for the mail I missclicked. >> >> As can be seen in the logs I'm using a NXP J3H145 card with this applet: https://github.com/ANSSI-FR/SmartPGP which is compliant with OpenPGP spec V3.4. >> >> I can assure that this card __works__ via RFID since I can easily sign files using it and OpenKeychain on my phone, the problem here is created by GPG in conjunction with the reader. >> >> Thanks for help, >> 22h49 >> >> >> >> Nov 14, 2020, 19:58 by gnupg-users at gnupg.org: >> >>> What kind of OpenPGP card do you use? >>> The OpenPGP Smart Card V3.3 + MiFare DESFire [1] don't support PGP operations via RFID. >>> >>> regards >>> Juergen >>> >>> [1] https://www.floss-shop.de/en/security-privacy/smartcards/4/openpgp-smart-card-v3.3-mifare-desfire >>> -- >>> /?\ No | >>> \ / HTML | Juergen Bruckner >>> X in | juergen at bruckner.email >>> / \ Mail | >>> >>> Am 14.11.20 um 19:45 schrieb 22h39 via Gnupg-users: >>> >>>> I don't understand, then how is OpenKeychain able to use OpenPGP cards via RFID? >>>> >>>> I can sucessfully sign using this card via my phone but It won't work with the reader connected to the computer. >>>> >>>> Looking at the logs, the card exchanges exactly the same apdus when using the contact and contactless interface so all points to some weird bug in gpg. >>>> >>>> Thanks for help, >>>> 22h49 >>>> >>>> >>>> _______________________________________________ >>>> Gnupg-users mailing list >>>> Gnupg-users at gnupg.org >>>> http://lists.gnupg.org/mailman/listinfo/gnupg-users >>>> >> >> >> >> _______________________________________________ >> Gnupg-users mailing list >> Gnupg-users at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-users >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From 22h39 at tutanota.com Sat Nov 14 21:32:59 2020 From: 22h39 at tutanota.com (22h39) Date: Sat, 14 Nov 2020 21:32:59 +0100 (CET) Subject: Major problems with gpg and scdaemon, help highly appriciated In-Reply-To: References: Message-ID: Problem resolved! look at my last reply to Juergen to find the solution. Thanks to everyone, 22h49 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Mon Nov 16 16:06:43 2020 From: wk at gnupg.org (Werner Koch) Date: Mon, 16 Nov 2020 16:06:43 +0100 Subject: Major problems with gpg and scdaemon, help highly appriciated In-Reply-To: (gnupg-users@gnupg.org's message of "Sat, 14 Nov 2020 21:28:58 +0100 (CET)") References: <3acfebb5-7868-a111-b08f-b6fa2480c05d@bruckner.email> Message-ID: <875z65pcho.fsf@wheatstone.g10code.de> On Sat, 14 Nov 2020 21:28, 22h39 said: > The problem lies in Pinentry which for some reason can't hande ccid > pin requests on the contactless interface, after this fix the Which reader and which ccid driver are you using? I assume that you are running pcscd, right? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From 22h39 at tutanota.com Mon Nov 16 18:18:02 2020 From: 22h39 at tutanota.com (22h39) Date: Mon, 16 Nov 2020 18:18:02 +0100 (CET) Subject: Major problems with gpg and scdaemon, help highly appriciated In-Reply-To: <875z65pcho.fsf@wheatstone.g10code.de> References: <3acfebb5-7868-a111-b08f-b6fa2480c05d@bruckner.email> <875z65pcho.fsf@wheatstone.g10code.de> Message-ID: The readers as I've shown is a REINERST Cyberjack RFID Standard, and the driver pcsc_lite. Indeed I am running pcsc, in my first message I've even posted it's debug log. Thanks, 22h49 Nov 16, 2020, 16:06 by wk at gnupg.org: > On Sat, 14 Nov 2020 21:28, 22h39 said: > >> The problem lies in Pinentry which for some reason can't hande ccid >> pin requests on the contactless interface, after this fix the >> > > Which reader and which ccid driver are you using? I assume that you are > running pcscd, right? > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wangtianjiao.wang959 at gmail.com Tue Nov 17 02:35:57 2020 From: wangtianjiao.wang959 at gmail.com (A NiceBoy) Date: Mon, 16 Nov 2020 20:35:57 -0500 Subject: GPG Encryption/Decryption Failing In-Reply-To: References: Message-ID: Hello Sirisha, I read from Mozilla's official documentation which states that SOPS command-line client is preferred, the SOPS library should be used only for decryption. The link is here: https://godoc.org/go.mozilla.org/sops/v3 >This package should not be used directly. Instead, Sops users should install the command line client >via `go get -u go.mozilla.org/sops/v3/cmd/sops`, or use the decryption helper provided at >`go.mozilla.org/sops/v3/decrypt`. >We do not guarantee API stability for any package other than `go.mozilla.org/sops/v3/decrypt`. My two cents. Best regards On Fri, 13 Nov 2020 at 17:08, Sirisha Gopigiri via Gnupg-users wrote: > > Hi, > > We are trying to use SOPS+GPG to encrypt/decrypt yaml files and we have written some go wrapper using sops library to perform the required encryption/decryption. However when trying to execute this code the gpg library seems to be failing at keygeneration most of the time with the following error. > > failed to encrypt new data key with master key "681E3A89EB1DAFD36EB883120A73BB48E26694D8": could not encrypt data key with PGP key: golang.org/x/crypto/openpgp error: key with fingerprint 681E3A89EB1DAFD36EB883120A73BB48E26694D8 is not available in keyring and could not be retrieved from keyserver; GPG binary error: gpg binary failed with error: exit status 2, gpg: 681E3A89EB1DAFD36EB883120A73BB48E26694D8: skipped: No public key > > Seems like it is unable to fetch the public key, we are executing the code locally, so we are using the local public and private keys only. > > Though we can list the public key locally, we keep getting the above error quite frequently. However, the encryption/decryption is happening successfully the other times. > > Kindly let us know if we are missing anything. > > We are facing this error only with gpg 2.1.x version, gpg 1.4.x version seems to be working fine. > > > Thank you in advance! > > Best Regards > Sirisha Gopigiri > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From wk at gnupg.org Tue Nov 17 11:17:11 2020 From: wk at gnupg.org (Werner Koch) Date: Tue, 17 Nov 2020 11:17:11 +0100 Subject: [Announce] GnuPG 2.2.24 released Message-ID: <87mtzgnv88.fsf@wheatstone.g10code.de> Hello! We are pleased to announce the availability of a new GnuPG release: version 2.2.24. This is maintenace release fixing some long standing bugs. See below for details. What is GnuPG ============= The GNU Privacy Guard (GnuPG, GPG) is a complete and free implementation of the OpenPGP and S/MIME standards. GnuPG allows to encrypt and sign data and communication, features a versatile key management system as well as access modules for public key directories. GnuPG itself is a command line tool with features for easy integration with other applications. The separate library GPGME provides a uniform API to use the GnuPG engine by software written in common programming languages. A wealth of frontend applications and libraries making use of GnuPG are available. As an universal crypto engine GnuPG provides support for S/MIME and Secure Shell in addition to OpenPGP. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License. Noteworthy changes in version 2.2.24 ==================================== * Allow Unicode file names on Windows almost everywhere. Note that it is still not possible to use Unicode strings on the command line. This change also fixes a regression in 2.2.22 related to non-ascii file names. [#5098] * Fix localized time printing on Windows. [#5073] * gpg: New command --quick-revoke-sig. [#5093] * gpg: Do not use weak digest algos if selected by recipient preference during sign+encrypt. [4c181d51a6] * gpg: Switch to AES256 for symmetric encryption in de-vs mode. [166e779634] * gpg: Silence weak digest warnings with --quiet. [#4893] * gpg: Print new status line CANCELED_BY_USER for a cancel during symmetric encryption. [f05d1772c4] * gpg: Fix the encrypt+sign hash algo preference selection for ECDSA. This is in particular needed for keys created from existing smartcard based keys. [aeed0b93ff] * agent: Fix secret key import of GnuPG 2.3 generated Ed25519 keys. [#5114] * agent: Keep some permissions of private-keys-v1.d. [#2312] * dirmngr: Align sks-keyservers.netCA.pem use between ntbtls and gnutls builds. [e4f3b74c91] * dirmngr: Fix the pool keyserver case for a single host in the pool. [72e04b03b1a7] * scd: Fix the use case of verify_chv2 by CHECKPIN. [61aea64b3c] * scd: Various improvements to the ccid-driver. [#4616,#5065] * scd: Minor fixes for Yubikey [25bec16d0b] * gpgconf: New option --show-versions. * w32: Install gpg-check-pattern and example profiles. Install Windows subsystem variant of gpgconf (gpgconf-w32). * i18n: Complete overhaul and completion of the Italian translation. Thanks to Denis Renzi. * Require Libgcrypt 1.8 because 1.7 has long reached end-of-life. Release-info: https://dev.gnupg.org/T5052 Getting the Software ==================== Please follow the instructions found at or read on: GnuPG 2.2.24 may be downloaded from one of the GnuPG mirror sites or direct from its primary FTP server. The list of mirrors can be found at . Note that GnuPG is not available at ftp.gnu.org. The GnuPG source code compressed using BZIP2 and its OpenPGP signature are available here: https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.24.tar.bz2 (7027k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.24.tar.bz2.sig An installer for Windows without any graphical frontend except for a very minimal Pinentry tool is available here: https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.24_20201117.exe (4322k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.24_20201117.exe.sig The source used to build the Windows installer can be found in the same directory with a ".tar.xz" suffix. New versions of the GnuPG VS-Desktop(tm) as well as Gpg4win for Windows featuring this version of GnuPG will be released shortly. Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a version of GnuPG installed, you can simply verify the supplied signature. For example to verify the signature of the file gnupg-2.2.24.tar.bz2 you would use this command: gpg --verify gnupg-2.2.24.tar.bz2.sig gnupg-2.2.24.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See the end of this mail for information on the signing keys. * If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either "sha1sum" or "shasum". Assuming you downloaded the file gnupg-2.2.24.tar.bz2, you run the command like this: sha1sum gnupg-2.2.24.tar.bz2 and check that the output matches the next line: 2e8e29fdc06710d1e7f6f4b87098b96e058797fe gnupg-2.2.24.tar.bz2 eeefbaaecc4d69a3b66e1ce333c4c5081501310a gnupg-w32-2.2.24_20201117.tar.xz ab895bd9bc4319b88b1314ede3a816cd0a1cc677 gnupg-w32-2.2.24_20201117.exe Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese (traditional and simplified), Czech, French, German, Italian, Japanese, Norwegian, Polish, Russian, and Ukrainian being almost completely translated. Documentation and Support ========================= If you used GnuPG in the past you should read the description of changes and new features at doc/whats-new-in-2.1.txt or online at https://gnupg.org/faq/whats-new-in-2.1.html The file gnupg.info has the complete reference manual of the system. Separate man pages are included as well but they miss some of the details available only in thee manual. The manual is also available online at https://gnupg.org/documentation/manuals/gnupg/ or can be downloaded as PDF at https://gnupg.org/documentation/manuals/gnupg.pdf . You may also want to search the GnuPG mailing list archives or ask on the gnupg-users mailing list for advise on how to solve problems. Most of the new features are around for several years and thus enough public experience is available. https://wiki.gnupg.org has user contributed information around GnuPG and relate software. In case of build problems specific to this release please first check https://dev.gnupg.org/T5052 for updated information. Please consult the archive of the gnupg-users mailing list before reporting a bug: . We suggest to send bug reports for a new release to this list in favor of filing a bug at . If you need commercial support go to or . If you are a developer and you need a certain feature for your project, please do not hesitate to bring it to the gnupg-devel mailing list for discussion. Thanks ====== Since 2001 maintenance and development of GnuPG is done by g10 Code GmbH and currently mostly financed by donations. Two full-time employed developers as well as two contractor exclusively work on GnuPG and closely related software like Libgcrypt, GPGME and Gpg4win. We like to thank all the nice people who are helping the GnuPG project, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, or answering questions on the mailing lists. Many thanks to our numerous financial supporters, both corporate and individuals. Without you it would not be possible to keep GnuPG in a good and secure shape and to address all the small and larger requests made by our users. Thanks. Happy hacking, Your GnuPG hackers p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users'at'gnupg.org mailing list. p.p.s List of Release Signing Keys: To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: rsa2048 2011-01-12 [expires: 2021-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048 2014-10-29 [expires: 2020-10-30] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa3072 2017-03-17 [expires: 2027-03-15] Key fingerprint = 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 Andre Heinecke (Release Signing Key) ed25519 2020-08-24 [expires: 2030-06-30] Key fingerprint = 6DAA 6E64 A76D 2840 571B 4902 5288 97B8 2640 3ADA Werner Koch (dist signing 2020) The keys are available at and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From bangchuishan at outlook.com Tue Nov 17 03:28:49 2020 From: bangchuishan at outlook.com (Gao Xiaohui) Date: Tue, 17 Nov 2020 02:28:49 +0000 Subject: How to change the protect cipher algorithm and the digest algorithm of the secret key? Message-ID: Thank you for your reply to my question. In "https://dev.gnupg.org/T1800", Werner responded: "It is an open question whether gpg should be allowed to change the s2k options because the keys are a property of the agent and not of gpg. For export it might hwoever make sense to be able to change that (think export for use on a slower box)."Excuse me, why not use "--s2k-digest-algo" and "--s2k-cipher-algo" and other options for gpg-agent.exe, so you can also write these options in "gpg- conf.conf". At present, the "--s2k-count" option can be used in both gpg.exe and gpg-agent.exe.Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Tue Nov 17 16:20:29 2020 From: wk at gnupg.org (Werner Koch) Date: Tue, 17 Nov 2020 16:20:29 +0100 Subject: How to change the protect cipher algorithm and the digest algorithm of the secret key? In-Reply-To: (Gao Xiaohui via Gnupg-users's message of "Tue, 17 Nov 2020 02:28:49 +0000") References: Message-ID: <87ft58nh6q.fsf@wheatstone.g10code.de> On Tue, 17 Nov 2020 02:28, Gao Xiaohui said: > conf.conf". At present, the "--s2k-count" option can be used in both > gpg.exe and gpg-agent.exe.Thank you. In gpg.conf this is used for deriving a passphrase for symmetric encryption. In gpg-agent.conf it is used to override the calibrated iteration code for protecting keys in gpg-agent. There is no need to change the algorithms. For interoperability and maintenance reasons we try to limit the number of user modifiable parameters. Eventually there will be change to an AEAD algorithm, howver interoperability is the main concern and not theoretical attacks. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From spam.trap.mailing.lists at gmail.com Tue Nov 17 16:47:18 2020 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Tue, 17 Nov 2020 15:47:18 +0000 Subject: Avoid recipient-compatibility SHA1 In-Reply-To: <20201102131532.GA1475874@fullerene.field.pennock-tech.net> References: <20201030041054.GA959448@fullerene.field.pennock-tech.net> <874km7vs7z.fsf@wheatstone.g10code.de> <20201102131532.GA1475874@fullerene.field.pennock-tech.net> Message-ID: On Mon, Nov 2, 2020 at 2:25 PM Phil Pennock via Gnupg-users wrote: > > On 2020-11-02 at 13:49 +0100, Werner Koch via Gnupg-users wrote: > > On Fri, 30 Oct 2020 00:10, Phil Pennock said: > > > recipient. That's fine. I'd rather create pressure for people to fix > > > their systems to use modern cryptography than cater to their brokenness > > > with sensitive messages. > > > > People won't update their keys - that just does not work. Ignoring the > > preferences is a better way here. > > First: thank you for the code changes! > > As to the people part: for a generic call to action, you're right. But > that's not the social dynamic in play here. > > For a specific set of people who know each other, trying to communicate > securely, if someone says "hey your key is too broken to use, please fix > it, here's a command to run (which you should check for yourself), > please do so and send us your new public key" ... then that works. I do have a question for you and Werner, if you don't mind. When one checks Wikipedia for SHA1: https://en.wikipedia.org/wiki/SHA-1 People may ask when seeing this [Quote]: Since 2005, SHA-1 has not been considered secure against well-funded opponents;[4] as of 2010 many organizations have recommended its replacement.[5][6][7] NIST formally deprecated use of SHA-1 in 2011 and disallowed its use for digital signatures in 2013. Was this therefore ever discussed on OpenPGP Mailing Lists, between OpenPGP experts and Mr. Zimmermann and Werner? Second question: What does it really mean for the OpenPGP ecosystem if there would be a SHA1 collision found in an email or detached signed document or file? I ask, because when one checks a GnuPG digitally signed message or file it usually says it comes from the key (owner) blah and this key has a fingerprint of blah if one checks. Regards Stefan From giessman at informatik.hu-berlin.de Tue Nov 17 17:37:38 2020 From: giessman at informatik.hu-berlin.de (Ernst G Giessmann) Date: Tue, 17 Nov 2020 17:37:38 +0100 Subject: Avoid recipient-compatibility SHA1 In-Reply-To: References: <20201030041054.GA959448@fullerene.field.pennock-tech.net> <874km7vs7z.fsf@wheatstone.g10code.de> <20201102131532.GA1475874@fullerene.field.pennock-tech.net> Message-ID: The answer to the second question is: A SHA-1 collision of two documents D1 and D2 means that the hash values Hash(D1) and Hash(D2) are equal, which in turn means that (regardless who signs) any signature of D1 (be it OpenPGP or SMIME) can also be used as a signature of D2. Any signer and any key, if used with SHA-1! So if you got a harmless document D to sign, you must be sure that there is no evil twin of it. This is usually the case if you are the author of D, because the construction of an evil twin remains hard. But it is easy to construct docs with the same hash value. /Ernst. Am 2020-11-17 um 16:47 schrieb Stefan Claas via Gnupg-users: > ... > Second question: > > What does it really mean for the OpenPGP ecosystem if there would be a > SHA1 collision found in an email or detached signed document or file? > I ask, because when one checks a GnuPG > digitally signed message or file it usually says it comes from the key > (owner) blah and this key has a fingerprint of blah if one checks. > > Regards > Stefan > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From gnupg-users at spodhuis.org Wed Nov 18 00:13:59 2020 From: gnupg-users at spodhuis.org (Phil Pennock) Date: Tue, 17 Nov 2020 18:13:59 -0500 Subject: Avoid recipient-compatibility SHA1 In-Reply-To: References: <20201030041054.GA959448@fullerene.field.pennock-tech.net> <874km7vs7z.fsf@wheatstone.g10code.de> <20201102131532.GA1475874@fullerene.field.pennock-tech.net> Message-ID: On 2020-11-17 at 15:47 +0000, Stefan Claas wrote: >} Since 2005, SHA-1 has not been considered secure against well-funded >} opponents;[4] as of 2010 many organizations have recommended its >} replacement.[5][6][7] NIST formally deprecated use of SHA-1 in 2011 >} and disallowed its use for digital signatures in 2013. > > Was this therefore ever discussed on OpenPGP Mailing Lists, between > OpenPGP experts and Mr. Zimmermann and Werner? It's been discussed on the standardization lists, where I would summarize the view as "What the hell, why are people still using SHA1?" The answer is that some people are still using tools such as GnuPGv1 and other similarly ancient software and get upset when asked to use the current code-bases. If you made a key using such old software but are now using modern software, you should re-sign your UID and check for other problems. If anyone wants to explore working with OpenPGP message formats while writing a standalone tool, I suggest a public key reporter tool which will report on the use of SHA1 (or MD5) digests where there's not also a signature with a modern digest scheme, and provide guidance about updating the keys. There's a few places such things might creep in. Re-reading RFC 4880 while taking notes about all the places you see such keys would help in writing a good tool. This strikes me as a good way for a developer to become more familiar with the ecosystem and to create an actively useful tool to help the community move forward away from ancient systems. Please don't demand this tool of any other developers: I offer the idea as a suggestion only. > Second question: > > What does it really mean for the OpenPGP ecosystem if there would be a > SHA1 collision found in an email or detached signed document or file? > I ask, because when one checks a GnuPG > digitally signed message or file it usually says it comes from the key > (owner) blah and this key has a fingerprint of blah if one checks. If someone can knowingly construct collisions against an existing signature, without the cooperation of the key owner, then SHA1 would be completely useless and such signatures would be nearly meaningless. The current state of SHA1 is "dangerously exposed, you should be hurrying for the exits, there might still be time to grab your coat on the way out of the door." The history is such that when the current attacks against a digest system are where the SHA1 attacks are now, you really don't want to be dealing with the next revelations because you will not be happy. At present, using "weak-digest sha1" in your GnuPG configuration files reveals a lot of problems and in day-to-day use you will have to periodically comment it back out again. I know, because I've been doing this since January. It has helped me with pushing people I need to exchange private mail with to update their keys. -Phil From azbigdogs at gmx.com Wed Nov 18 06:18:55 2020 From: azbigdogs at gmx.com (Mark) Date: Tue, 17 Nov 2020 22:18:55 -0700 Subject: Avoid recipient-compatibility SHA1 In-Reply-To: References: <20201030041054.GA959448@fullerene.field.pennock-tech.net> <874km7vs7z.fsf@wheatstone.g10code.de> <20201102131532.GA1475874@fullerene.field.pennock-tech.net> Message-ID: <483c47e9-aa79-9f57-75fd-ace40fe7a319@gmx.com> Not to ask a stupid question but how can you tell which algorithm your keys are using and if using SHA1 update them to a more secure one? Thanks, On 11/17/2020 4:13 PM, Phil Pennock via Gnupg-users wrote: > > The current state of SHA1 is "dangerously exposed, you should be > hurrying for the exits, there might still be time to grab your coat on > the way out of the door." The history is such that when the current > attacks against a digest system are where the SHA1 attacks are now, you > really don't want to be dealing with the next revelations because you > will not be happy. > > At present, using "weak-digest sha1" in your GnuPG configuration files > reveals a lot of problems and in day-to-day use you will have to > periodically comment it back out again. I know, because I've been doing > this since January. It has helped me with pushing people I need to > exchange private mail with to update their keys. > > -Phil > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -- PGP Key Upon Request From spam.trap.mailing.lists at gmail.com Wed Nov 18 14:11:53 2020 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Wed, 18 Nov 2020 14:11:53 +0100 Subject: Avoid recipient-compatibility SHA1 In-Reply-To: <20201102131532.GA1475874@fullerene.field.pennock-tech.net> References: <20201030041054.GA959448@fullerene.field.pennock-tech.net> <874km7vs7z.fsf@wheatstone.g10code.de> <20201102131532.GA1475874@fullerene.field.pennock-tech.net> Message-ID: Thank you for your reply, much appreciated! I will however ask also Ernst here again the same question one more time again, as an illustrative example. Regards Stefan On Mon, Nov 2, 2020 at 3:25 PM Phil Pennock via Gnupg-users wrote: > > On 2020-11-02 at 13:49 +0100, Werner Koch via Gnupg-users wrote: > > On Fri, 30 Oct 2020 00:10, Phil Pennock said: > > > recipient. That's fine. I'd rather create pressure for people to fix > > > their systems to use modern cryptography than cater to their brokenness > > > with sensitive messages. > > > > People won't update their keys - that just does not work. Ignoring the > > preferences is a better way here. > > First: thank you for the code changes! > > As to the people part: for a generic call to action, you're right. But > that's not the social dynamic in play here. > > For a specific set of people who know each other, trying to communicate > securely, if someone says "hey your key is too broken to use, please fix > it, here's a command to run (which you should check for yourself), > please do so and send us your new public key" ... then that works. > > In the generic case, there's a hypothetical reward requiring work now. > In the specific case, it's a case of "you're getting cut out of this > ongoing conversation which presumably matters to you, do this now to get > back in". If the conversation really does matter to that person, then > they will fix their key. I have gotten people to fix various problems > on exactly this basis. > > For everyone I am not talking to? Not my business, not my problem. > I can only issue advice and shrug when people ignore it. > > Now I just need a sane way to figure out which key caused this. :) > > Thanks, > -Phil > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From spam.trap.mailing.lists at gmail.com Wed Nov 18 14:30:12 2020 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Wed, 18 Nov 2020 14:30:12 +0100 Subject: Avoid recipient-compatibility SHA1 In-Reply-To: References: <20201030041054.GA959448@fullerene.field.pennock-tech.net> <874km7vs7z.fsf@wheatstone.g10code.de> <20201102131532.GA1475874@fullerene.field.pennock-tech.net> Message-ID: On Tue, Nov 17, 2020 at 11:11 PM Ernst G Giessmann via Gnupg-users wrote: > > The answer to the second question is: > > A SHA-1 collision of two documents D1 and D2 means that the hash values > Hash(D1) and Hash(D2) are equal, which in turn means that (regardless > who signs) any signature of D1 (be it OpenPGP or SMIME) can also be used > as a signature of D2. Any signer and any key, if used with SHA-1! > > So if you got a harmless document D to sign, you must be sure that there > is no evil twin of it. This is usually the case if you are the author of > D, because the construction of an evil twin remains hard. But it is easy > to construct docs with the same hash value. > > /Ernst. Thanks for your reply! So if I check the SHA1 checksums from https://gnupg.org/download/integrity_check.html and Alice checks from another evil site the same files then we could have a problem with tools like openssl or the shasum tool. But, sorry to ask again. I like to give an Example. Mallory has managed to listen to the clear text communications from Alice and Bob's online devices. Alice and Bob always use GnuPG to digitally sign their messages. Mallory is *not* in possession of the private keys from Alice and Bob. Mallory has created a document which causes a collision and was signed with his own key. He sends this message to Alice. What does Alice see when she does a gpg --verify? I mean she should see, regardless if the message has a collision or not, that the message was digitally signed by Mallory's private key and not by Bob's private key. Regards Stefan From spam.trap.mailing.lists at gmail.com Wed Nov 18 15:20:00 2020 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Wed, 18 Nov 2020 15:20:00 +0100 Subject: Avoid recipient-compatibility SHA1 In-Reply-To: References: <20201030041054.GA959448@fullerene.field.pennock-tech.net> <874km7vs7z.fsf@wheatstone.g10code.de> <20201102131532.GA1475874@fullerene.field.pennock-tech.net> Message-ID: On Wed, Nov 18, 2020 at 2:30 PM Stefan Claas wrote: > > On Tue, Nov 17, 2020 at 11:11 PM Ernst G Giessmann via Gnupg-users > wrote: > > > > The answer to the second question is: > > > > A SHA-1 collision of two documents D1 and D2 means that the hash values > > Hash(D1) and Hash(D2) are equal, which in turn means that (regardless > > who signs) any signature of D1 (be it OpenPGP or SMIME) can also be used > > as a signature of D2. Any signer and any key, if used with SHA-1! > > > > So if you got a harmless document D to sign, you must be sure that there > > is no evil twin of it. This is usually the case if you are the author of > > D, because the construction of an evil twin remains hard. But it is easy > > to construct docs with the same hash value. > > > > /Ernst. > > Thanks for your reply! So if I check the SHA1 checksums > from https://gnupg.org/download/integrity_check.html > and Alice checks from another evil site the same files then we > could have a problem with tools like openssl or the shasum tool. evil mirror with 'same' files ... > But, sorry to ask again. > > I like to give an Example. > > Mallory has managed to listen to the clear text communications from > Alice and Bob's online devices. Alice and Bob always use GnuPG > to digitally sign their messages. prior encrypting. > Mallory is *not* in possession of the private keys from Alice and Bob. > Mallory has created a document which causes a collision and was > signed with his own key. > > He sends this message to Alice. What does Alice see when she > does a gpg --verify? I mean she should see, regardless if the > message has a collision or not, that the message was digitally > signed by Mallory's private key and not by Bob's private key. The one thing I could currently see is if Alice would make a public statement on her web site, for example, digitally signed by her with SHA1 and that Mallory would upload a collided document with a (completely) different content. So the question for me would be if a collision could be crafted, let's say for an important business contract etc., if the different content of a document would make the same sense, like the one from the original document. Regards Stefan From giessman at informatik.hu-berlin.de Wed Nov 18 15:58:18 2020 From: giessman at informatik.hu-berlin.de (Ernst G Giessmann) Date: Wed, 18 Nov 2020 15:58:18 +0100 Subject: Avoid recipient-compatibility SHA1 In-Reply-To: References: <20201030041054.GA959448@fullerene.field.pennock-tech.net> <874km7vs7z.fsf@wheatstone.g10code.de> <20201102131532.GA1475874@fullerene.field.pennock-tech.net> Message-ID: <3533c941-54eb-e35c-7ff0-ef847cac0390@informatik.hu-berlin.de> Am 2020-11-18 um 14:30 schrieb Stefan Claas: > On Tue, Nov 17, 2020 at 11:11 PM Ernst G Giessmann via Gnupg-users > wrote: >> The answer to the second question is: >> >> A SHA-1 collision of two documents D1 and D2 means that the hash values >> Hash(D1) and Hash(D2) are equal, which in turn means that (regardless >> who signs) any signature of D1 (be it OpenPGP or SMIME) can also be used >> as a signature of D2. Any signer and any key, if used with SHA-1! >> >> So if you got a harmless document D to sign, you must be sure that there >> is no evil twin of it. This is usually the case if you are the author of >> D, because the construction of an evil twin remains hard. But it is easy >> to construct docs with the same hash value. >> >> /Ernst. > Thanks for your reply! So if I check the SHA1 checksums > from https://gnupg.org/download/integrity_check.html > and Alice checks from another evil site the same files then we > could have a problem with tools like openssl or the shasum tool. No, here you will have no problem, because we all trust gnupg.org ;-) They will never create two different packages with a SHA-1 collision. The problem shows up, if Mallory creates two documents D1 and D2 being a SHA-1 collision. D1 says that Alice will owe Bob 10 Euros, D2 says the Bob will owe Alice 1000 Euros. Anybody who signs D1 will sign at the same time also D2.? Now I come back to your example. > But, sorry to ask again. > > I like to give an Example. > > Mallory has managed to listen to the clear text communications from > Alice and Bob's online devices. Alice and Bob always use GnuPG > to digitally sign their messages. Fine. Unfortunally Alice accepts SHA-1 signed messages and Bob creates signatures based on SHA-1 > Mallory is *not* in possession of the private keys from Alice and Bob. > Mallory has created a document which causes a collision and was > signed with his own key. No, Mallory does not sign the document, instead he sends D1 to Bob and asks him for his signature. Bob is happy because he gets 10 Euros for free from Alice and immediately signs the document D1. Mallory replaces D1 by D2, leaving the signature untouched. > He sends this message to Alice. What does Alice see when she > does a gpg --verify? I mean she should see, regardless if the > message has a collision or not, that the message was digitally > signed by Mallory's private key and not by Bob's private key. Alice will see a signed by Bob document D2 with a valid signature (due to the fact that SHA1(D1)=SHA1(D2)), where Bob confirms, that he owes Alice money. That Bob signs another document could be proven by showing the other document D1, but which document, D1 or D2, was actually signed remains nevertheless open. In this particular case, it seems very unlikely that Bob had signed D2, but it would have been even better if he had not used SHA-1 at all. And SHA-2(D1) is certainly different from SHA-2(D2). /Ernst. I suspect, that Mallory and Alice were in fact the same person ;-) From sirisha.gopigiri at ericsson.com Wed Nov 18 12:51:51 2020 From: sirisha.gopigiri at ericsson.com (Sirisha Gopigiri) Date: Wed, 18 Nov 2020 11:51:51 +0000 Subject: GPG Encryption/Decryption Failing In-Reply-To: References: , Message-ID: Hi Thank you for the reply and we have looked into the documentation. But after debugging a little we found that we are running into this issue only if we use gpg 2.2.4 version. We tested the same code with gpg 1.4.20 version and it seems to work fine. I mean we ran the test cases for the code like 20 times and we haven't got this error at least once. So we were thinking if we are missing out some configuration with gpg 2.2.4. Could you please help us? Thank you in advance! Best Regards Sirisha Gopigiri ________________________________ From: A NiceBoy Sent: 17 November 2020 07:05 To: Sirisha Gopigiri Cc: gnupg-users at gnupg.org ; E Guhan ; Michelle Eslinger A ; Deepak Kataria Subject: Re: GPG Encryption/Decryption Failing Hello Sirisha, I read from Mozilla's official documentation which states that SOPS command-line client is preferred, the SOPS library should be used only for decryption. The link is here: https://godoc.org/go.mozilla.org/sops/v3 >This package should not be used directly. Instead, Sops users should install the command line client >via `go get -u go.mozilla.org/sops/v3/cmd/sops`, or use the decryption helper provided at >`go.mozilla.org/sops/v3/decrypt`. >We do not guarantee API stability for any package other than `go.mozilla.org/sops/v3/decrypt`. My two cents. Best regards On Fri, 13 Nov 2020 at 17:08, Sirisha Gopigiri via Gnupg-users wrote: > > Hi, > > We are trying to use SOPS+GPG to encrypt/decrypt yaml files and we have written some go wrapper using sops library to perform the required encryption/decryption. However when trying to execute this code the gpg library seems to be failing at keygeneration most of the time with the following error. > > failed to encrypt new data key with master key "681E3A89EB1DAFD36EB883120A73BB48E26694D8": could not encrypt data key with PGP key: golang.org/x/crypto/openpgp error: key with fingerprint 681E3A89EB1DAFD36EB883120A73BB48E26694D8 is not available in keyring and could not be retrieved from keyserver; GPG binary error: gpg binary failed with error: exit status 2, gpg: 681E3A89EB1DAFD36EB883120A73BB48E26694D8: skipped: No public key > > Seems like it is unable to fetch the public key, we are executing the code locally, so we are using the local public and private keys only. > > Though we can list the public key locally, we keep getting the above error quite frequently. However, the encryption/decryption is happening successfully the other times. > > Kindly let us know if we are missing anything. > > We are facing this error only with gpg 2.1.x version, gpg 1.4.x version seems to be working fine. > > > Thank you in advance! > > Best Regards > Sirisha Gopigiri > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > https://protect2.fireeye.com/v1/url?k=146cabc1-4bf79282-146ceb5a-861fcb972bfc-84bc22f40f25e6db&q=1&e=7a9f0586-9961-40e8-9e54-93a010f749b1&u=http%3A%2F%2Flists.gnupg.org%2Fmailman%2Flistinfo%2Fgnupg-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnupg-users at spodhuis.org Wed Nov 18 23:52:14 2020 From: gnupg-users at spodhuis.org (Phil Pennock) Date: Wed, 18 Nov 2020 17:52:14 -0500 Subject: Avoid recipient-compatibility SHA1 In-Reply-To: <483c47e9-aa79-9f57-75fd-ace40fe7a319@gmx.com> References: <20201030041054.GA959448@fullerene.field.pennock-tech.net> <874km7vs7z.fsf@wheatstone.g10code.de> <20201102131532.GA1475874@fullerene.field.pennock-tech.net> <483c47e9-aa79-9f57-75fd-ace40fe7a319@gmx.com> Message-ID: On 2020-11-17 at 22:18 -0700, Mark wrote: > Not to ask a stupid question but how can you tell which algorithm your > keys are using and if using SHA1 update them to a more secure one? With GnuPG, `gpg --list-packets` shows a lot of fine detail, but unless you're familiar with the standards it can be a bit of a slog. If I might be forgiven for mentioning another OpenPGP tool from outside the GnuPG suite which can help here, then Sequioa has an "sq" command with the "inspect" sub-command. Using an old revoked key of mine to demonstrate: -----------------------8< inspect with sequoia >8----------------------- $ gpg --export 0x7C34B4E14CE4F655 | sq inspect -: OpenPGP Certificate. Fingerprint: 1745 1D0F BB5E 88F4 0AC0 08F6 7C34 B4E1 4CE4 F655 Invalid: No binding signature at time 2020-11-18T22:41:24Z Public-key algo: DSA (Digital Signature Algorithm) Public-key size: 1024 bits Creation time: 2001-08-03 17:34:53 UTC UserID: Phil Pennock [censored email address in this list post] Invalid: Policy rejected non-revocation signature (PositiveCertification) because: SHA1 is not considered secure since 2013-01-01T00:00:00Z Bad Signature: [ snip long error which doesn't matter here ] -----------------------8< inspect with sequoia >8----------------------- Here the lack of SHA1 support made the fingerprint invalid, and then it's explicitly called out under the UserID. The other thing to do is to use `gpg --edit-key $YOURKEY` and run `showpref`; it's okay for SHA1 to be _listed_ on the Digest: line, but you also want SHA256 listed. Fine: Digest: SHA256, SHA512, RIPEMD160, SHA1 Not fine: Digest: RIPEMD160, SHA1 With GnuPG: * To fix the preferences, "setpref" in the edit-key menu. * To fix the self-binding: gpg --expert --cert-digest-algo SHA256 --sign-key $YOURKEY There's also the problem of subkey binding signatures. That's a whole other mess, but frankly if you have a key which is worth keeping (it has a good web-of-trust) and you have old subkeys, just go ahead and make new ones with a current version of GnuPG, after you've fixed the self-binding. I _think_, but have not checked, that GnuPG will do the right thing there. Basically, make a subkey for encryption, and a subkey for signing, and call it good. -Phil From gnupg-users at spodhuis.org Thu Nov 19 00:09:39 2020 From: gnupg-users at spodhuis.org (Phil Pennock) Date: Wed, 18 Nov 2020 18:09:39 -0500 Subject: Avoid recipient-compatibility SHA1 In-Reply-To: <483c47e9-aa79-9f57-75fd-ace40fe7a319@gmx.com> References: <20201030041054.GA959448@fullerene.field.pennock-tech.net> <874km7vs7z.fsf@wheatstone.g10code.de> <20201102131532.GA1475874@fullerene.field.pennock-tech.net> <483c47e9-aa79-9f57-75fd-ace40fe7a319@gmx.com> Message-ID: On 2020-11-17 at 22:18 -0700, Mark wrote: > Not to ask a stupid question but how can you tell which algorithm your > keys are using and if using SHA1 update them to a more secure one? I have a better answer than my previous one, because the very next mailing-list I read has a post today from the Sequoia devs where they've written a tool to report this stuff, and even to automatically generate current bindings, if you trust your private key to their code. Looks to do much of what I recommended; I haven't read the code and don't know if the current version will also fix preference lists. (I look forward to this sort of functionality being part of GnuPG natively, as part of key lifecycle maintenance for long-lived keys.) -Phil From neal at walfield.org Thu Nov 19 08:52:39 2020 From: neal at walfield.org (Neal H. Walfield) Date: Thu, 19 Nov 2020 08:52:39 +0100 Subject: Avoid recipient-compatibility SHA1 In-Reply-To: References: <20201030041054.GA959448@fullerene.field.pennock-tech.net> <874km7vs7z.fsf@wheatstone.g10code.de> <20201102131532.GA1475874@fullerene.field.pennock-tech.net> Message-ID: <87o8jt3hrs.wl-neal@walfield.org> Hi Stefan, A chosen-prefix collision attack works as follows: an attacker chooses two message prefixes, and then uses near collisions blocks (in the SHA-1 is a Shambles paper they needed about 10 such 512-bit blocks) to align the internal state of the two hashes. Since SHA-1 is a streaming function, the attacker can also append a common suffix. That is, we want: Hash(prefix #1 || near collision blocks #1 || suffix) = Hash(prefix #2 || near collision blocks #2 || suffix) And the attacker can choose prefix #1, prefix #2, and suffix, but cannot control near collision blocks #1 or near collision blocks #2. One way to exploit this is to create a pair of colliding documents (e.g., something benign and a will), and then convince Alice to sign the benign one. If successful, the signature can be transferred to the other document, and it appears that Alice has sign it too! This attack requires the attacker to hide the near collision blocks in the documents. This is often straighforward: most formats have provisions for comments, or metadata, which the user does not see. The difficulty is to get Alice to sign the first document: if she modifies it (e.g., adds any context), then the hash will be different. But, if Alice is a signing service, then this may be possible even if Alice modifies the document as long as the modifications are predictable. On Wed, 18 Nov 2020 14:30:12 +0100, Stefan Claas via Gnupg-users wrote: > Mallory has managed to listen to the clear text communications from > Alice and Bob's online devices. Alice and Bob always use GnuPG > to digitally sign their messages. > > Mallory is *not* in possession of the private keys from Alice and Bob. > Mallory has created a document which causes a collision and was > signed with his own key. This is currently not possible. What you describe is a preimage attack, not a collision attack. A preimage attack is when you can create a document with the same hash as an existing document. Right now, it is possible to find two documents that collide, but you can only partially control the content of each of them (i.e., you need to add the near collision blocks to both to actually create the collision). :) Neal From spam.trap.mailing.lists at gmail.com Thu Nov 19 22:53:29 2020 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Thu, 19 Nov 2020 21:53:29 +0000 Subject: Avoid recipient-compatibility SHA1 In-Reply-To: <87o8jt3hrs.wl-neal@walfield.org> References: <20201030041054.GA959448@fullerene.field.pennock-tech.net> <874km7vs7z.fsf@wheatstone.g10code.de> <20201102131532.GA1475874@fullerene.field.pennock-tech.net> <87o8jt3hrs.wl-neal@walfield.org> Message-ID: Hi Neal, thanks a lot for the detailed explanation! Best regards Stefan On Thu, Nov 19, 2020 at 7:52 AM Neal H. Walfield wrote: > > Hi Stefan, > > A chosen-prefix collision attack works as follows: an attacker chooses > two message prefixes, and then uses near collisions blocks (in the > SHA-1 is a Shambles paper they needed about 10 such 512-bit blocks) to > align the internal state of the two hashes. Since SHA-1 is a > streaming function, the attacker can also append a common suffix. > That is, we want: > > Hash(prefix #1 || near collision blocks #1 || suffix) > = Hash(prefix #2 || near collision blocks #2 || suffix) > > And the attacker can choose prefix #1, prefix #2, and suffix, but > cannot control near collision blocks #1 or near collision blocks #2. > > One way to exploit this is to create a pair of colliding documents > (e.g., something benign and a will), and then convince Alice to sign > the benign one. If successful, the signature can be transferred to > the other document, and it appears that Alice has sign it too! > > This attack requires the attacker to hide the near collision blocks in > the documents. This is often straighforward: most formats have > provisions for comments, or metadata, which the user does not see. > > The difficulty is to get Alice to sign the first document: if she > modifies it (e.g., adds any context), then the hash will be different. > But, if Alice is a signing service, then this may be possible even if > Alice modifies the document as long as the modifications are > predictable. > > On Wed, 18 Nov 2020 14:30:12 +0100, > Stefan Claas via Gnupg-users wrote: > > Mallory has managed to listen to the clear text communications from > > Alice and Bob's online devices. Alice and Bob always use GnuPG > > to digitally sign their messages. > > > > Mallory is *not* in possession of the private keys from Alice and Bob. > > Mallory has created a document which causes a collision and was > > signed with his own key. > > This is currently not possible. What you describe is a preimage > attack, not a collision attack. A preimage attack is when you can > create a document with the same hash as an existing document. Right > now, it is possible to find two documents that collide, but you can > only partially control the content of each of them (i.e., you need to > add the near collision blocks to both to actually create the > collision). > > :) Neal From gpg at alsd.eu Thu Nov 19 22:08:25 2020 From: gpg at alsd.eu (dalz) Date: Thu, 19 Nov 2020 22:08:25 +0100 Subject: Ask for passphrase once, but require confirmation each time a key is used? Message-ID: The motivation is that I'd like to know when something wants to decrypt a file. I could configure gpg-agent to not cache the key and ask for the passphrase each time, but that is very annoying with a long passphrase, so I was wondering if there was any other way to accomplish that. What I'm thinking is a popup window that (while gpg-agent has the key) replaces pinentry, requiring a simple click of a button to allow the decryption. Is there any way to do this? I'm pretty new to this, so feel free to point out that my idea is pointless / makes no sense if that is the case! -- dalz From 2017-r3sgs86x8e-lists-groups at riseup.net Fri Nov 20 01:20:24 2020 From: 2017-r3sgs86x8e-lists-groups at riseup.net (MFPA) Date: Fri, 20 Nov 2020 00:20:24 +0000 Subject: Ask for passphrase once, but require confirmation each time a key is used? In-Reply-To: References: Message-ID: <1715164171.20201120001957@mail.riseup.net> Hi On Thursday 19 November 2020 at 9:08:25 PM, in , dalz via Gnupg-users wrote:- > I could configure gpg-agent to not cache the > key and ask for the > passphrase each time, but that is very annoying with > a long passphrase If you use a password manager, the length of your passphrase doesn't make any difference. -- Best regards MFPA Yellow snow is not lemon flavoured -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 1207 bytes Desc: not available URL: From gpg at alsd.eu Fri Nov 20 09:45:23 2020 From: gpg at alsd.eu (dalz) Date: Fri, 20 Nov 2020 09:45:23 +0100 Subject: Ask for passphrase once, but require confirmation each time a key is used? In-Reply-To: <1715164171.20201120001957@mail.riseup.net> References: <1715164171.20201120001957@mail.riseup.net> Message-ID: I do use a password manager (https://www.passwordstore.org/), but it stores passwords in pgp-encrypted files - I'd have to insert the passphrase to get the passphrase :) -- dalz From informatik at semy.ch Fri Nov 20 10:23:22 2020 From: informatik at semy.ch (Daniel Bossert) Date: Fri, 20 Nov 2020 10:23:22 +0100 Subject: Thunderbird / Enigmail / Autocrypt Message-ID: <20201120102322.56cbc8506cb075747a3de511@semy.ch> Hello all How secure is it to use Thundebrird with Autocrypt? I use Sylpheed at the moment, but it is not that comfortable to use as Thunderbird. Also, when I send an email, the signature will be shown instead like with thunderbid just an info that the mail is signed Do you have some inputs? Regards Daniel -- PGP: 81A8 1EC7 179C BE5F 02A8 2C01 3FF1 07B6 FC68 F10A -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From wk at gnupg.org Fri Nov 20 12:39:01 2020 From: wk at gnupg.org (Werner Koch) Date: Fri, 20 Nov 2020 12:39:01 +0100 Subject: GPG Encryption/Decryption Failing In-Reply-To: (Sirisha Gopigiri via Gnupg-users's message of "Wed, 18 Nov 2020 11:51:51 +0000") References: Message-ID: <873614mf56.fsf@wheatstone.g10code.de> On Wed, 18 Nov 2020 11:51, Sirisha Gopigiri said: > But after debugging a little we found that we are running into this > issue only if we use gpg 2.2.4 version. We tested the same code with You are really using a 3 year old version which was followed by 20 more releases. You also missed 2.2.8 which fixes CVE-2018-12020. > gpg 1.4.20 version and it seems to work fine. I mean we ran the test Same here. If you use 1.4 at all you need to use the latest version (1.4.23 from 2018)! Isn't it a general advise to first thr the latest version of a software if you run into a bug ;-) Anyway, ppl here can in general better help you if you explain your problem in more detail and best show how it can be replicated. For example, I even don't know what this SOPS is and how it used gpg. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From cqcallaw at brainvitamins.net Fri Nov 20 20:13:22 2020 From: cqcallaw at brainvitamins.net (cqcallaw) Date: Fri, 20 Nov 2020 19:13:22 +0000 Subject: Signing decentralized websites Message-ID: <0Ocu7_u7IGcQBut5VB8Wie7D6kSpzarEqoEq8pGrPyrShZp4n7FMStePe81k2lFhFfvsqERJnid9-ub0N9iPO_KpbTyrJ6JolGOzMFGMGHY=@brainvitamins.net> Hi all, I want to sign my decentralized website, hosted on IPFS + Ethereum Name Service (ENS). PGP detached signatures for every published file seems to be the correct solution. Inline signatures would make validation of HTML documents difficult and binary files would become invalid. Signing the root IPFS CID might work, but would require substantial updates to ENS or an external Ethereum smart contract. Signing a subset of files isn't enough, because corrupted or inauthentic unsigned files could be bundled together with the signed subset and published as authentic. Assuming folks agree with this analysis, I have two additional questions: 1) What's the best way to sign multiple files in parallel? I have 16 CPU threads and would like to take advantage of these (mostly idle) threads to speed up the signing process. GNU parallel and Python's multiprocessing module are behaving oddly, though; when they run gpg in parallel, I'm prompted for my PGP key's password multiple times. I'm running gpg-agent, so I'd expect to be prompted for my password only once. I also observe intermittent memory allocation errors. The --lock-once and --lock-multiple CLI options don't seem to change the behavior. Is there some implementation issue with running multiple gpg signing operations in parallel? 2) Are there any tools to verify detached signatures in the browser? As a user, I'd like my browser to check for a signature file and verify any discovered signatures with any available trusted keys. If a trusted key isn't found, I'd like my browser to check for a pubkey in some known location (e.g. /pubkey.asc) and allow me to trust the bundled pubkey if I so desire. I'd expect browser security considerations to necessitate a separate key store for keys used in the browser, but that's an acceptable solution for me if a key import workflow exists. Does anything like this exist? Thanks! -Caleb From patrick at enigmail.net Sat Nov 21 10:35:29 2020 From: patrick at enigmail.net (Patrick Brunschwig) Date: Sat, 21 Nov 2020 10:35:29 +0100 Subject: Thunderbird / Enigmail / Autocrypt In-Reply-To: <20201120102322.56cbc8506cb075747a3de511@semy.ch> References: <20201120102322.56cbc8506cb075747a3de511@semy.ch> Message-ID: If you think about using the current stable version of Thunderbird (version 78), then there is no Enigmail and no Autocrypt. OpenPGP has been implemented directly in Thunderbird, but there is currently no Autocrypt support in Thunderbird. -Patrick Daniel Bossert via Gnupg-users wrote on 20.11.2020 10:23: > Hello all > > How secure is it to use Thundebrird with Autocrypt? I use Sylpheed at the moment, but it is not that comfortable to use as Thunderbird. > Also, when I send an email, the signature will be shown instead like with thunderbid just an info that the mail is signed > > Do you have some inputs? > > Regards > Daniel > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > From alci at mecadu.org Sat Nov 21 10:37:57 2020 From: alci at mecadu.org (Franck Routier (perso)) Date: Sat, 21 Nov 2020 10:37:57 +0100 Subject: Ask for passphrase once, but require confirmation each time a key is used? In-Reply-To: References: Message-ID: <802a7d94faca7df8d78c7f8871bf225a7d54676b.camel@mecadu.org> You could use a Yubikey: correctly configured, it will required you to touch the yubikey capacitor button to allow the use of the gpg key (once the passphrade is cached of course) Franck Le jeudi 19 novembre 2020 ? 22:08 +0100, dalz via Gnupg-users a ?crit?: > The motivation is that I'd like to know when something wants to > decrypt > a file. I could configure gpg-agent to not cache the key and ask for > the > passphrase each time, but that is very annoying with a long > passphrase, > so I was wondering if there was any other way to accomplish that. > What I'm thinking is a popup window that (while gpg-agent has the > key) > replaces pinentry, requiring a simple click of a button to allow the > decryption. Is there any way to do this? > > I'm pretty new to this, so feel free to point out that my idea is > pointless / makes no sense if that is the case! > > -- > dalz > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From gpg at alsd.eu Sat Nov 21 17:42:45 2020 From: gpg at alsd.eu (dalz) Date: Sat, 21 Nov 2020 17:42:45 +0100 Subject: Ask for passphrase once, but require confirmation each time a key is used? In-Reply-To: <802a7d94faca7df8d78c7f8871bf225a7d54676b.camel@mecadu.org> References: <802a7d94faca7df8d78c7f8871bf225a7d54676b.camel@mecadu.org> Message-ID: Thanks, that could be an option - but not a cheap one it seems. I'm also considering writing a pinentry program that does what I want, however the last attempt ended in nothing but frustration... -- dalz From wk at gnupg.org Sat Nov 21 18:58:49 2020 From: wk at gnupg.org (Werner Koch) Date: Sat, 21 Nov 2020 18:58:49 +0100 Subject: Signing decentralized websites In-Reply-To: <0Ocu7_u7IGcQBut5VB8Wie7D6kSpzarEqoEq8pGrPyrShZp4n7FMStePe81k2lFhFfvsqERJnid9-ub0N9iPO_KpbTyrJ6JolGOzMFGMGHY=@brainvitamins.net> (cqcallaw via Gnupg-users's message of "Fri, 20 Nov 2020 19:13:22 +0000") References: <0Ocu7_u7IGcQBut5VB8Wie7D6kSpzarEqoEq8pGrPyrShZp4n7FMStePe81k2lFhFfvsqERJnid9-ub0N9iPO_KpbTyrJ6JolGOzMFGMGHY=@brainvitamins.net> Message-ID: <87wnyelhgm.fsf@wheatstone.g10code.de> On Fri, 20 Nov 2020 19:13, cqcallaw said: > change the behavior. Is there some implementation issue with running > multiple gpg signing operations in parallel? This is all serialized because the gpg-agent does the actual signing. There is one gpg-agent per GNUPGHOME. Thus the easiest solution for you is to provide copies of the GNUPGHOME and either set this envvar for each process or pass --homedir=decicated-homedir-copy. You can't use links to the same directory because we use lock files. However, it should be possible to sumlink the private-keys-v1.d sub directories. > 2) Are there any tools to verify detached signatures in the browser? > As a user, I'd like my browser to check for a signature file and Mailvelope comes to mind or you write your own thing using gpgme-json as the native messaging server. Mailvelope can use gpgme-json. There is also openpgp.js as a solid Javascript implementation of OpenPGP. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Sat Nov 21 19:02:33 2020 From: wk at gnupg.org (Werner Koch) Date: Sat, 21 Nov 2020 19:02:33 +0100 Subject: Thunderbird / Enigmail / Autocrypt In-Reply-To: <20201120102322.56cbc8506cb075747a3de511@semy.ch> (Daniel Bossert via Gnupg-users's message of "Fri, 20 Nov 2020 10:23:22 +0100") References: <20201120102322.56cbc8506cb075747a3de511@semy.ch> Message-ID: <87sg92lhae.fsf@wheatstone.g10code.de> On Fri, 20 Nov 2020 10:23, Daniel Bossert said: > How secure is it to use Thundebrird with Autocrypt? I use Sylpheed at > the moment, but it is not that comfortable to use as Thunderbird. Checkout Claws-mail which was forked from Sylpheed many years ago. The OpenPGP and S/MIME integration of both was initially done by me but many others improved it at lot. Claws is like Thunderbird cross-platform. The current TB OpenPGP support is pretty basic after they removed Enigmail. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From cqcallaw at brainvitamins.net Sun Nov 22 02:06:53 2020 From: cqcallaw at brainvitamins.net (cqcallaw) Date: Sun, 22 Nov 2020 01:06:53 +0000 Subject: Signing decentralized websites In-Reply-To: <87wnyelhgm.fsf@wheatstone.g10code.de> References: <0Ocu7_u7IGcQBut5VB8Wie7D6kSpzarEqoEq8pGrPyrShZp4n7FMStePe81k2lFhFfvsqERJnid9-ub0N9iPO_KpbTyrJ6JolGOzMFGMGHY=@brainvitamins.net> <87wnyelhgm.fsf@wheatstone.g10code.de> Message-ID: ??????? Original Message ??????? On Saturday, November 21, 2020 9:58 AM, Werner Koch wrote: > On Fri, 20 Nov 2020 19:13, cqcallaw said: > > > change the behavior. Is there some implementation issue with running > > multiple gpg signing operations in parallel? > > This is all serialized because the gpg-agent does the actual signing. > There is one gpg-agent per GNUPGHOME. Thus the easiest solution for you > is to provide copies of the GNUPGHOME and either set this envvar for > each process or pass --homedir=decicated-homedir-copy. You can't use > links to the same directory because we use lock files. However, it > should be possible to sumlink the private-keys-v1.d sub directories. > > > 2. Are there any tools to verify detached signatures in the browser? > > As a user, I'd like my browser to check for a signature file and > > > > Mailvelope comes to mind or you write your own thing using gpgme-json as > the native messaging server. Mailvelope can use gpgme-json. > > There is also openpgp.js as a solid Javascript implementation of > OpenPGP. > > Shalom-Salam, > > Werner > > ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. Many thanks. I've written a Python script (https://github.com/cqcallaw/www/blob/94f0dbb84fa3908acdd698d7b67071bf4f2a723b/sign.py) to handle the parallel signing; I'll look into the browser options shortly. Cheers, -Caleb From informatik at semy.ch Sun Nov 22 04:52:39 2020 From: informatik at semy.ch (Daniel Bossert) Date: Sun, 22 Nov 2020 04:52:39 +0100 Subject: Thunderbird / Enigmail / Autocrypt In-Reply-To: <87sg92lhae.fsf@wheatstone.g10code.de> References: <20201120102322.56cbc8506cb075747a3de511@semy.ch> <87sg92lhae.fsf@wheatstone.g10code.de> Message-ID: <20201122045239.21446ab23e6407fccc091a9d@semy.ch> Hello Werner I would like to use claws-mail, but it looked quite old-school when I last used it. There was no auto-configure of mail setup (find mail-server by itself). But I will install it again and check it out. Thank you Daniel On Sat, 21 Nov 2020 19:02:33 +0100 Werner Koch wrote: > On Fri, 20 Nov 2020 10:23, Daniel Bossert said: > > > How secure is it to use Thundebrird with Autocrypt? I use Sylpheed at > > the moment, but it is not that comfortable to use as Thunderbird. > > Checkout Claws-mail which was forked from Sylpheed many years ago. The > OpenPGP and S/MIME integration of both was initially done by me but many > others improved it at lot. Claws is like Thunderbird cross-platform. > > The current TB OpenPGP support is pretty basic after they removed > Enigmail. > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -- PGP: 81A8 1EC7 179C BE5F 02A8 2C01 3FF1 07B6 FC68 F10A -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From gnupgpacker at on.yourweb.de Sun Nov 22 10:02:54 2020 From: gnupgpacker at on.yourweb.de (gnupgpacker) Date: Sun, 22 Nov 2020 10:02:54 +0100 Subject: Thunderbird / Enigmail / Autocrypt Message-ID: <000101d6c0ae$43a38240$caea86c0$@on.yourweb.de> Claws Mail is an useful alternative, but please keep aware it does not support html mail, text only! https://www.claws-mail.org/manual/de/claws-mail-manual.html#AEN955 Best regards, Chris > Date: Sat, 21 Nov 2020 19:02:33 +0100 > From: Werner Koch > To: Daniel Bossert via Gnupg-users > Subject: Re: Thunderbird / Enigmail / Autocrypt > Message-ID: <87sg92lhae.fsf at wheatstone.g10code.de> > Content-Type: text/plain; charset="us-ascii" > ... > Checkout Claws-mail which was forked from Sylpheed many years ago. > The > OpenPGP and S/MIME integration of both was initially done by me but > many > others improved it at lot. Claws is like Thunderbird cross-platform. > The current TB OpenPGP support is pretty basic after they removed > Enigmail. > Salam-Shalom, > Werner From juergen at bruckner.email Sun Nov 22 12:38:52 2020 From: juergen at bruckner.email (Juergen Bruckner) Date: Sun, 22 Nov 2020 12:38:52 +0100 Subject: Thunderbird / Enigmail / Autocrypt In-Reply-To: <000101d6c0ae$43a38240$caea86c0$@on.yourweb.de> References: <000101d6c0ae$43a38240$caea86c0$@on.yourweb.de> Message-ID: Hi Chris, Am 22.11.20 um 10:02 schrieb gnupgpacker: > Claws Mail is an useful alternative, but please keep aware it does not > support html mail, text only! > https://www.claws-mail.org/manual/de/claws-mail-manual.html#AEN955 > > Best regards, Chris > I don't understand why HTML in e-Mails is so important for some people. For example, I configured my Mailserver to sort out HTML-Mails as Spam as long the sender is not on a whitelist. HTML in e-Mails is a very big security risk in my eyes. regards Juergen -- /?\ No | \ / HTML | Juergen Bruckner X in | juergen at bruckner.email / \ Mail | -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3894 bytes Desc: S/MIME Cryptographic Signature URL: From witwall3 at disroot.org Sun Nov 22 12:42:44 2020 From: witwall3 at disroot.org (ael) Date: Sun, 22 Nov 2020 11:42:44 +0000 Subject: Thunderbird / Enigmail / Autocrypt In-Reply-To: References: <000101d6c0ae$43a38240$caea86c0$@on.yourweb.de> Message-ID: <20201122114244.GA6692@shelf.conquest> On Sun, Nov 22, 2020 at 12:38:52PM +0100, Juergen Bruckner via Gnupg-users wrote: > > I don't understand why HTML in e-Mails is so important for some people. > > For example, I configured my Mailserver to sort out HTML-Mails as Spam as > long the sender is not on a whitelist. > HTML in e-Mails is a very big security risk in my eyes. +1 ael From andrewg at andrewg.com Sun Nov 22 17:06:41 2020 From: andrewg at andrewg.com (Andrew Gallagher) Date: Sun, 22 Nov 2020 16:06:41 +0000 Subject: Thunderbird / Enigmail / Autocrypt In-Reply-To: References: Message-ID: <28181ACD-F9B4-4891-BAD6-6EA752B60FF7@andrewg.com> > On 22 Nov 2020, at 11:40, Juergen Bruckner via Gnupg-users wrote: > > HTML in e-Mails is a very big security risk in my eyes. Not just yours, but unfortunately for many people it is a risk that they must absorb, because e.g. their job may depend upon it. It is not always feasible to scold your correspondents about their use of HTML mail, just as it is not always feasible to complain about their use of Microsoft Word. People need tools that work in the real world; not everyone can afford the luxury of righteous evangelism. A From brad at fineby.me.uk Sun Nov 22 17:17:37 2020 From: brad at fineby.me.uk (Brad Rogers) Date: Sun, 22 Nov 2020 16:17:37 +0000 Subject: Thunderbird / Enigmail / Autocrypt In-Reply-To: <28181ACD-F9B4-4891-BAD6-6EA752B60FF7@andrewg.com> References: <28181ACD-F9B4-4891-BAD6-6EA752B60FF7@andrewg.com> Message-ID: <20201122161737.1e310c15@earth.stargate.org.uk> On Sun, 22 Nov 2020 16:06:41 +0000 Andrew Gallagher wrote: Hello Andrew, >It is not always feasible to scold your correspondents about their use >of HTML mail, True, but when my bank (just one example) tells me about their 'caring about security' and then spewing HTML left, right, and centre, whilst simultaneously disavowing themselves of blame should a virus be transported by their message, they can, quite frankly, go take a running jump. -- Regards _ / ) "The blindingly obvious is / _)rad never immediately apparent" Tell the dinosaurs they just won't survive The History Of The World (Part 1) - The Damned -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From G.Franchetti at gsi.de Sun Nov 22 19:34:00 2020 From: G.Franchetti at gsi.de (Giuliano Franchetti) Date: Sun, 22 Nov 2020 19:34:00 +0100 Subject: gpg does not ask for a passphrase anymore In-Reply-To: <20201122161737.1e310c15@earth.stargate.org.uk> References: <28181ACD-F9B4-4891-BAD6-6EA752B60FF7@andrewg.com> <20201122161737.1e310c15@earth.stargate.org.uk> Message-ID: Hello to all, I use gpg for many years and never got a problem. Usually I encrypt files and directory with public key system. Recently I install duplicity and afterwards I have a strange problem I do not know to solve. The problem is that now if I decrypt an encrypted file, gpg decrypts it without asking the passphrase. I do not know what happened as before it always asked the passphrase but now not anymore. Is anybody having a suggestion on how to make gpg to ask the passphrase again? Many thanks Giuliano From jerry at seibercom.net Sun Nov 22 20:04:41 2020 From: jerry at seibercom.net (Jerry) Date: Sun, 22 Nov 2020 14:04:41 -0500 Subject: Thunderbird / Enigmail / Autocrypt In-Reply-To: <20201122161737.1e310c15@earth.stargate.org.uk> References: <28181ACD-F9B4-4891-BAD6-6EA752B60FF7@andrewg.com> <20201122161737.1e310c15@earth.stargate.org.uk> Message-ID: <20201122140441.00003208@seibercom.net> On Sun, 22 Nov 2020 16:17:37 +0000, Brad Rogers stated: >True, but when my bank (just one example) tells me about their 'caring >about security' and then spewing HTML left, right, and centre, whilst >simultaneously disavowing themselves of blame should a virus be >transported by their message, they can, quite frankly, go take a >running jump. So, off the top of your head, how many viruses, parasites and other assorted malignancies has your bank infected you with? -- Jerry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 659 bytes Desc: OpenPGP digital signature URL: From johanw at vulcan.xs4all.nl Mon Nov 23 03:03:54 2020 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Mon, 23 Nov 2020 03:03:54 +0100 Subject: Thunderbird / Enigmail / Autocrypt In-Reply-To: References: <000101d6c0ae$43a38240$caea86c0$@on.yourweb.de> Message-ID: On 22-11-2020 12:38, Juergen Bruckner via Gnupg-users wrote: > I don't understand why HTML in e-Mails is so important for some people. I agree on a personal level, but if you use your email also to communicate with business users (usually using Outlook) it would be nice to get their mails in a human readable format. Which requires, unfortunately, usually html. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From guru at unixarea.de Mon Nov 23 07:08:12 2020 From: guru at unixarea.de (Matthias Apitz) Date: Mon, 23 Nov 2020 07:08:12 +0100 Subject: Thunderbird / Enigmail / Autocrypt In-Reply-To: References: <000101d6c0ae$43a38240$caea86c0$@on.yourweb.de> Message-ID: <20201123060812.GA29830@r314251-amd64> El d?a lunes, noviembre 23, 2020 a las 03:03:54a. m. +0100, Johan Wevers escribi?: > On 22-11-2020 12:38, Juergen Bruckner via Gnupg-users wrote: > > > I don't understand why HTML in e-Mails is so important for some people. > > I agree on a personal level, but if you use your email also to > communicate with business users (usually using Outlook) it would be nice > to get their mails in a human readable format. Which requires, > unfortunately, usually html. Since ages human read mails in ASCII or UTF-8 text. Why you think this is not a "human readable format"? HTML as e-mail (read carefully: as email, not as attachment) should be forbidden because most MUA automatically fetch additional remote content which violates privacy and can fetch bad content into your system. You're warned. matthias -- Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub ??? ????? ??? ??????, ??? ?????? ??? ?????????? (??a????? ????? ?????) Without books no knowledge - without knowledge no communism (Vladimir Ilyich Lenin) Sin libros no hay saber - sin saber no hay comunismo. (Vladimir Ilich Lenin) From cqcallaw at brainvitamins.net Mon Nov 23 08:22:19 2020 From: cqcallaw at brainvitamins.net (cqcallaw) Date: Mon, 23 Nov 2020 07:22:19 +0000 Subject: Thunderbird / Enigmail / Autocrypt In-Reply-To: <20201123060812.GA29830@r314251-amd64> References: <000101d6c0ae$43a38240$caea86c0$@on.yourweb.de> <20201123060812.GA29830@r314251-amd64> Message-ID: ??????? Original Message ??????? On Sunday, November 22, 2020 10:08 PM, Matthias Apitz wrote: > El d?a lunes, noviembre 23, 2020 a las 03:03:54a. m. +0100, Johan Wevers escribi?: > > > On 22-11-2020 12:38, Juergen Bruckner via Gnupg-users wrote: > > > > > I don't understand why HTML in e-Mails is so important for some people. > > > > I agree on a personal level, but if you use your email also to > > communicate with business users (usually using Outlook) it would be nice > > to get their mails in a human readable format. Which requires, > > unfortunately, usually html. > > Since ages human read mails in ASCII or UTF-8 text. Why you think this > is not a "human readable format"? > > HTML as e-mail (read carefully: as email, not as attachment) should be > forbidden because most MUA automatically fetch additional remote content > which violates privacy and can fetch bad content into your system. > You're warned. > > matthias > At my job, I frequently send out summary charts and graphs surrounded by text. Attachments simply do not work; my audience cannot spend the mental energy to context-switch between text and attachments, and my reports become unusable. I also provide hyperlinks in my reports. Sharing hyperlinks in plaintext emails is possible, but verbose and unfriendly to the viewer. In such circumstances, plaintext email is not human readable; I must use HTML. Thanks, -Caleb From informatik at semy.ch Mon Nov 23 08:30:31 2020 From: informatik at semy.ch (Daniel Bossert) Date: Mon, 23 Nov 2020 08:30:31 +0100 Subject: Thunderbird / Enigmail / Autocrypt In-Reply-To: <28181ACD-F9B4-4891-BAD6-6EA752B60FF7@andrewg.com> References: <28181ACD-F9B4-4891-BAD6-6EA752B60FF7@andrewg.com> Message-ID: <20201123083031.d4be6eda68429b76594f7a98@semy.ch> I don't know if this is the right place here, but as we are discussing about sylpheed and claws-mail as well: I have the following issue with Sylpheed: I searched in Sylpheed for an email of April 20, 2020 for an insurance. I could easily find it in Thunderbird, but Sylpheed couldn't find it. I didn't see the mail in the inbox list of Sylpheed. Could it be Sylpheed doesn't catch all mail? How can I force it to sync everything it finds on the server? I know it's not pgp related, but you guys know these two MUA, so therefore I ask. Regards Daniel -- PGP: 81A8 1EC7 179C BE5F 02A8 2C01 3FF1 07B6 FC68 F10A -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From informatik at semy.ch Mon Nov 23 08:37:11 2020 From: informatik at semy.ch (Daniel Bossert) Date: Mon, 23 Nov 2020 08:37:11 +0100 Subject: Thunderbird / Enigmail / Autocrypt In-Reply-To: References: <000101d6c0ae$43a38240$caea86c0$@on.yourweb.de> <20201123060812.GA29830@r314251-amd64> Message-ID: <20201123083711.8416328c68f1aa371d28b8dc@semy.ch> On Mon, 23 Nov 2020 07:22:19 +0000 cqcallaw via Gnupg-users wrote: > ??????? Original Message ??????? > On Sunday, November 22, 2020 10:08 PM, Matthias Apitz wrote: > > > El d?a lunes, noviembre 23, 2020 a las 03:03:54a. m. +0100, Johan Wevers escribi?: > > > > > On 22-11-2020 12:38, Juergen Bruckner via Gnupg-users wrote: > > > > > > > I don't understand why HTML in e-Mails is so important for some people. > > > > > > I agree on a personal level, but if you use your email also to > > > communicate with business users (usually using Outlook) it would be nice > > > to get their mails in a human readable format. Which requires, > > > unfortunately, usually html. > > > > Since ages human read mails in ASCII or UTF-8 text. Why you think this > > is not a "human readable format"? > > > > HTML as e-mail (read carefully: as email, not as attachment) should be > > forbidden because most MUA automatically fetch additional remote content > > which violates privacy and can fetch bad content into your system. > > You're warned. > > > > matthias > > > > At my job, I frequently send out summary charts and graphs surrounded by text. > Attachments simply do not work; my audience cannot spend the mental energy to > context-switch between text and attachments, and my reports become unusable. > > I also provide hyperlinks in my reports. Sharing hyperlinks in plaintext emails > is possible, but verbose and unfriendly to the viewer. > > In such circumstances, plaintext email is not human readable; I must use HTML. > > Thanks, > -Caleb Probably HTML within an organization should be allowed but not when leaving such one? > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -- PGP: 81A8 1EC7 179C BE5F 02A8 2C01 3FF1 07B6 FC68 F10A -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From guru at unixarea.de Mon Nov 23 09:01:15 2020 From: guru at unixarea.de (Matthias Apitz) Date: Mon, 23 Nov 2020 09:01:15 +0100 Subject: Thunderbird / Enigmail / Autocrypt In-Reply-To: References: <000101d6c0ae$43a38240$caea86c0$@on.yourweb.de> <20201123060812.GA29830@r314251-amd64> Message-ID: <20201123080115.GA30442@r314251-amd64> El d?a lunes, noviembre 23, 2020 a las 07:22:19a. m. +0000, cqcallaw escribi?: > > Since ages human read mails in ASCII or UTF-8 text. Why you think this > > is not a "human readable format"? > > > > HTML as e-mail (read carefully: as email, not as attachment) should be > > forbidden because most MUA automatically fetch additional remote content > > which violates privacy and can fetch bad content into your system. > > You're warned. > > > > matthias > > > > At my job, I frequently send out summary charts and graphs surrounded by text. > Attachments simply do not work; my audience cannot spend the mental energy to > context-switch between text and attachments, and my reports become unusable. > > I also provide hyperlinks in my reports. Sharing hyperlinks in plaintext emails > is possible, but verbose and unfriendly to the viewer. > > In such circumstances, plaintext email is not human readable; I must use HTML. Below you find a good example of such HTML SPAM going directly to an external web server to fetch an "IMG" which could contain malisious code. Is this what you really want to send to your boss or colleagues? matthias Unbenanntes Dokument

FFP2 Maske 1,89 bzw. 1,99 Euro. Die beliebteste und meist getragene Atemmaske der Welt.

 

Sehr geehrte Damen und Herren,

Folgende Angebote sind sofort lieferbar, einzeln verschweisst:

CE-Zertifiziert durch Institut der europäischen Union.
Schutzklasse FFP2!
(KN95) Guter Schutz vor SARSCoV2 - Covid19CoronaViren.

Lieferung an Firmen, Behörden, Arztpraxen, Apotheken, Kliniken usw.:

Abnahmemengen: 10er weise oder 100er weise.

FFP2 Atemschutzmasken: (Auch nach AT, CH, NL, LU)
10 St. 19,90 Euro zzgl. 16 Proz. MwSt.

Angebot für Firmen, Kliniken, Arztpraxen:
100 St. 189,- Euro zzgl. 16 Proz. MwSt.

(Größere Mengen auch sofort lieferbar.)

Bestellen Sie ganz einfach und zeitsparend, in dem Sie uns auf dieses Schreiben einfach antworten.
(Lieferung auf Rechnung. Keine Vorkasse oder ähnliches.)

ceschutz at gmx.de

Versandkostenfreie Lieferung!

6 Wochen Rückgaberecht bei Nichtgefallen! Ihnen enstehen keine Kosten.

 

Mit freundlichen Grüßen,

Michaela Kress
CE-Schutz Vertrieb
Hannover

 

 

 

Bitte antworten Sie uns direkt per Email.

EU-Kunden können gern die Umsatzsteuernummer (VAT) angeben.

 

 

 

From m.mansfeld at mansfeld-elektronik.de Mon Nov 23 11:39:39 2020 From: m.mansfeld at mansfeld-elektronik.de (Mansfeld Elektronik) Date: Mon, 23 Nov 2020 11:39:39 +0100 Subject: Ban HTML mails? Really?(was: Re: Thunderbird / Enigmail / Autocrypt) In-Reply-To: <20201123060812.GA29830@r314251-amd64> References: <000101d6c0ae$43a38240$caea86c0$@on.yourweb.de> <20201123060812.GA29830@r314251-amd64> Message-ID: I'm sorry, but all this stuff becomes slightly off-topic.... Am 23.11.2020 07:08, schrieb Matthias Apitz: > El d?a lunes, noviembre 23, 2020 a las 03:03:54a. m. +0100, Johan > Wevers escribi?: > >> On 22-11-2020 12:38, Juergen Bruckner via Gnupg-users wrote: >> >> > I don't understand why HTML in e-Mails is so important for some people. >> >> I agree on a personal level, but if you use your email also to >> communicate with business users (usually using Outlook) it would be >> nice >> to get their mails in a human readable format. Which requires, >> unfortunately, usually html. > > Since ages human read mails in ASCII or UTF-8 text. Why you think this > is not a "human readable format"? > > HTML as e-mail (read carefully: as email, not as attachment) should be > forbidden because most MUA automatically fetch additional remote > content > which violates privacy and can fetch bad content into your system. > You're warned. > > matthias should.... should... Sorry? In a perfect world we can choose our communication partners. In a semi-perfect world we can at least try to missionate against HTML mails, but maybe with not much success. In the real world we have very often no choice. This battle is lost. The only choice is to harden the MUAs. Everything else is IMHO a quite academic disussion. Regards another Matthias From wk at gnupg.org Mon Nov 23 13:23:39 2020 From: wk at gnupg.org (Werner Koch) Date: Mon, 23 Nov 2020 13:23:39 +0100 Subject: Thunderbird / Enigmail / Autocrypt In-Reply-To: (cqcallaw via Gnupg-users's message of "Mon, 23 Nov 2020 07:22:19 +0000") References: <000101d6c0ae$43a38240$caea86c0$@on.yourweb.de> <20201123060812.GA29830@r314251-amd64> Message-ID: <87a6v8l0s4.fsf@wheatstone.g10code.de> On Mon, 23 Nov 2020 07:22, cqcallaw said: > At my job, I frequently send out summary charts and graphs surrounded by text. > Attachments simply do not work; my audience cannot spend the mental energy to Proper MUAs display inline images without problems. I recall that even exmh did this ~25 years ago. It is just that the marketing department can't enforce the corporate identity on text mails - or are too lazy to create rules which work with plain text (and maybe inline images). And well, I like HTML mails: my main address is free of spam thanks to a simple procmail rule ;-) Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Mon Nov 23 13:29:43 2020 From: wk at gnupg.org (Werner Koch) Date: Mon, 23 Nov 2020 13:29:43 +0100 Subject: Thunderbird / Enigmail / Autocrypt In-Reply-To: <000101d6c0ae$43a38240$caea86c0$@on.yourweb.de> (gnupgpacker's message of "Sun, 22 Nov 2020 10:02:54 +0100") References: <000101d6c0ae$43a38240$caea86c0$@on.yourweb.de> Message-ID: <873610l0i0.fsf@wheatstone.g10code.de> On Sun, 22 Nov 2020 10:02, gnupgpacker said: > Claws Mail is an useful alternative, but please keep aware it does not > support html mail, text only! > https://www.claws-mail.org/manual/de/claws-mail-manual.html#AEN955 Just load one of the HTML viewer plugins. Note that most plugins are an integral part of Claws and thus don't run into problems like Enigmail with Thunderbird. Right, the first-use setup is not as easy as with Thunderbird. That is the difference between a multi-million dollar per year project and a voluntary thingy. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From mwood at iupui.edu Mon Nov 23 16:15:43 2020 From: mwood at iupui.edu (Mark H. Wood) Date: Mon, 23 Nov 2020 10:15:43 -0500 Subject: Thunderbird / Enigmail / Autocrypt In-Reply-To: <20201123060812.GA29830@r314251-amd64> References: <000101d6c0ae$43a38240$caea86c0$@on.yourweb.de> <20201123060812.GA29830@r314251-amd64> Message-ID: <20201123151543.GC5082@IUPUI.Edu> On Mon, Nov 23, 2020 at 07:08:12AM +0100, Matthias Apitz wrote: > El d?a lunes, noviembre 23, 2020 a las 03:03:54a. m. +0100, Johan Wevers escribi?: > > > On 22-11-2020 12:38, Juergen Bruckner via Gnupg-users wrote: > > > > > I don't understand why HTML in e-Mails is so important for some people. > > > > I agree on a personal level, but if you use your email also to > > communicate with business users (usually using Outlook) it would be nice > > to get their mails in a human readable format. Which requires, > > unfortunately, usually html. > > Since ages human read mails in ASCII or UTF-8 text. Why you think this > is not a "human readable format"? > > HTML as e-mail (read carefully: as email, not as attachment) should be > forbidden because most MUA automatically fetch additional remote content > which violates privacy and can fetch bad content into your system. > You're warned. I consider that Mutt gives me the best of both, when I configure it: auto_view text/html and in .mailcap: text/html; \ lynx -dump -force_html %s; \ copiousoutput The text is flattened. The result is sometimes ugly, but readable. Attachments (such as images, or things purporting to be images) are presented separately, and I can open them if I choose. (Or I can copy them out and inspect them in other ways, if I'm suspicious. Examining the un-rendered structure and content of some malicious messages can be briefly entertaining.) I would be mildly surprised to learn that my co-workers, outside of my immediate workgroup, are even aware that I don't see their emails rendered the way they do. And nobody has ever told me, "your message looks funny," except an occasional comment that someone couldn't open the "attachment" (meaning the PGP/MIME signature). Those stopped when I got a corporate X.509 certificate and configured Mutt to use S/MIME for internal mail. Other console MUAs probably can do similar things when configured to do so. -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From johanw at vulcan.xs4all.nl Mon Nov 23 17:57:45 2020 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Mon, 23 Nov 2020 17:57:45 +0100 Subject: Thunderbird / Enigmail / Autocrypt In-Reply-To: <20201123060812.GA29830@r314251-amd64> References: <000101d6c0ae$43a38240$caea86c0$@on.yourweb.de> <20201123060812.GA29830@r314251-amd64> Message-ID: On 23-11-2020 7:08, Matthias Apitz wrote: > Since ages human read mails in ASCII or UTF-8 text. Why you think this > is not a "human readable format"? Sure, hand crafted html in a text reader is human readable. But the html that is vomited by Outlook is not (unless you are a very experienced web developer). > HTML as e-mail (read carefully: as email, not as attachment) should be > forbidden because most MUA automatically fetch additional remote content > which violates privacy and can fetch bad content into your system. Fortunately Thunderbird does not do that by default. But you can select trusted domains for which it does if you like. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From gnupgpacker at on.yourweb.de Mon Nov 23 18:03:54 2020 From: gnupgpacker at on.yourweb.de (gnupgpacker) Date: Mon, 23 Nov 2020 18:03:54 +0100 Subject: Thunderbird / Enigmail / Autocrypt In-Reply-To: <873610l0i0.fsf@wheatstone.g10code.de> References: <000101d6c0ae$43a38240$caea86c0$@on.yourweb.de> <873610l0i0.fsf@wheatstone.g10code.de> Message-ID: <000001d6c1ba$a0172ec0$e0458c40$@on.yourweb.de> Thanks Werner. After further investigation about html mailing with Claws Mail: 'Dillo HTML viewer' project has been updated Jun-2015, not available for Windows. 'litehtml' is available for Windows, but latest update is Oct-2015. In our environment ~ 70% of contacts are using M$ Outlook and its standard html mail functions, so discussion about sense of purpose are mindless even a change of security awareness take place around there... But you are right, html mail is definitely an annoyance and security risk, but wide spreaded compatibility to several communication partners and its needs is necessary! Best regards, Chris > -----Original Message----- > From: Werner Koch > Sent: Monday, November 23, 2020 1:30 PM > ... > Just load one of the HTML viewer plugins. Note that most plugins are > an integral part of Claws and thus don't run into problems like > Enigmail with Thunderbird. From wk at gnupg.org Mon Nov 23 19:00:22 2020 From: wk at gnupg.org (Werner Koch) Date: Mon, 23 Nov 2020 19:00:22 +0100 Subject: [Announce] GnuPG 2.2.25 released Message-ID: <87tutgj6mh.fsf@wheatstone.g10code.de> Hello! We are pleased to announce the availability of a new GnuPG release: version 2.2.25. This maintenance release fixes a minor regression introduced last week with 2.2.24. What is GnuPG ============= The GNU Privacy Guard (GnuPG, GPG) is a complete and free implementation of the OpenPGP and S/MIME standards. GnuPG allows to encrypt and sign data and communication, features a versatile key management system as well as access modules for public key directories. GnuPG itself is a command line tool with features for easy integration with other applications. The separate library GPGME provides a uniform API to use the GnuPG engine by software written in common programming languages. A wealth of frontend applications and libraries making use of GnuPG are available. As an universal crypto engine GnuPG provides support for S/MIME and Secure Shell in addition to OpenPGP. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License. Noteworthy changes in version 2.2.25 ==================================== * scd: Fix regression in 2.2.24 requiring gpg --card-status before signing or decrypting. [#5065] * gpgsm: Using Libksba 1.5.0 signatures with a rarely used combination of attributes can now be verified. [#5146] Release-info: https://dev.gnupg.org/T5140 Getting the Software ==================== Please follow the instructions found at or read on: GnuPG 2.2.25 may be downloaded from one of the GnuPG mirror sites or direct from its primary FTP server. The list of mirrors can be found at . Note that GnuPG is not available at ftp.gnu.org. The GnuPG source code compressed using BZIP2 and its OpenPGP signature are available here: https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.25.tar.bz2 (7027k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.25.tar.bz2.sig An installer for Windows without any graphical frontend except for a very minimal Pinentry tool is available here: https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.25_20201123.exe (4321k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.25_20201123.exe.sig The source used to build the Windows installer can be found in the same directory with a ".tar.xz" suffix. New versions of the GnuPG VS-Desktop(tm) and Gpg4win featuring this version of GnuPG will be released shortly. Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a version of GnuPG installed, you can simply verify the supplied signature. For example to verify the signature of the file gnupg-2.2.25.tar.bz2 you would use this command: gpg --verify gnupg-2.2.25.tar.bz2.sig gnupg-2.2.25.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See the end of this mail for information on the signing keys. * If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either "sha1sum" or "shasum". Assuming you downloaded the file gnupg-2.2.25.tar.bz2, you run the command like this: sha1sum gnupg-2.2.25.tar.bz2 and check that the output matches the next line: 074b21dd07419575fa31c0c5d3116596d5544cbd gnupg-2.2.25.tar.bz2 9a36c4b487563aab82d1436d8bf4518718dcc267 gnupg-w32-2.2.25_20201123.tar.xz d4bc499a192e607f6db5e50bbc885a649ae670fc gnupg-w32-2.2.25_20201123.exe Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese (traditional and simplified), Czech, French, German, Italian, Japanese, Norwegian, Polish, Russian, and Ukrainian being almost completely translated. Documentation and Support ========================= If you used GnuPG in the past you should read the description of changes and new features at doc/whats-new-in-2.1.txt or online at https://gnupg.org/faq/whats-new-in-2.1.html The file gnupg.info has the complete reference manual of the system. Separate man pages are included as well but they miss some of the details available only in thee manual. The manual is also available online at https://gnupg.org/documentation/manuals/gnupg/ or can be downloaded as PDF at https://gnupg.org/documentation/manuals/gnupg.pdf . You may also want to search the GnuPG mailing list archives or ask on the gnupg-users mailing list for advise on how to solve problems. Most of the new features are around for several years and thus enough public experience is available. https://wiki.gnupg.org has user contributed information around GnuPG and relate software. In case of build problems specific to this release please first check https://dev.gnupg.org/T5140 for updated information. Please consult the archive of the gnupg-users mailing list before reporting a bug: https://gnupg.org/documentation/mailing-lists.html. We suggest to send bug reports for a new release to this list in favor of filing a bug at https://bugs.gnupg.org. If you need commercial support go to https://gnupg.com or https://gnupg.org/service.html. If you are a developer and you need a certain feature for your project, please do not hesitate to bring it to the gnupg-devel mailing list for discussion. Thanks ====== Since 2001 maintenance and development of GnuPG is done by g10 Code GmbH and still mostly financed by donations. Two full-time employed developers as well as two contractors exclusively work on GnuPG and closely related software like Libgcrypt, GPGME and Gpg4win. We like to thank all the nice people who are helping the GnuPG project, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, or answering questions on the mailing lists. Many thanks to our numerous financial supporters, both corporate and individuals. Without you it would not be possible to keep GnuPG in a good and secure shape and to address all the small and larger requests made by our users. Thanks. Happy hacking, Your GnuPG hackers p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users'at'gnupg.org mailing list. p.p.s List of Release Signing Keys: To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: rsa2048 2011-01-12 [expires: 2021-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048 2014-10-29 [expires: 2020-10-30] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa3072 2017-03-17 [expires: 2027-03-15] Key fingerprint = 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 Andre Heinecke (Release Signing Key) ed25519 2020-08-24 [expires: 2030-06-30] Key fingerprint = 6DAA 6E64 A76D 2840 571B 4902 5288 97B8 2640 3ADA Werner Koch (dist signing 2020) The keys are available at https://gnupg.org/signature_key.html and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. -- "If privacy is outlawed, only outlaws will have privacy." - PRZ 1991 ... some still don't get it. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From surendersinghpawar at gmail.com Mon Nov 23 18:18:39 2020 From: surendersinghpawar at gmail.com (surender singh pawar) Date: Mon, 23 Nov 2020 09:18:39 -0800 Subject: caching of passphrase is not working in windows , gpg agent version 2.2.23 Message-ID: Hi folks, I am kind of stuck on this, hence reaching out to you guyz. GPG is prompting for passphrase even though passphrase cached in gpg-agent (windows) Following steps I did. 1. installed gpg on windows from https://gnupg.org/download/ (version - 2.2.23) 2. imported the key : - > gpg --import 3. in home dir set the allow-preset-passphrase in gpg-agent.conf. 4. from powershell started agent "$gpgPath\bin\gpg-connect-agent.exe" reloadagent /bye 5. powershell set passphrase "$gpgPath\bin\gpg-preset-passphrase.exe" -v -c -P "$pgpPassphrase" 6. mvn sign and deploy mvn gpg:sign-and-deploy-file -B "-Dfile=E:\Publish\files-1.0.12-test.jar" "-Durl=https://oss.sonatype.org/service/local/staging/deploy/maven2" "-Drevision=1.0.12-test" "-DrepositoryId=ossrh" "-Dversion=1.0.12-test" "-DgroupId=datamodel" "-DartifactId=files" "-Dsources=E:\Publish\files-1.0.12-test-sources.jar" "-Djavadoc=E:\Publish\files-1.0.12-test-javadoc.jar" "-Dpackaging=jar" "-DpomFile=E:\Publish\pom.xml" it prompted the passphrase, I already cached it at step 5. Not sure what is going wrong here .Is it a bug ? Few questions, really appreciate if any one can help or i 1. I don't see any option in windows, to verify if passphrase has been cached . Does anyone know how to do that ? 2. Are there any steps I am missing causing the passphrase prompt? 3. Any other direction , I should investigate. I am kind of stuck here. Any help is very much appreciated. Thanks Surender -------------- next part -------------- An HTML attachment was scrubbed... URL: From philihp at gmail.com Tue Nov 24 01:16:12 2020 From: philihp at gmail.com (Philihp Busby) Date: Tue, 24 Nov 2020 00:16:12 +0000 Subject: Ban HTML mails? Really?(was: Re: Thunderbird / Enigmail / Autocrypt) In-Reply-To: References: <000101d6c0ae$43a38240$caea86c0$@on.yourweb.de> <20201123060812.GA29830@r314251-amd64> Message-ID: <20201124001612.GA29694@valencia.lan> As a personal policy, I do not respond to emails if they are only in HTML. It provides an excellent signal on when an email is actually worth the distraction. Even password-reset/verify-your-email emails will have text-only components. Mailchimp marketing emails, on the other hand, often skip over the plaintext version (text-only emails don't convert in their metrics, i imagine the images don't load and they don't know you read it). This battle has only been lost when you give up. On 2020-11-23T11:39:39+0100 Mansfeld Elektronik wrote 2.0K bytes: > I'm sorry, but all this stuff becomes slightly off-topic.... > > Am 23.11.2020 07:08, schrieb Matthias Apitz: > > El d?a lunes, noviembre 23, 2020 a las 03:03:54a. m. +0100, Johan > > Wevers escribi?: > > > > > On 22-11-2020 12:38, Juergen Bruckner via Gnupg-users wrote: > > > > > > > I don't understand why HTML in e-Mails is so important for some people. > > > > > > I agree on a personal level, but if you use your email also to > > > communicate with business users (usually using Outlook) it would be > > > nice > > > to get their mails in a human readable format. Which requires, > > > unfortunately, usually html. > > > > Since ages human read mails in ASCII or UTF-8 text. Why you think this > > is not a "human readable format"? > > > > HTML as e-mail (read carefully: as email, not as attachment) should be > > forbidden because most MUA automatically fetch additional remote content > > which violates privacy and can fetch bad content into your system. > > You're warned. > > > > matthias > > > should.... should... Sorry? > In a perfect world we can choose our communication partners. In a > semi-perfect world we can at least try to missionate against HTML mails, but > maybe with not much success. In the real world we have very often no choice. > This battle is lost. The only choice is to harden the MUAs. Everything else > is IMHO a quite academic disussion. > > Regards > another Matthias > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From gnupg at raf.org Tue Nov 24 00:01:47 2020 From: gnupg at raf.org (raf) Date: Tue, 24 Nov 2020 10:01:47 +1100 Subject: Thunderbird / Enigmail / Autocrypt In-Reply-To: <87a6v8l0s4.fsf@wheatstone.g10code.de> References: <000101d6c0ae$43a38240$caea86c0$@on.yourweb.de> <20201123060812.GA29830@r314251-amd64> <87a6v8l0s4.fsf@wheatstone.g10code.de> Message-ID: <20201123230147.dl4q6xg6xsdjuo5i@raf.org> On Mon, Nov 23, 2020 at 01:23:39PM +0100, Werner Koch via Gnupg-users wrote: > On Mon, 23 Nov 2020 07:22, cqcallaw said: > > > At my job, I frequently send out summary charts and graphs surrounded by text. > > Attachments simply do not work; my audience cannot spend the mental energy to > > Proper MUAs display inline images without problems. I recall that even > exmh did this ~25 years ago. It is just that the marketing department > can't enforce the corporate identity on text mails - or are too lazy to > create rules which work with plain text (and maybe inline images). > > And well, I like HTML mails: my main address is free of spam thanks to a > simple procmail rule ;-) > > Shalom-Salam, > > Werner Apologies in advance. I know this is all off-topic for a gnupg mailing list, but for those who really hate html email, and are able to function without it, there's a potentially useful mail filter I wrote that converts everything to text that can be converted, and deletes everything else. http://raf.org/textmail https://github.com/raforg/textmail It makes it look like everyone is sending you plain text. :-) For everyone else, I recommend lots of phishing training to mitigate the biggest risks of html email. At least until gmail/outlook/etc. implement, by default, the equivalent of Thunderbird's brilliant Torpedo anti-phishing addon. cheers, raf From guru at unixarea.de Tue Nov 24 06:31:46 2020 From: guru at unixarea.de (Matthias Apitz) Date: Tue, 24 Nov 2020 06:31:46 +0100 Subject: Ban HTML mails? Really?(was: Re: Thunderbird / Enigmail / Autocrypt) In-Reply-To: <20201124001612.GA29694@valencia.lan> References: <000101d6c0ae$43a38240$caea86c0$@on.yourweb.de> <20201123060812.GA29830@r314251-amd64> <20201124001612.GA29694@valencia.lan> Message-ID: <20201124053146.GA35349@r314251-amd64> El d?a martes, noviembre 24, 2020 a las 12:16:12a. m. +0000, Philihp Busby via Gnupg-users escribi?: > As a personal policy, I do not respond to emails if they are only in HTML. It provides an excellent signal on when an email is actually worth the distraction. Even password-reset/verify-your-email emails will have text-only components. Mailchimp marketing emails, on the other hand, often skip over the plaintext version (text-only emails don't convert in their metrics, i imagine the images don't load and they don't know you read it). > > This battle has only been lost when you give up. > There are some other two battles to win: Don't top post and, second, break your text lines around coulmn 72 :-) matthias -- Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub ??? ????? ??? ??????, ??? ?????? ??? ?????????? (??a????? ????? ?????) Without books no knowledge - without knowledge no communism (Vladimir Ilyich Lenin) Sin libros no hay saber - sin saber no hay comunismo. (Vladimir Ilich Lenin) From wk at gnupg.org Tue Nov 24 08:37:31 2020 From: wk at gnupg.org (Werner Koch) Date: Tue, 24 Nov 2020 08:37:31 +0100 Subject: Thunderbird / Enigmail / Autocrypt In-Reply-To: <000001d6c1ba$a0172ec0$e0458c40$@on.yourweb.de> (gnupgpacker's message of "Mon, 23 Nov 2020 18:03:54 +0100") References: <000101d6c0ae$43a38240$caea86c0$@on.yourweb.de> <873610l0i0.fsf@wheatstone.g10code.de> <000001d6c1ba$a0172ec0$e0458c40$@on.yourweb.de> Message-ID: <87mtz7jjd0.fsf@wheatstone.g10code.de> On Mon, 23 Nov 2020 18:03, gnupgpacker said: > After further investigation about html mailing with Claws Mail: > 'Dillo HTML viewer' project has been updated Jun-2015, not available for > Windows. Mature software does not always need updates. Nevertheless the plugin code was recently updated to get rid of conditionals to build with gtk2. Right, it is not availabale for Windows but ... > 'litehtml' is available for Windows, but latest update is Oct-2015. The latest update is just 6 weeks old. The plugin is part of the standard claws installer for Windows. Right, the Windows installer is often behind the source release (right now by a year). But again, this is a project by volunteers. FWIW, for years we distributed Claws as part of Gpg4win but at some point decided that it is better to let the Claws devs do the installer so that we can concentrate on things we are can do best. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Tue Nov 24 08:53:55 2020 From: wk at gnupg.org (Werner Koch) Date: Tue, 24 Nov 2020 08:53:55 +0100 Subject: caching of passphrase is not working in windows , gpg agent version 2.2.23 In-Reply-To: (surender singh pawar via Gnupg-users's message of "Mon, 23 Nov 2020 09:18:39 -0800") References: Message-ID: <87im9vjilo.fsf@wheatstone.g10code.de> On Mon, 23 Nov 2020 09:18, surender singh pawar said: > 4. from powershell started agent > > "$gpgPath\bin\gpg-connect-agent.exe" reloadagent /bye Why do you do this? The import operation already started the agent. In any case to explicitly start the agent please use gpgconf --launch gpg-agent > "$gpgPath\bin\gpg-preset-passphrase.exe" -v -c -P "$pgpPassphrase" You need to add the keygrip to the invocation; from the man page: gpg-preset-passphrase [options] [command] cacheid cacheid is either a 40 character keygrip of hexadecimal characters identifying the key for which the passphrase should be set or cleared. The keygrip is listed along with the key when running the command: gpgsm --with-keygrip --list-secret-keys. Alternatively an arbitrary string may be used to identify a passphrase; it is suggested that such a string is prefixed with the name of the application (e.g foo:12346). Scripts should always use the option --with-colons, which provides the keygrip in a "grp" line (cf. ?doc/DETAILS?)/ Thus something like gpg-preset-passphrase -vcP "$pgpPassphrase" 00112233445566778898aabvccddeeff You should also review your architecture and the attack tree: Why use a passphrase at all (with its KDF induced delays) if you put it into a script. Better remove the passphrase from the key. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From surendersinghpawar at gmail.com Tue Nov 24 09:30:18 2020 From: surendersinghpawar at gmail.com (surender singh pawar) Date: Tue, 24 Nov 2020 00:30:18 -0800 Subject: caching of passphrase is not working in windows , gpg agent version 2.2.23 In-Reply-To: <87im9vjilo.fsf@wheatstone.g10code.de> References: <87im9vjilo.fsf@wheatstone.g10code.de> Message-ID: Thanks for quick reply i did the following command only to put passphrase in cache ( missed id while writing mail ) got id from gpg --list-secret-keys gpg-preset-passphrase -vcP "$pgpPassphrase" *00112233445566778898aabvccddeeff * How can I confirm if a passphrase set in the cache ? is there any debug log which I can see to confirm it. Can you share .if possible, any steps how to build windows gpg agent using source code.? Most docs are for linux. details for question is here as well gnupg - windows :GPG is prompting for passphrase even though passphrase cache is set in gpg-agent - Super User Thanks surender On Mon, Nov 23, 2020 at 11:55 PM Werner Koch wrote: > On Mon, 23 Nov 2020 09:18, surender singh pawar said: > > > 4. from powershell started agent > > > > "$gpgPath\bin\gpg-connect-agent.exe" reloadagent /bye > > Why do you do this? The import operation already started the agent. In > any case to explicitly start the agent please use > > gpgconf --launch gpg-agent > > > "$gpgPath\bin\gpg-preset-passphrase.exe" -v -c -P "$pgpPassphrase" > > You need to add the keygrip to the invocation; from the man page: > > gpg-preset-passphrase [options] [command] cacheid > > cacheid is either a 40 character keygrip of hexadecimal > characters identifying the key for which the passphrase should be > set or cleared. The keygrip is listed along with the key when > running the command: gpgsm --with-keygrip --list-secret-keys. > Alternatively an arbitrary string may be used to identify a > passphrase; it is suggested that such a string is prefixed with > the name of the application (e.g foo:12346). Scripts should > always use the option --with-colons, which provides the keygrip > in a "grp" line (cf. ?doc/DETAILS?)/ > > Thus something like > > gpg-preset-passphrase -vcP "$pgpPassphrase" > 00112233445566778898aabvccddeeff > > You should also review your architecture and the attack tree: Why use a > passphrase at all (with its KDF induced delays) if you put it into a > script. Better remove the passphrase from the key. > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrick at enigmail.net Tue Nov 24 12:26:43 2020 From: patrick at enigmail.net (Patrick Brunschwig) Date: Tue, 24 Nov 2020 12:26:43 +0100 Subject: GpgOSX for Apple Silicon Message-ID: <421282bb-796b-ed49-4957-723aa933ac65@enigmail.net> I have created a first version of GpgOSX 2.2.25 for the new Apple Silicon architecture (ARM processor). However, I don't have a machine to test my build, thus I can't verify if it works. Therefore, if someone has access to an ARM-based Mac, then please get in touch with me. Thanks, Patrick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 834 bytes Desc: OpenPGP digital signature URL: From kloecker at kde.org Wed Nov 25 10:45:28 2020 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Wed, 25 Nov 2020 10:45:28 +0100 Subject: caching of passphrase is not working in windows , gpg agent version 2.2.23 In-Reply-To: References: <87im9vjilo.fsf@wheatstone.g10code.de> Message-ID: <5660109.lOV4Wx5bFT@collossus.localdomain> On Dienstag, 24. November 2020 09:30:18 CET surender singh pawar via Gnupg- users wrote: > Thanks for quick reply i did the following command only to put > passphrase in cache ( missed id while writing mail ) got id from gpg > --list-secret-keys > gpg-preset-passphrase -vcP "$pgpPassphrase" > *00112233445566778898aabvccddeeff * Is this id really the keygrip of the key? Or is it probably the key's fingerprint? You need to add --with-keygrip to make --list-secret-keys show the keygrip. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: From dirk.gottschalk1980 at googlemail.com Thu Nov 26 12:10:59 2020 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Thu, 26 Nov 2020 12:10:59 +0100 Subject: Five volunteers needed (EU only please) In-Reply-To: <20201005163757.0000391f@300baud.de> References: <20201005163757.0000391f@300baud.de> Message-ID: <39d845f714609d1ce09286e991ab1056e9dfae2a.camel@googlemail.com> Hello Stefan. Am Montag, den 05.10.2020, 17:37 +0200 schrieb Stefan Claas: > Hi all, > > while I did some JAB-Code experiments with MMS, to send GnuPG > messages with a dumb > phone, I came up now with a new idea. :-) > > For that I need five people who are willing to share with me their > postal address. > You can send me your address GnuPG encrypted. I will not store your > address on my > computer and will delete your email, once I received it. > > My new idea is to send encrypted postcards or letters, with an NFC > tag attached, > containing a GnuPG clearsigned test message. I like to see if the > postcards will > arrive in proper condition, so that the NFC tags are still readable. > [...] For this test I would suggest to not use NFC stickers or anything like that. I would suggest using plastic cards with embedded NFC Tags. The reason for my suggestion. I'm working at a company which creates and sells solutions for european transportation and logistics companies. We use NFC tags for a drivers license check. These are stickers on the drivers license card to check if it is available. Removing them from the card destroys them. We now had multiple times the problem that those stickers were dead on arrival. We did a fw tests ans saw that the problem occurs only after the tags were on the postal way. Perhaps some strong magnetic fields in the postal systems, or anything like that. Now as we send and receive those tags in boxes, we didn't have Problems anymore. Cards never had this problem, as far as I can tell. The Tags should have enough memory to take encrypted messages. I think at least 12k. The more memory, the longer can the message be. Another benefit of using plastic cards instead of sticker tags is: They are reusable. Kind regards, Dirk -- Dirk Gottschalk GPG key Fingerprint: C8F4 4499 861E D5B7 66FC??18F5 8E34 AF58 6574 32C8 Keyoxide: https://keybase.io/dgottschalk GitHub: https://github.com/Dirk1980ac -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From johndoe65534 at mail.com Thu Nov 26 19:12:27 2020 From: johndoe65534 at mail.com (john doe) Date: Thu, 26 Nov 2020 19:12:27 +0100 Subject: Verifying and checksumming new release is somewhat cumbersom Message-ID: <5fe4d4c3-8ab2-6555-792d-00b59997b9b8@mail.com> Hello all, I see that at (1) and (2) the public keys block and the sha1sums respectively are listed on their corresponding page. Is there a URL to download those sha1sums and those public keyss as files? That is for checksumming I could simply do: $ wget $ sha1sum -c --ignore-missing and for the public key I could do something like: $ wget $ gpg --import $ gpg --verify *.sig I understand that for this last step I could also do: $ gpg --keyserver-options auto-key-retrieve veirfy *.sig Any feedback is appreciated. P.S. If I can I'll be more than happy to help tweaking the release process in that regard. 1) https://gnupg.org/download/integrity_check.html 2) https://gnupg.org/signature_key.html -- John Doe From spam.trap.mailing.lists at gmail.com Thu Nov 26 19:46:53 2020 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Thu, 26 Nov 2020 18:46:53 +0000 Subject: Five volunteers needed (EU only please) In-Reply-To: <39d845f714609d1ce09286e991ab1056e9dfae2a.camel@googlemail.com> References: <20201005163757.0000391f@300baud.de> <39d845f714609d1ce09286e991ab1056e9dfae2a.camel@googlemail.com> Message-ID: On Thu, Nov 26, 2020 at 1:13 PM Dirk Gottschalk via Gnupg-users wrote: > > Hello Stefan. Hi Dirk (long time not seen you!), [...] > For this test I would suggest to not use NFC stickers or anything like > that. I would suggest using plastic cards with embedded NFC Tags. > > The reason for my suggestion. I'm working at a company which creates > and sells solutions for european transportation and logistics > companies. We use NFC tags for a drivers license check. These are > stickers on the drivers license card to check if it is available. > Removing them from the card destroys them. We now had multiple times > the problem that those stickers were dead on arrival. We did a fw tests > ans saw that the problem occurs only after the tags were on the postal > way. Perhaps some strong magnetic fields in the postal systems, or > anything like that. > > Now as we send and receive those tags in boxes, we didn't have Problems > anymore. > > Cards never had this problem, as far as I can tell. > > The Tags should have enough memory to take encrypted messages. I think > at least 12k. The more memory, the longer can the message be. > > Another benefit of using plastic cards instead of sticker tags is: They > are reusable. Thanks, I am aware of these cards, but wanted for my tests to avoid higher costs and I only wanted to see if the postcards and tags arrived in proper condition. Should I use cards in the future then I would also use security envelopes. Best regards Stefan From wk at gnupg.org Thu Nov 26 21:10:50 2020 From: wk at gnupg.org (Werner Koch) Date: Thu, 26 Nov 2020 21:10:50 +0100 Subject: Verifying and checksumming new release is somewhat cumbersom In-Reply-To: <5fe4d4c3-8ab2-6555-792d-00b59997b9b8@mail.com> (john doe via Gnupg-users's message of "Thu, 26 Nov 2020 19:12:27 +0100") References: <5fe4d4c3-8ab2-6555-792d-00b59997b9b8@mail.com> Message-ID: <87ft4vhoad.fsf@wheatstone.g10code.de> Hi, and thanks for asking. On Thu, 26 Nov 2020 19:12, john doe said: > Is there a URL to download those sha1sums and those public keyss as files? The problem with sha1sums is that a single publication would be easy to fake. The only known countermeasure is to widely distribute them. We do have them on the website as you noticed, they are send out by signed mail to several thousand subscribers, and our and other mail archives carry the release announcement with the checksums. No, there is no single file with the checksums because that would be a too easy target for an attacker. > and for the public key I could do something like: > > $ wget > $ gpg --import > $ gpg --verify *.sig And please check the printed fingerprint against copies of the fingerprint distributed in the same way as the checksums. The keys are also quite well connected in the Web-of-Trust, which can also help to to validate them. The advantage of the public keys and the fingerprints is that they do not change and thus you only need to validate them once once and sign the keys so that you can trust them in the future. The release signing key as well as most commit signing keys are token based and thus it is very unlikely that this key material will be leaked. The worst what could happen is that the build machine is compromised by dedicated malware which swaps the to be signed data during the build process - so we would unnoticed sign them with the real key. But well, that is quite advanced and enough people are building from source and closely watch our repositories for signs of intrusion. > I understand that for this last step I could also do: > > $ gpg --keyserver-options auto-key-retrieve veirfy *.sig Don't. For verification always use gpg --verify file.sig file and check the output well. If you need to automate this, use gpgv and put all the trusted signing keys into a dedicated keyring. For automating this with gpg, I would suggest to write a gpgme based tool. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From spam.trap.mailing.lists at gmail.com Fri Nov 27 23:07:12 2020 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Fri, 27 Nov 2020 23:07:12 +0100 Subject: Verifying and checksumming new release is somewhat cumbersom In-Reply-To: <87ft4vhoad.fsf@wheatstone.g10code.de> References: <5fe4d4c3-8ab2-6555-792d-00b59997b9b8@mail.com> <87ft4vhoad.fsf@wheatstone.g10code.de> Message-ID: On Thu, Nov 26, 2020 at 9:18 PM Werner Koch via Gnupg-users wrote: > > Hi, > > and thanks for asking. > > On Thu, 26 Nov 2020 19:12, john doe said: > > > Is there a URL to download those sha1sums and those public keyss as files? > > The problem with sha1sums is that a single publication would be easy to > fake. The only known countermeasure is to widely distribute them. We > do have them on the website as you noticed, they are send out by signed > mail to several thousand subscribers, and our and other mail archives > carry the release announcement with the checksums. > > No, there is no single file with the checksums because that would be a > too easy target for an attacker. Maybe not common among programmers, but you could easily clearsign the shasums text file and then use a public time stamping service additionally, thus first time users would know that the signed shasums file would have been actually signed at day x time y, if you would also provide the .ots file. https://opentimestamps.org Regards Stefan From cqcallaw at brainvitamins.net Fri Nov 27 23:52:27 2020 From: cqcallaw at brainvitamins.net (cqcallaw) Date: Fri, 27 Nov 2020 22:52:27 +0000 Subject: =?utf-8?Q?[cross_post]_Why_does_verification_of_a_detached_signature_result_in_a_=E2=80=9CMessage_digest_did_not_match=E2=80=9D_error_for_OpenPGP.js=3F?= Message-ID: Hi folks, This is an OpenPGP.js question, but I've gotten no answers from Stack Overflow, so I'm widening the cast of my net in hopes a relevant expert is lurking about. I couldn't find any community policy that such a cross post might violate, but if I missed something, please feel free to (gently) inform me of that fact. I can sign and verify a test file through `gpg` without issue, but verifying the signature through OpenGPG.js fails with the error, "Message digest did not match." Why is this? ``` $ gpg --armor --quiet --batch --yes --detach-sig index.html $ gpg --verify index.html.asc index.html gpg: Signature made Wed 25 Nov 2020 08:26:34 PM PST gpg: using RSA key C361FDC3F93B9E8F8BD7E08D5F873051B2D6C347 gpg: Good signature from $ node sandbox.js { signatures: [ { keyid: [Keyid], verified: [Promise], signature: [Signature], valid: false, error: Error: Message digest did not match at Signature.verify (/home/caleb/src/islands/node_modules/openpgp/dist/openpgp.js:41176:11) at process._tickCallback (internal/process/next_tick.js:68:7) at Function.Module.runMain (internal/modules/cjs/loader.js:834:11) at startup (internal/bootstrap/node.js:283:19) at bootstrapNodeJSCore (internal/bootstrap/node.js:623:3) } ], data: 'Test!\n' } ``` sandbox.js (based on [the OpenPGP.js example](https://openpgpjs.org/openpgpjs/doc/index.html#create-and-verify-detached-signatures)): ```javascript openpgp = require('openpgp'); fs = require('fs'); async function sandbox() { path = './' let msg_data = fs.readFileSync(path + "index.html", 'utf8'); let sig_data = fs.readFileSync(path + "index.html.asc", 'utf8'); let pubkey_data = fs.readFileSync(path + "pubkey.asc", 'utf8'); let msg = await openpgp.cleartext.fromText(msg_data); let sig = await openpgp.signature.readArmored(sig_data); let pubkey = await openpgp.key.readArmored(pubkey_data); openpgp.verify({ message: msg, signature: sig, publicKeys: pubkey.keys }).then(function(verified) { console.log(verified); }); } sandbox(); ``` index.html: ``` Test! ``` index.html.sig: ``` -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEw2H9w/k7no+L1+CNX4cwUbLWw0cFAl+/LnoACgkQX4cwUbLW w0cfcBAAlYx+81hVyOmBKF8BVHUyZ7c7xNEDEy8fe2EvEQlz4KL+O5PdWFWdlopl FrdHenxQktfTZPs+bjWTu52OwIGomAQP7Vu4zvkScQw2M4xdBwuJTsB9/hZNJPLX +9lWFVUffYDFPHziNRZCK1vlYpi/fJO1KrmK3ggSJCUylkjl+QtZbSE1EAuxNF4S 3NsxzH1YcyuZP8dvuMFqfHNQVfDcny5AB67fmHdf/aMnq6B05d437qqfVgCjIAKp 11naQ4g8hNSVIwacCWO/sjsa5kSvg2oKI76GTQtBFwybLh9KJTByOUbkbNOJooWM +kpbfWSIQ7Dtl6Q4dDF9C2QJH0Af4YgKjzgT3hWU57FEw/3i7DTseZ3r2YtDcBkv GNaFmRG0mBkRy5pyAliKC91LPWH/FznRQLSA4S2XNce1AxNJKWZpxlbtf79ns6RQ TagE2gRt/vq+UjdN+FL6uyEdhVroWOv2vFTY5bsdD9wy8HyBSyXr0wfSMze7Ci1e t1s098eM9MFwtx2oNOcWbKYxHy4lnDotnGkZ1WFOQMWHTKlVichL1eFNQcx08Mhw 82hoOnS49kNHrzgVV8jP7y+0Nfjcg9vqUV1kR2KkxDO7xoxtwev0k7Ol/mDOA3xi ckPKkU60NlzMHsQe+DzW2wCMKC751ds50huLXMo1txoQ5yo6m6o= =7Z6F -----END PGP SIGNATURE----- ``` pubkey.asc: ``` -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFv5CNMBEADgrYOZdSUwQr+tvcL2l/BtXfJ/baeZQvwT376QnwwZ6dvYjuOE gxLUXmLAXt2x+xhdBztUGk6IDM0X498N4tnoq4nyuRCpeH2zyMqGGXDeiEhZq7gJ P1J6DruBw8zW0K+1Cu8qzJOXXHHVj040A4wlwCeqZiB/ZgxuuFGvoQRtGZhVIMKW ZNPy7fcki3QvbkLzVkUyJJz2LiQMf9IcVGb534SH4NTts+TqEHFL9LAuKk8Yx+nY EMiSTkDMtBCRNDKOM7+XZTfs51KfMivwQd5CxHrm1qB8K67qGApNwXODE16ckGyc ttSbniVtRbaoFw95eusXTHOOSuJzaFvAe5zQXpNPgQfMI3Wi/iqlhy/wb5XCOE3M H6sRKThozGCXrvnPooAetsSTDjw/5kUAPUG0Xc3aDFQf0kXj5NVqkN2MOBv8N3ZP pBtsJwYK+bp8JNzBMuTAOiKXoj/6HyKnFu/UpeisRmjxvJ+naBMRajD5dNsweyyW w5ZNknY9/GTkjnmBycwGd2xCm/Dbq6X+PI1MY69/FzzyoavTM0a63sG4Ipo6sNGu 9pvBHrnwMuE8Jvr2TGC99ems/61vmTujwRcFsb122wpXhRgX4FEv8POnM0EmL/l1 wdr+SRLY+kwWlNrSpfuB7FZXMpt9GqyOPA1FYzrXu9nAgjEgq5oXouroPQARAQAB tCNDYWxlYiBDYWxsYXdheSA8Y3FjYWxsYXdAZ21haWwuY29tPokCPgQTAQIAKAUC W/kI0wIbAwUJCWYBgAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQnT4cLjBJ fqtb/Q//TfWxvQmVdbOd6pBymFgfAoi+K8fKg4H38ogbeFjxeEUBz0+tfcnQ0Wj+ 4v4kTha71br7MzPr5P1vCM47lgbigoEJlSay0J5CKZq3fe1xXrUh4Mat+Fq8EDbM QWYum5MAelD0yjfr7SbGNjiVm6zVyLAC3qRFCdjvxVaYn0lpEwXPMwH3SOM2z4D/ UiUcOlJYuYMgyxAXbGjK7mpBFUtS49LiY1qZq20ZMLEGcv+7tydNA4nKtBru7EW8 Afnx9LM3+xyk6XPJa/b0AKt3N5GEFrwwx8RDmmoIa3uqxnjFvbUfLGmOqBCbawRz d871e7xZCwUr/YqIgtomOMJlLmyVMiyXrHJOLywRDQGWPYUXVQV6/6YstWmCrY8e m7sUzSJyWafh6sof4thbWfMTgePrskbnsN1VZULc0JrYTEXW3oNRdgk8FfxCcT9P MszKhIR/rEhDHMY+A4rpOG1/tC2vw1B0TyDYyueCa9K8ubogFLQpKKpaOVuMqIQx GcgE6utdtmXtJlDrPDM4DCPEeyqw9/W5Dfmuj9sQHlOE0J243GerpJWp2iGuV27E YlUjAEcKXGIpgbNyucd5/e2Xvvb8HnyWeK4IiI9vDDminjXefYTv8Z5/736aTzEx Gwcnh5B+c9P+RRmwUhHvdu7POclnbKYmUEVk2wW462lczVA2nDi0K0NhbGViIENh bGxhd2F5IDxjcWNhbGxhd0BicmFpbnZpdGFtaW5zLm5ldD6JAlcEEwEKAEECGwMF CQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AWIQRyvkAwXZiPVUzqGgSdPhwu MEl+qwUCX6bX9wIZAQAKCRCdPhwuMEl+q7AvEACXYo7sEn1JW6lszLD6/DBxmgog fVl4YVO1pGIc5Ub2Ua3FrDNOCWNIPpkB65rx9btK5j6mtqdqUGpKKcVGoAf6y7m7 PlL9RLTUwG/T4xTMprQlYnrK5yjQRnRzHzi5jyOEcweDtwlp6J3Jm0uBYywIBt0+ QtogNWMrdOyuBqlA0uhCDqVcUjuur31N7BmYFe6SZ80GBAU/zFVXKRWp3ZLgLOkU AulaVZ/WwFrAIi1vM7pCx4T2gQ9fXnxj7xzvuhnAJXmODlPlF7rPnqevrTpv0Dqv M4rxmjCCFdOfxjPkFjdwskbzFRJe9zbbhRUkDFuksvxM/ixROo+wMq9zlaRTzbiG G29ee3WnNIn3WW8NOvy4tsxIvQOjufk1wP4nnIjXlxn8qPQrmkCcZGJqSlrmuFvx yAj/qEGAb6w0Yu+A+6hgb6amUhxI2CIL3leLOW+pXjVqEKknJ7D52OEk5m50YTam xfzl6SiqE/QQST1WOnBUtYvOBG/v+om/tXvkSkQRALhoEOa8lj9ZOUs76w139qm3 ZNVls+cBAaKBr8s4Z9X6MohG8/ls/frFWYlqN4ettG3ULsW88RQUzr3J9PtHSHnD A8SZtqqSZY7kKmw/fk3R279t0BJzTqKCh3gybxTXWPIG44G30lsbP5pqK2ejt9nu YDnNvZjCB05a9Rue07kCDQRb+QjTARAAxiIZO0TrY73yrBaeXtIknEVT3Z2+OhJd YL6RAaZk0sf6iX6CFdEAeO7XS3W3SZEITzfl3+rkdBJ3k3HKLdQyrCCpjOUK4orW bLsEBTQl7IDMJJ4YBO2BSc7I+akiq+Flx8t4JefAVlR2i5Vf/FxqutoxyZ13L/2k gyqc95UAhVfykJB/vUgodV1VAbOXmIEL53MAXDC7HQWUuW3eKzWsJnw+i1LD+ZPE bYD/mIKdKeqWQZW6E6N7jj7dXhErQn/0cFpIssSxWPNF63mcPTj4Yq61ruIqjarV tVGKL40ekL2grAF0n/2iERYSqUo18YATlJjrMbxR1k4Td67hSEJFuarJYwQqPI93 20/izYJMPrdwAzUf/jPa0lDZqaQK7xuln2/cpusFZC4p98A7Dn6bHxkYv3ymGhVz WiAohX6vc5kYh5Qdsh1pUloInjGm2f0QimOGt+PU7U9KFGcj5c4UGaJkrLM9Qeoa qUGN7pwzBF6NRdmAOuyB7F/e7xhMz6xdQ8iAuwbrLcwi6i1FcworwoRMmaK93etN +1hrYjQ+ru95ZXodvPkVTeYAm8NCoVE3CmMxi3RhNAF/W1xvxO459Cj3mRNpIg1N uw4YvhtKNW1HQhUzZr7HUu1TyKsk8uX6XTn6SnXZvd5gO/Xi7merVwvH0XlM5k9J f6a6Xziv+ZUAEQEAAYkCJQQYAQIADwUCW/kI0wIbDAUJCWYBgAAKCRCdPhwuMEl+ q87mEADU3k1JuulGC5It3S+bNd692tcofCY0Q75EBCl0SOi0xFEh0KyCqG9DEjCo MSFV033G5oVZ/CGQhDw3MQ1wSVVZn3yviGlEkde0KjCWXawOcuJo5GJDtltCegne dcnCp+DqPnwhSL3OkASYG015DACq1iIGJSN/TCEPx3+myhKrdGjpDWA/6tUm1985 AQ3q2qzJi6LskOKHw/stel72OHexTjTFWQVFq+AVi63O3HMhOQ/wdEhO/5Snvr1P bp388hi+jbubyysbAtU0VO5fuHKE+NCVUJ+DB0ju2UqtFiVP/jj6efOC3piEKFfn pSVYCbGwJpJdM9DNPc5RQFN3hCxe0CQovReitz5KdCGQmEra18WmFgSdn/RBVHUy xvh/FSntsfeQ6h6QwzFGvab5s2VUCVfAzyRCsZUTZ0i/yIiQe838oYsCDo5DxUgW r8pplwqlH14mItrmv3Tlwifgol5XCESDub4nnBMsI1g18K/Mva2wghg02ClJAjxl 7bakRe5I+G1OD6n0uv/HFJNhW29SFqfFvyJLv754C7Q/iR0p1UNyuV6gqK6/Nf1B Y2c/1fpSqvoS1JUTtLIOxJNEOtFqDwylp1K3xITMjIQFESbxfEp5wrA5y2aLExTM cBkEBIB/Ts/5Jekwo1/8khZ1vbjMM8GqaL4WEBlOth5heZ/Jh7kCDQRdSQxpARAA vTaGTccLWcrknJlLfer5KH+X8T/Uqj6KSS7HIA9xo59sP4cXpMQihoUc+7zemq7R TnBryudxQOdllQw3XUYvXC5/iiHJffSxAh1s7UjlxKbvG6cPs5FKHQ1ElZ9n6WEx GuA/FSyLHnKtjaldHM1VaNBfShs92xvolyWFohmjcjrod5G1AEDk+UrHM7PKYHCe 65pfils9uoGnUe9+wYBRfcQtQsODtXLkEQez8nLwZvfxn/IzQ8ZJttRy6kkrzOor ZyFKRsLEeugQ5Oih5xmzyPRYAS0GUhfHOSYZnUQmfw1ikcpo5ZIKDGARZgUY9rSj KKqpaN/BE15VqXuigiSfUf/jEVf1Kk+8SQ+Tt5V12yJUYZQNGr+zEZOu/gQe8hNM /Hfx0MK6NYxOqhjTdxqbsxHLOCG4cJWp7LS9OqGmCGu9V0MpK8/Dg8Zg5+LL4dM2 dsqroRVWSOao6rnqizOYZ0oniNwWOAm3+QMmwrgRg0TJv7q56Mh8k5I1QHjqWcVw BPOlRvfog1iOXkC7er4hZgYGRcdeE4ztJsqhfUkC1wBRj9PnhtlfMeXaZ/S/oYdd EnsiCKbntCzYi8jvF/Ax8pTNG5e5RjQVYAitK03NG3MK0dgrPya0J9cLwNrefbIm /Oh5QdY464WJGkpJvw67jfytT3F477pUHBqY0WaZbmMAEQEAAYkEcgQYAQoAJhYh BHK+QDBdmI9VTOoaBJ0+HC4wSX6rBQJdSQxpAhsCBQkSzAMAAkAJEJ0+HC4wSX6r wXQgBBkBCgAdFiEEw2H9w/k7no+L1+CNX4cwUbLWw0cFAl1JDGkACgkQX4cwUbLW w0eEIw//YFO4X9g2C5eLDU7RtgMu+RFHyOTncpQwCcmr4RpQSD/Cz5K9si3zby6f eq/niEXzU88cYPCIMBT0JwEKArZlgQv8vbBKiT4C79QmlIkShSsp56dlSV4KqzyA u8dMPFgXR2/PKEiWyflHhLVP6cx2hNgWEMJ0WT8kTcx33GnGtGxMdYtr7y15Wxe3 okWhOpVEgYFeWRudxwpcPPfayIlBsW7sBiI0ez2hlfa29iQQP7kSSNw27nn4ARBQ wisythPsKwvzaugcEyEXSf1rmI5kfcvHBoNBwdLnA1S7UTgs+NF2xeMsjOas+5ag quUkghcndM0DIM6Oe2R1QrBsEu3oyqQJWjWK3MkF8gT+Fs9NM38J+8Yij54w0lXA ZdQOU8Nbz2B6w2HhMXJctry/Te3swZN7czKl65PZ3nxU3qP1AvWiy91MjZq94BUU yGjp44/t7gHATEAxo6n0hCWBy/hmXlBb2vVV4QptUBi8Xh0nUcYtAEZiK4bl9KIw XpTGeg9bxMokgo3l4FiVRRLOeCJaljnp3WagqQ0enet0s/VXMlTgBG3mH13fWVZM GEv1GuChi01IcBJ2qSGz0BFaAP2nlfGOomhvpkT4jM6C9cZgcFk6cJ/jTtMDEEXR +AKA33kdM286NulrMQveT3C/1mQoHksCwicq6jY0tqPBUzkRSL6ibg/+LPBPMHGD s2XohNNNRQ34UG0W9Go5ZWfDfiRpIyix8YKENNQN8OEM6kGyyuxoHkhioSno33cV pbnNA3sIcqmvxyxaw+352u5zgGSNJmHE4ObKbZs8s5A1UW49Tf0SyeUbxKRQzogr B6oGlfqEjA0gZ2aVwa7ZIu0gt1bjrMtF7d9uAkoBuTkwkQyxQ9qIJ5Tin8tQE1q1 idofW0FpzXNK0N5n3jUOOIajWbret4eZ3YXUFNh0gX4UD8VJ811ZzaaqCDcCz+Ss B4JiPcb9kOz8i+R7FhPvi6yqxd5+uRkMdCL+0WtXqzGZpd7YXZwf938fAfdGabgb /3SaSsMKkZrheQNINAh5G1OQ88CB/kD/sTBN7dv7qakdJlB1cr0oKALVu5IXvyDb kMyYp8xIT9pT7vLdDs7hJDu7OhTBNf9FSIa075V68e5jZ2J67k4LhXkaViAsQylY eZ0nR4nbfRGugPsQml4KX+N9m8eIi4OGWobE9oDpDP2gGuZY56Vf80Ao6fRDQUtf /d7rPF7aYg3ST0GaTwQO/2tSEPn6xaMjGr7I9NQmtwQxfa3rt8ESEsO0sEcpR02k wwhdk/GvJf8V/lR747/xNY5ZNr+fujPSLCBrWqJBfK+61DUpqeKN6cHPjNELvQTo tYSsa0zo3W8EwXhkoia5hOf/YhubcMkhqXU= =Hgou -----END PGP PUBLIC KEY BLOCK----- ``` `npm list` shows openpgp at 4.10.8. -------------- next part -------------- An HTML attachment was scrubbed... URL: From karmanyaahm at gmail.com Sat Nov 28 07:00:01 2020 From: karmanyaahm at gmail.com (Karmanyaah Malhotra) Date: Sat, 28 Nov 2020 01:00:01 -0500 Subject: Changing compression configuration Message-ID: I'm wondering if it would be possibly to somehow use something like (pbzip2)[https://www.archlinux.org/packages/community/x86_64/pbzip2/] instead of just regular bzip2 when compressing files. I'm not sure if this would work with how GnuPG is designed, but it would be nice if compression could be multi-threaded since using one thread is the bottleneck in my system when using GPG with large files (backups so 100s GBs). I have tested that encryption can be sped up by disabling compression but that would increase storage usage. (or using another algorithm, but ZLIB and ZIP are both CPU bottlenecked). Thanks, Karmanyaah Malhotra -- Contact me at https://karmanyaah.malhotra.cc/contact/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 554 bytes Desc: OpenPGP digital signature URL: From johndoe65534 at mail.com Sat Nov 28 07:57:05 2020 From: johndoe65534 at mail.com (john doe) Date: Sat, 28 Nov 2020 07:57:05 +0100 Subject: Verifying and checksumming new release is somewhat cumbersom In-Reply-To: <87ft4vhoad.fsf@wheatstone.g10code.de> References: <5fe4d4c3-8ab2-6555-792d-00b59997b9b8@mail.com> <87ft4vhoad.fsf@wheatstone.g10code.de> Message-ID: <469842e0-86fa-cd41-f80f-be7efec7d754@mail.com> On 11/26/2020 9:10 PM, Werner Koch wrote: > Hi, > > and thanks for asking. > Thanks for this. To be sure that I understand you correctly, I took the liberty of rewording your answers. > On Thu, 26 Nov 2020 19:12, john doe said: > >> Is there a URL to download those sha1sums and those public keyss as files? > > The problem with sha1sums is that a single publication would be easy to > fake. The only known countermeasure is to widely distribute them. We > do have them on the website as you noticed, they are send out by signed > mail to several thousand subscribers, and our and other mail archives > carry the release announcement with the checksums. > If I look at Debian (1) for example, the checksum file is gpg signed. Assuming that I understand correctly, the Debian approach is not a safe way to make the checksums available?propagate? > No, there is no single file with the checksums because that would be a > too easy target for an attacker. > Even if the file would be gpg signed? >> and for the public key I could do something like: >> >> $ wget >> $ gpg --import >> $ gpg --verify *.sig > > And please check the printed fingerprint against copies of the > fingerprint distributed in the same way as the checksums. The keys are > also quite well connected in the Web-of-Trust, which can also help to to > validate them. > You mean by checking if the fingerprint of the downloaded keys match the one listed on the web site? > The advantage of the public keys and the fingerprints is that they do > not change and thus you only need to validate them once once and sign > the keys so that you can trust them in the future. > Okay, if the fingerprints matches I should sign the keys with mine. >> I understand that for this last step I could also do: >> >> $ gpg --keyserver-options auto-key-retrieve veirfy *.sig > > Don't. For verification always use > > gpg --verify file.sig file > Okay, won't do that anymore. > and check the output well. If you need to automate this, use gpgv and > put all the trusted signing keys into a dedicated keyring. For > automating this with gpg, I would suggest to write a gpgme based tool. > If I want to verify a new release,: - Manually: take advantage of gpgv - Unattended: use a wrapper around gpgme Your input is much appriciated. 1) https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/ -- John Doe From spam.trap.mailing.lists at gmail.com Sat Nov 28 08:59:40 2020 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Sat, 28 Nov 2020 07:59:40 +0000 Subject: Mobile mini computers for GnuPG/OpenPGP usage instead of smartphone usage Message-ID: Hi all, some of you may remember the recent thread from me about OpenPGP usage with smartphones. Since I sold my Android smartphone a while ago I thought why not look for other mobile devices, which are smaller than regular notebooks and which are maybe better suited (for me) than pure Linux smartphones. This would also have the advantage that one can use his preferred MUA instead of the once available for Android/iOS. After googling a bit I found these IMHO super mini PCs, which looked very attractive to me and I purchased one (should be delivered in a couple of days). https://www.gpd.hk/gpdmicropc and for fans of MacBook designs: https://www.gpd.hk/gpdpocket2 Hope you find this info useful! P.S. I purchased the GPD MicroPC with Ubuntu Mate instead of Microsoft Windows. P.P.S. These little computers are mostly sold out when looking around, but I had luck to find a German reseller who still has some in stock. Regards Stefan From guru at unixarea.de Sat Nov 28 09:44:32 2020 From: guru at unixarea.de (Matthias Apitz) Date: Sat, 28 Nov 2020 09:44:32 +0100 Subject: Mobile mini computers for GnuPG/OpenPGP usage instead of smartphone usage In-Reply-To: References: Message-ID: <20201128084432.GA2638@c720-r342378> El d?a s?bado, noviembre 28, 2020 a las 07:59:40a. m. +0000, Stefan Claas via Gnupg-users escribi?: > ... > > After googling a bit I found these IMHO super mini PCs, which looked very > attractive to me and I purchased one (should be delivered in a couple of days). > > https://www.gpd.hk/gpdmicropc > > and for fans of MacBook designs: > > https://www.gpd.hk/gpdpocket2 > > Hope you find this info useful! > > P.S. I purchased the GPD MicroPC with Ubuntu Mate instead of Microsoft Windows. > > P.P.S. These little computers are mostly sold out when looking around, but I had > luck to find a German reseller who still has some in stock. Hi Stefan, Could you please share with me the contact to the German reseller? Thanks in advance. Have you seen this alternative: https://puri.sm/posts/librem-5-visual-walkthrough/ I funded the campaign in October 2017 (USD 599) and now, after three years they start delivery to the backers. matthias -- Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub ??? ????? ??? ??????, ??? ?????? ??? ?????????? (??a????? ????? ?????) Without books no knowledge - without knowledge no communism (Vladimir Ilyich Lenin) Sin libros no hay saber - sin saber no hay comunismo. (Vladimir Ilich Lenin) From spam.trap.mailing.lists at gmail.com Sat Nov 28 11:05:06 2020 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Sat, 28 Nov 2020 11:05:06 +0100 Subject: Mobile mini computers for GnuPG/OpenPGP usage instead of smartphone usage In-Reply-To: <20201128084432.GA2638@c720-r342378> References: <20201128084432.GA2638@c720-r342378> Message-ID: On Sat, Nov 28, 2020 at 9:48 AM Matthias Apitz wrote: > Hi Stefan, > > Could you please share with me the contact to the German reseller? > Thanks in advance. Hi Matthias, sure, I just send you an email via my ctemplar account. Best regards Stefan From juergen at bruckner.email Sat Nov 28 15:35:09 2020 From: juergen at bruckner.email (Juergen Bruckner) Date: Sat, 28 Nov 2020 15:35:09 +0100 Subject: Mobile mini computers for GnuPG/OpenPGP usage instead of smartphone usage In-Reply-To: References: Message-ID: <970cb566-619d-02fb-b70f-5a83381f2968@bruckner.email> Hello Stefan, Am 28.11.20 um 08:59 schrieb Stefan Claas via Gnupg-users: > Hi all, > > some of you may remember the recent thread from me about OpenPGP usage > with smartphones. Since I sold my Android smartphone a while ago I thought > why not look for other mobile devices, which are smaller than regular notebooks > and which are maybe better suited (for me) than pure Linux smartphones. > > This would also have the advantage that one can use his preferred MUA > instead of the once available for Android/iOS. > > After googling a bit I found these IMHO super mini PCs, which looked very > attractive to me and I purchased one (should be delivered in a couple of days). > > https://www.gpd.hk/gpdmicropc > > and for fans of MacBook designs: > > https://www.gpd.hk/gpdpocket2 > > Hope you find this info useful! > > P.S. I purchased the GPD MicroPC with Ubuntu Mate instead of Microsoft Windows. > > P.P.S. These little computers are mostly sold out when looking around, but I had > luck to find a German reseller who still has some in stock. > > Regards > Stefan Could you please tell me more when you get this device? best regards Juergen -- /?\ No | \ / HTML | Juergen Bruckner X in | juergen at bruckner.email / \ Mail | -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3894 bytes Desc: S/MIME Cryptographic Signature URL: From kloecker at kde.org Sat Nov 28 16:38:27 2020 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Sat, 28 Nov 2020 16:38:27 +0100 Subject: [cross post] Why does verification of a detached signature result in a =?UTF-8?B?4oCcTWVzc2FnZSBkaWdlc3QgZGlkIG5vdCBtYXRjaOKAnQ==?= error for OpenPGP.js? In-Reply-To: References: Message-ID: <1667962.ExSmAaXVfq@breq> On Freitag, 27. November 2020 23:52:27 CET cqcallaw via Gnupg-users wrote: > I can sign and verify a test file through `gpg` without issue, but verifying > the signature through OpenGPG.js fails with the error, "Message digest did > not match." Why is this? Could be a problem with text mode vs. non-text mode. By default, gpg uses non- text mode when signing something. Try adding --textmode to gpg's command line. > let msg = await openpgp.cleartext.fromText(msg_data); This is just a wild guess, but fromText() could imply text mode in OpenPGP.js. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: From spam.trap.mailing.lists at gmail.com Sat Nov 28 16:49:39 2020 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Sat, 28 Nov 2020 16:49:39 +0100 Subject: Mobile mini computers for GnuPG/OpenPGP usage instead of smartphone usage In-Reply-To: <970cb566-619d-02fb-b70f-5a83381f2968@bruckner.email> References: <970cb566-619d-02fb-b70f-5a83381f2968@bruckner.email> Message-ID: On Sat, Nov 28, 2020 at 3:38 PM Juergen Bruckner via Gnupg-users wrote: > > Hello Stefan, [...] > Could you please tell me more when you get this device? Hi Juergen, sure, I will tell you more once I have the device. It may take a couple of days due to delivery schedules at DHL, because of COVID-19. Best regards Stefan From guru at unixarea.de Sat Nov 28 19:08:53 2020 From: guru at unixarea.de (Matthias Apitz) Date: Sat, 28 Nov 2020 18:08:53 +0000 Subject: Mobile mini computers for GnuPG/OpenPGP usage instead of smartphone usage In-Reply-To: <970cb566-619d-02fb-b70f-5a83381f2968@bruckner.email> References: <970cb566-619d-02fb-b70f-5a83381f2968@bruckner.email> Message-ID: <9kqfyr.qkiqeu.2wbngi-qmf@ms-10.1blu.de> > > Could you please tell me more when you get this device? > > best regards > Juergen I will do too :-) matthias -- Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub ??? ????? ??? ??????, ??? ?????? ??? ?????????? (??a????? ????? ?????) Without books no knowledge - without knowledge no communism (Vladimir Ilyich Lenin) Sin libros no hay saber - sin saber no hay comunismo. (Vladimir Ilich Lenin) From cqcallaw at brainvitamins.net Sat Nov 28 21:54:10 2020 From: cqcallaw at brainvitamins.net (cqcallaw) Date: Sat, 28 Nov 2020 20:54:10 +0000 Subject: =?utf-8?Q?Re:_[cross_post]_Why_does_verification_of_a_detached_signature_result_in_a_=E2=80=9CMessage_digest_did_not_match=E2=80=9D_error_for_OpenPGP.js=3F?= In-Reply-To: <1667962.ExSmAaXVfq@breq> References: <1667962.ExSmAaXVfq@breq> Message-ID: ??????? Original Message ??????? On Saturday, November 28, 2020 7:38 AM, Ingo Kl?cker wrote: > On Freitag, 27. November 2020 23:52:27 CET cqcallaw via Gnupg-users wrote: > Could be a problem with text mode vs. non-text mode. By default, gpg uses non- > text mode when signing something. Try adding --textmode to gpg's command line. > > > let msg = await openpgp.cleartext.fromText(msg_data); > > This is just a wild guess, but fromText() could imply text mode in OpenPGP.js. Excellent, adding --textmode to gpg's command line resolved the issue. Thanks! -Caleb From thomas at glanzmann.de Sun Nov 29 08:24:11 2020 From: thomas at glanzmann.de (Thomas Glanzmann) Date: Sun, 29 Nov 2020 08:24:11 +0100 Subject: graphical pinentry no longer working after upgrading to debian bullseye and pinentry and how to resolve it Message-ID: <20201129072411.GE30751@glanzmann.de> Hello, I just upgraded to Debian bullseye and the graphical pinentry did not work anymore. I got the following error message: 2020-11-28 21:37:41 gpg-agent[3535] DBG: connection to PIN entry established 2020-11-28 21:37:41 gpg-agent[3535] DBG: chan_10 -> INQUIRE PINENTRY_LAUNCHED 3633 gtk2:curses 1.1.0 - - - 2020-11-28 21:37:41 gpg-agent[3535] DBG: chan_10 <- END 2020-11-28 21:37:41 gpg-agent[3535] DBG: error calling pinentry: Inappropriate ioctl for device 2020-11-28 21:37:41 gpg-agent[3535] failed to unprotect the secret key: Inappropriate ioctl for device 2020-11-28 21:37:41 gpg-agent[3535] failed to read the secret key 2020-11-28 21:37:41 gpg-agent[3535] command 'PKDECRYPT' failed: Inappropriate ioctl for device 2020-11-28 21:37:41 gpg-agent[3535] DBG: chan_10 -> ERR 83918950 Inappropriate ioctl for device 2020-11-28 21:37:41 gpg-agent[3535] DBG: chan_10 <- [eof] I did the following to resolve the issue: - Installed pinentry-gnome3 because that for one of two systems dis resolve the issue for me without anything else below. I also installed pinentry-gnome3 because it grabs the keyboard, deinstalled any other pinentry (like gtk2 which does not grab the keyboard, if you have focus follows mouse on fvwm2) apt install -y pinentry-gnome3 dbus-x11 - Added the following to my .xsession. This is necessary because in bullseye gpg-agent seems to be started by systemd sometimes without the correct display set gpg-connect-agent UPDATESTARTUPTTY /bye - gpg.conf (just to have a fully working example): keyserver hkp://pool.sks-keyservers.net keyserver-options no-honor-keyserver-url cert-digest-algo SHA512 no-greeting lock-once default-key encrypt-to keyid-format 0xlong use-agent with-fingerprint quiet default-recipient-self no-secmem-warning keyserver-options auto-key-retrieve no-auto-check-trustdb trust-model direct no-autostart default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed - gpg-agent.conf (I tried here a lot in the old days I had keep-display and keep-tty and restarted gpg-agent in my .xsession. that does not work anylonger becuase systemd seems to start gpg-agent. What also worked was calling pinentry using a wrapper script which sets the DISPLAY variable explicitly, but this gives me more flexibility, not that I need it. Because I always enter my passphrase using X11 on system I'm sitting in front of) enable-ssh-support default-cache-ttl 34560000 max-cache-ttl 34560000 default-cache-ttl-ssh 34560000 max-cache-ttl-ssh 34560000 allow-mark-trusted With the above setup the following works: - gpg locally gpg -d test.gpg - gpg as ssh-agent ssh remotesystem - gpg remotely ssh -A -R /home/sithglan/.gnupg/S.gpg-agent:/run/user/1000/gnupg/S.gpg-agent.extra remotesystem gpg -d test.gpg - sshfs using gpg as ssh-agent: # automounter sshfs apt-get install sshfs autofs echo '/ssh /etc/auto.sshfs --timeout=60' >> /etc/auto.master cat > /etc/auto.sshfs <<'EOF' #!/bin/bash echo -e "-fstype=fuse,rw,nodev,noatime,allow_other,ssh_command=/usr/local/sbin/ssh_sshfs / sshfs\#${1}:/" EOF cat > /usr/local/sbin/ssh_sshfs <<'EOF' #!/bin/bash if [ "${UID}" == 0 ]; then exec /usr/bin/sudo -H -u sithglan $0 "$@" fi export LOCALDOMAIN="glanzmann.de gmvl.de cs.fau.de" source ~sithglan/.ssh/env exec /usr/bin/ssh "$@" EOF chmod +x /etc/auto.sshfs /usr/local/sbin/ssh_sshfs /etc/init.d/autofs restart Tripwires: - nsswitch.conf: automount: files - 'echo export SSH_AUTH_SOCK=${SSH_AUTH_SOCK} > ~/.ssh/env' Feedback, improvement and explanations welcome. Cheers, Thomas From thomas at glanzmann.de Sun Nov 29 08:32:30 2020 From: thomas at glanzmann.de (Thomas Glanzmann) Date: Sun, 29 Nov 2020 08:32:30 +0100 Subject: gpg prompts me thrice for my passphrase - how to resolve it Message-ID: <20201129073230.GA9809@glanzmann.de> Hello, I sometimes use a yubikey, there gpg-agent only asks me once for my pin, however if I have my key on the disk, gpg-agent asks me three times: - once for local gpg -d test.gpg - once for gpg-agent functioning as ssh-agent - once for remote gpg -d test.gpg Now I wonder, if I can tell gpg-agent to prompt me only once or prepopulate all three secrets at once during startup? Cheers, Thomas From wk at gnupg.org Sun Nov 29 12:49:06 2020 From: wk at gnupg.org (Werner Koch) Date: Sun, 29 Nov 2020 12:49:06 +0100 Subject: Changing compression configuration In-Reply-To: (Karmanyaah Malhotra via Gnupg-users's message of "Sat, 28 Nov 2020 01:00:01 -0500") References: Message-ID: <87pn3wfknh.fsf@wheatstone.g10code.de> On Sat, 28 Nov 2020 01:00, Karmanyaah Malhotra said: > instead of just regular bzip2 when compressing files. I'm not sure if bzip2 is part of the OpenPGP specs and it is very unlikely that we will ever add another compression algo. In fact adding bzip2 was already a bad idea. > compression could be multi-threaded since using one thread is the Adding this to GnuPG would be too hard. You better use an external program for compressing the data cat foo | bzip2 | gpg -z0 -e >foo.bz2.gpg gpg -d foo this has more flexibility and the OS (and bzip2 er al) take care of multi-threading. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Sun Nov 29 12:53:53 2020 From: wk at gnupg.org (Werner Koch) Date: Sun, 29 Nov 2020 12:53:53 +0100 Subject: Verifying and checksumming new release is somewhat cumbersom In-Reply-To: <469842e0-86fa-cd41-f80f-be7efec7d754@mail.com> (john doe via Gnupg-users's message of "Sat, 28 Nov 2020 07:57:05 +0100") References: <5fe4d4c3-8ab2-6555-792d-00b59997b9b8@mail.com> <87ft4vhoad.fsf@wheatstone.g10code.de> <469842e0-86fa-cd41-f80f-be7efec7d754@mail.com> Message-ID: <87lfekfkfi.fsf@wheatstone.g10code.de> On Sat, 28 Nov 2020 07:57, john doe said: > If I look at Debian (1) for example, the checksum file is gpg signed. > Assuming that I understand correctly, the Debian approach is not a safe > way to make the checksums available?propagate? No, that is a safe way. Having a separate file with checksums is sometimes better for the signing workflow. It also allows to sign/verify a bunch of files with just one operation. It also avoids the need to download and upload all files to a dedicated signing box. Only since GnuPG 2.2 the latter could be handled using gpg-agent's remote feature. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From rjh at sixdemonbag.org Mon Nov 30 10:16:56 2020 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 30 Nov 2020 04:16:56 -0500 Subject: Odd error Message-ID: <31679534-a4ff-5222-f02c-b5de32e53de1@sixdemonbag.org> This should not be happening, but is. From a completely clean installation, importation of legitimate OpenPGP keys results in strange general failures. The system is an x64 Fedora 33 box running GnuPG 2.2.24 on libgcrypt 1.8.6. I'm happy to provide the keys.asc file to any GnuPG dev who needs it to look into this problem. ===== [rjh at localhost ~]$ gpgconf --kill gpg-agent [rjh at localhost ~]$ rm -rf .gnupg [rjh at localhost ~]$ gpg --import Downloads/keys.asc gpg: directory '/home/rjh/.gnupg' created gpg: keybox '/home/rjh/.gnupg/pubring.kbx' created gpg: /home/rjh/.gnupg/trustdb.gpg: trustdb created [snip] gpg: key 1DCBDC01B44427C7: public key "Robert J. Hansen " imported gpg: kbx: error computing keygrip gpg: error writing keyring '/home/rjh/.gnupg/pubring.kbx': General error gpg: error reading 'Downloads/keys.asc': General error gpg: no valid OpenPGP data found. gpg: import from 'Downloads/keys.asc' failed: General error gpg: Total number processed: 5 gpg: imported: 5 gpg: no ultimately trusted keys found ===== Let's try again on a higher verbosity level. (I have to say I saw nothing of use here.) ===== [rjh at localhost ~]$ gpgconf --kill gpg-agent [rjh at localhost ~]$ rm -rf .gnupg [rjh at localhost ~]$ gpg -vvv --import Downloads/keys.asc gpg: using character set 'utf-8' gpg: directory '/home/rjh/.gnupg' created gpg: keybox '/home/rjh/.gnupg/pubring.kbx' created gpg: armor: BEGIN PGP PUBLIC KEY BLOCK # off=0 ctb=99 tag=6 hlen=3 plen=269 [snipping successfully imported public keys] [leaving in debugging lines from other GnuPG components] [some data anonymized, because it's not mine] gpg: pub rsa2048/XXXXXXXXXXXXXXXX 2010-10-18 XXXXXXXX gpg: writing to '/home/rjh/.gnupg/pubring.kbx' gpg: /home/rjh/.gnupg/trustdb.gpg: trustdb created gpg: using pgp trust model gpg: key XXXXXXXXXXXXXXXX: public key "XXXXXXXX" imported gpg: no running gpg-agent - starting '/usr/bin/gpg-agent' gpg: waiting for the agent to come up ... (5s) gpg: connection to agent established gpg: pub rsa2048/XXXXXXXXXXXXXXXX 2012-05-24 XXXXXXXX gpg: writing to '/home/rjh/.gnupg/pubring.kbx' gpg: key XXXXXXXXXXXXXXXX: public key "XXXXXXXX" imported gpg: pub rsa4096/XXXXXXXXXXXXXXXX 2013-09-13 XXXXXXXX gpg: writing to '/home/rjh/.gnupg/pubring.kbx' gpg: key XXXXXXXXXXXXXXXX: public key "XXXXXXXX" imported gpg: pub rsa4096/XXXXXXXXXXXXXXXX 2016-10-04 XXXXXXXX gpg: writing to '/home/rjh/.gnupg/pubring.kbx' # off=10553 ctb=99 tag=6 hlen=3 plen=397 :public key packet: version 4, algo 1, created 1437075659, expires 0 pkey[0]: [3072 bits] pkey[1]: [17 bits] keyid: 1DCBDC01B44427C7 gpg: key XXXXXXXXXXXXXXXX: public key "XXXXXXXX" imported # off=10953 ctb=b4 tag=13 hlen=2 plen=35 :user ID packet: "Robert J. Hansen " # off=10990 ctb=89 tag=2 hlen=3 plen=446 :signature packet: algo 1, keyid 1DCBDC01B44427C7 version 4, created 1437078058, md5len 0, sigclass 0x13 digest algo 8, begin of digest cf aa hashed subpkt 2 len 4 (sig created 2015-07-16) hashed subpkt 27 len 1 (key flags: 03) hashed subpkt 11 len 11 (pref-sym-algos: 10 13 9 12 8 11 7 4 3 1 2) hashed subpkt 21 len 5 (pref-hash-algos: 10 9 8 11 3) hashed subpkt 22 len 3 (pref-zip-algos: 3 1 2) hashed subpkt 30 len 1 (features: 01) hashed subpkt 23 len 1 (keyserver preferences: 80) subpkt 16 len 8 (issuer key ID 1DCBDC01B44427C7) data: [3070 bits] # off=11439 ctb=89 tag=2 hlen=3 plen=540 :signature packet: algo 1, keyid DB1187B9DD5F693B version 4, created 1437210170, md5len 0, sigclass 0x13 digest algo 10, begin of digest 8b 3c hashed subpkt 2 len 4 (sig created 2015-07-18) subpkt 16 len 8 (issuer key ID DB1187B9DD5F693B) data: [4095 bits] # off=11982 ctb=b4 tag=13 hlen=2 plen=38 :user ID packet: "Robert J. Hansen " # off=12022 ctb=89 tag=2 hlen=3 plen=449 :signature packet: algo 1, keyid 1DCBDC01B44427C7 version 4, created 1467479780, md5len 0, sigclass 0x13 digest algo 8, begin of digest 34 63 hashed subpkt 27 len 1 (key flags: 03) hashed subpkt 11 len 11 (pref-sym-algos: 10 13 9 12 8 11 7 4 3 1 2) hashed subpkt 21 len 5 (pref-hash-algos: 10 9 8 11 3) hashed subpkt 22 len 3 (pref-zip-algos: 3 1 2) hashed subpkt 30 len 1 (features: 01) hashed subpkt 23 len 1 (keyserver preferences: 80) hashed subpkt 2 len 4 (sig created 2016-07-02) hashed subpkt 25 len 1 (primary user ID) subpkt 16 len 8 (issuer key ID 1DCBDC01B44427C7) data: [3072 bits] # off=12474 ctb=89 tag=2 hlen=3 plen=540 :signature packet: algo 1, keyid DB1187B9DD5F693B version 4, created 1437210170, md5len 0, sigclass 0x13 digest algo 10, begin of digest a8 e5 hashed subpkt 2 len 4 (sig created 2015-07-18) subpkt 16 len 8 (issuer key ID DB1187B9DD5F693B) data: [4096 bits] # off=13017 ctb=b4 tag=13 hlen=2 plen=41 :user ID packet: "Robert J. Hansen " # off=13060 ctb=89 tag=2 hlen=3 plen=446 :signature packet: algo 1, keyid 1DCBDC01B44427C7 version 4, created 1467479729, md5len 0, sigclass 0x13 digest algo 8, begin of digest 81 4e hashed subpkt 2 len 4 (sig created 2016-07-02) hashed subpkt 27 len 1 (key flags: 03) hashed subpkt 11 len 11 (pref-sym-algos: 10 13 9 12 8 11 7 4 3 1 2) hashed subpkt 21 len 5 (pref-hash-algos: 10 9 8 11 3) hashed subpkt 22 len 3 (pref-zip-algos: 3 1 2) hashed subpkt 30 len 1 (features: 01) hashed subpkt 23 len 1 (keyserver preferences: 80) subpkt 16 len 8 (issuer key ID 1DCBDC01B44427C7) data: [3071 bits] # off=13509 ctb=b9 tag=14 hlen=3 plen=397 :public sub key packet: version 4, algo 1, created 1437075659, expires 0 pkey[0]: [3072 bits] pkey[1]: [17 bits] keyid: DC0F82625FA6AADE # off=13909 ctb=89 tag=2 hlen=3 plen=415 :signature packet: algo 1, keyid 1DCBDC01B44427C7 version 4, created 1437075659, md5len 0, sigclass 0x18 digest algo 8, begin of digest 60 5b hashed subpkt 2 len 4 (sig created 2015-07-16) hashed subpkt 27 len 1 (key flags: 0C) subpkt 16 len 8 (issuer key ID 1DCBDC01B44427C7) data: [3067 bits] # off=14327 ctb=b8 tag=14 hlen=2 plen=51 :public sub key packet: version 4, algo 22, created 1491360583, expires 0 pkey[0]: [80 bits] ed25519 (1.3.6.1.4.1.11591.15.1) pkey[1]: [263 bits] keyid: A83CAE94D3DC3873 # off=14380 ctb=89 tag=2 hlen=3 plen=511 :signature packet: algo 1, keyid 1DCBDC01B44427C7 version 4, created 1491360583, md5len 0, sigclass 0x18 digest algo 2, begin of digest 69 5a hashed subpkt 2 len 4 (sig created 2017-04-05) hashed subpkt 27 len 1 (key flags: 02) subpkt 16 len 8 (issuer key ID 1DCBDC01B44427C7) subpkt 32 len 94 (signature: v4, class 0x19, algo 22, digest algo 8) data: [3072 bits] # off=14894 ctb=b8 tag=14 hlen=2 plen=56 :public sub key packet: version 4, algo 18, created 1491360897, expires 0 pkey[0]: [88 bits] cv25519 (1.3.6.1.4.1.3029.1.5.1) pkey[1]: [263 bits] pkey[2]: [32 bits] keyid: AA24CC81B8AED08B # off=14952 ctb=89 tag=2 hlen=3 plen=415 :signature packet: algo 1, keyid 1DCBDC01B44427C7 version 4, created 1491360897, md5len 0, sigclass 0x18 digest algo 2, begin of digest a1 8d hashed subpkt 2 len 4 (sig created 2017-04-05) hashed subpkt 27 len 1 (key flags: 0C) subpkt 16 len 8 (issuer key ID 1DCBDC01B44427C7) data: [3071 bits] # off=15370 ctb=99 tag=6 hlen=3 plen=525 [resuming omission of other people's keys] gpg: pub rsa3072/1DCBDC01B44427C7 2015-07-16 Robert J. Hansen gpg: key 1DCBDC01B44427C7: 2 signatures not checked due to missing keys gpg: writing to '/home/rjh/.gnupg/pubring.kbx' gpg: key 1DCBDC01B44427C7: public key "Robert J. Hansen " imported gpg: pub rsa4096/XXXXXXXXXXXXXXXX 2017-03-18 XXXXXXXX gpg: writing to '/home/rjh/.gnupg/pubring.kbx' gpg: kbx: error computing keygrip gpg: error writing keyring '/home/rjh/.gnupg/pubring.kbx': General error gpg: error reading 'Downloads/keys.asc': General error gpg: no valid OpenPGP data found. gpg: import from 'Downloads/keys.asc' failed: General error gpg: Total number processed: 5 gpg: imported: 5 gpg: 0 keys processed (0 validity counts cleared) gpg: no ultimately trusted keys found From wk at gnupg.org Mon Nov 30 15:16:20 2020 From: wk at gnupg.org (Werner Koch) Date: Mon, 30 Nov 2020 15:16:20 +0100 Subject: Odd error In-Reply-To: <31679534-a4ff-5222-f02c-b5de32e53de1@sixdemonbag.org> (Robert J. Hansen via Gnupg-users's message of "Mon, 30 Nov 2020 04:16:56 -0500") References: <31679534-a4ff-5222-f02c-b5de32e53de1@sixdemonbag.org> Message-ID: <87pn3vdj63.fsf@wheatstone.g10code.de> Hi! On Mon, 30 Nov 2020 04:16, Robert J. Hansen said: > gpg: kbx: error computing keygrip > gpg: error writing keyring '/home/rjh/.gnupg/pubring.kbx': General error The first one is the real error. We can't compute the keygrip for the public key. If you can build gpg yourself please apply this patch: --8<---------------cut here---------------start------------->8--- diff --git a/kbx/keybox-openpgp.c b/kbx/keybox-openpgp.c index 6d6ed77dc..345af0164 100644 --- a/kbx/keybox-openpgp.c +++ b/kbx/keybox-openpgp.c @@ -240,6 +240,7 @@ keygrip_from_keyparm (int algo, struct keyparm_s *kp, unsigned char *grip) if (!err && !gcry_pk_get_keygrip (s_pkey, grip)) { + gcry_log_debugsxp ("pubkey:", s_pkey); log_info ("kbx: error computing keygrip\n"); err = gpg_error (GPG_ERR_GENERAL); } --8<---------------cut here---------------end--------------->8--- or send me your sample key. In any case please also run our new 2.2.24 command to see how libgcrypt has been built: gpgconf --show-versions Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From rjh at sixdemonbag.org Mon Nov 30 15:25:26 2020 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 30 Nov 2020 09:25:26 -0500 Subject: Odd error In-Reply-To: <87pn3vdj63.fsf@wheatstone.g10code.de> References: <31679534-a4ff-5222-f02c-b5de32e53de1@sixdemonbag.org> <87pn3vdj63.fsf@wheatstone.g10code.de> Message-ID: > The first one is the real error. We can't compute the keygrip for the > public key. If you can build gpg yourself please apply this patch: It's a standard Fedora GnuPG, so although I'm sure a source RPM is available I'm not enough of an RPM surgeon to know how to modify the .rpmspec to apply the patch. I'll send the keyring onto you privately. > or send me your sample key. In any case please also run our new 2.2.24 > command to see how libgcrypt has been built: > > gpgconf --show-versions * GnuPG 2.2.25 (40f75823d) GNU/Linux * Libgcrypt 1.8.7 () version:1.8.7:10807:1.37-unknown:12500: cc:100201:gcc:10.2.1 20201016 (Red Hat 10.2.1-6): ciphers:arcfour:blowfish:cast5:des:aes:twofish:serpent:rfc2268:seed:camellia:idea:salsa20:gost28147:chacha20: pubkeys:dsa:elgamal:rsa:ecc: digests:crc:gostr3411-94::md4:md5:rmd160:sha1:sha256:sha512:sha3:tiger:whirlpool:stribog:blake2: rnd-mod:linux: cpu-arch:x86: mpi-asm:amd64/mpih-add1.S:amd64/mpih-sub1.S:amd64/mpih-mul1.S:amd64/mpih-mul2.S:amd64/mpih-mul3.S:amd64/mpih-lshift.S:amd64/mpih-rshift.S: hwflist:intel-cpu:intel-bmi2:intel-ssse3:intel-sse4.1:intel-pclmul:intel-aesni:intel-rdrand:intel-avx:intel-avx2:intel-fast-vpgather:intel-rdtsc: fips-mode:n:n: rng-type:standard:1:2010000:1: * GpgRT 1.37-unknown (0000000) * Libassuan 2.5.3 (4de3154) * KSBA 1.3.5 (?) * GNUTLS 3.6.15 From ryan at digicana.com Mon Nov 30 15:36:16 2020 From: ryan at digicana.com (Ryan McGinnis) Date: Mon, 30 Nov 2020 14:36:16 +0000 Subject: Mobile mini computers for GnuPG/OpenPGP usage instead of smartphone usage In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 839 bytes Desc: OpenPGP digital signature URL: From m.fernandes.business at gmail.com Mon Nov 30 19:00:00 2020 From: m.fernandes.business at gmail.com (Mark Fernandes) Date: Mon, 30 Nov 2020 18:00:00 +0000 Subject: Five volunteers needed (EU only please) In-Reply-To: References: Message-ID: > ------------------------------ > > Message: 2 > Date: Thu, 26 Nov 2020 12:10:59 +0100 > From: Dirk Gottschalk > To: gnupg-users at gnupg.org > Subject: Re: Five volunteers needed (EU only please) > Message-ID: > <39d845f714609d1ce09286e991ab1056e9dfae2a.camel at googlemail.com> > Content-Type: text/plain; charset="utf-8" > > ... > > Am Montag, den 05.10.2020, 17:37 +0200 schrieb Stefan Claas: > > ... > > > > My new idea is to send encrypted postcards or letters, with an NFC > > tag attached, > > containing a GnuPG clearsigned test message. ... > > [...] > > ... > The Tags should have enough memory to take encrypted messages. I think > at least 12k. The more memory, the longer can the message be. > > .... It might be better only to use tags that have relatively small amounts of memory, in order to be more secure: if your computer has been hacked, it may try to do arbitrary code execution of data on the NFC, where someone may have deceptively planted malware. Kind regards, Mark Fernandes -------------- next part -------------- An HTML attachment was scrubbed... URL: From spam.trap.mailing.lists at gmail.com Mon Nov 30 19:59:18 2020 From: spam.trap.mailing.lists at gmail.com (Stefan Claas) Date: Mon, 30 Nov 2020 19:59:18 +0100 Subject: Mobile mini computers for GnuPG/OpenPGP usage instead of smartphone usage In-Reply-To: References: Message-ID: On Mon, Nov 30, 2020 at 3:36 PM Ryan McGinnis wrote: > > Hah, these look like they?re probably aimed at the pentesting market, they are indeed tiny as hell! [...] What I like to try out is to see how it works as offline device, i.e. attaching the MicroPC to my dumb phone via USB (to send GnuPG encrypted MMS) or to my PC via the serial port and then CoolTerm usage on both. Regards Stefan From wk at gnupg.org Mon Nov 30 21:34:17 2020 From: wk at gnupg.org (Werner Koch) Date: Mon, 30 Nov 2020 21:34:17 +0100 Subject: Odd error In-Reply-To: (Robert J. Hansen via Gnupg-users's message of "Mon, 30 Nov 2020 09:25:26 -0500") References: <31679534-a4ff-5222-f02c-b5de32e53de1@sixdemonbag.org> <87pn3vdj63.fsf@wheatstone.g10code.de> Message-ID: <87ft4qeg8m.fsf@wheatstone.g10code.de> On Mon, 30 Nov 2020 09:25, Robert J. Hansen said: > I'll send the keyring onto you privately. Thanks. Unfortunately i was not able to replicate the bug on my Devuan box. I tried using the same Libgcrypt version but with some libraries different. Should not matter, though. > * Libgcrypt 1.8.7 () This is a somehow patched version, it should read * Libgcrypt 1.8.7 (04c156a4) which gives the commit id of the release. As you know, patching a version is quite common and not a problem. However, given the error message, this is the first place where I need to look. I don't have any Fedora running here but it is a good opportunity to install a VM for testing. But not this evening anymore. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Mon Nov 30 22:20:58 2020 From: wk at gnupg.org (Werner Koch) Date: Mon, 30 Nov 2020 22:20:58 +0100 Subject: Odd error In-Reply-To: <87ft4qeg8m.fsf@wheatstone.g10code.de> (Werner Koch via Gnupg-users's message of "Mon, 30 Nov 2020 21:34:17 +0100") References: <31679534-a4ff-5222-f02c-b5de32e53de1@sixdemonbag.org> <87pn3vdj63.fsf@wheatstone.g10code.de> <87ft4qeg8m.fsf@wheatstone.g10code.de> Message-ID: <878saiee2t.fsf@wheatstone.g10code.de> Hi! I looked at the Fedora Libgcrypt source and noticed that they ship libgcrypt with the nistp192 and all brainpool curves removed. I have not yet build this version but given that one of your keys has brainpool curves this might be the culprit. I can understand that they remove nistp192 for security policy reasons. But I do not understand why the brainpool curves are removed. The general statement in the spec file is that curves need to be removed due to patent rasons. However, Brainpool curves are less prone to patent claims for fast multiplication than the NIST curves and we actually use the very same code for all those Weierstrass curves. I'll build with the Fedora patches in the next days. If the missing curves are really the reason, we can fix that. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: