Re: WKD: conveying intent of encrypt-by-default?
Phil Pennock via Gnupg-users wrote: [...] Problem: we use PGP for signing and for certain transactions which need high confidentiality, but for the most part, for most of our staff, setting up a PGP-capable mail client with our mail-provider is a pain and we're not interested. We want the PGP keys _available_ for people to have a trusted path to the key, but that does _not_ mean that we want people to default to using PGP for all communications with us. Simple option if most users at your site will be generating PGP signatures but not running PGP-capable MUAs: generate sign-only keys and put those in WKD. You would need a second mechanism for distributing the encryption-permitted keys for those users who need them, but the encryption keys could in turn be signed with the WKD sign-only keys to prevent a man-in-the-middle attack. -- Jacob ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD: conveying intent of encrypt-by-default?
On Mon, 3 Oct 2022, Phil Pennock via Gnupg-users wrote: Folks, I setup WKD for work a while back, to publish the PGP keys for those who had them. Then in November I removed the first key because it was causing Protonmail users to keep sending encrypted to the recipient and a lot of his communications turned out to be with Protonmail users. Now we've had this happening again, with someone else, and one very plausible outcome at this point is that we remove almost everyones' keys from WKD, leaving only those who sign security advisories, because WKD and the ecosystem right now is causing bigger problems than it solves. I think that there's a perfectly reasonable conflation of semantic intent. I'm not sure what the solution is, although I'm thinking that _perhaps_ the answer is to extend the allowed values in the "policy" file, to convey intent to a different audience than those uploading keys. Problem: we use PGP for signing and for certain transactions which need high confidentiality, but for the most part, for most of our staff, setting up a PGP-capable mail client with our mail-provider is a pain and we're not interested. We want the PGP keys _available_ for people to have a trusted path to the key, but that does _not_ mean that we want people to default to using PGP for all communications with us. While Protonmail is the triggering party here, I don't think that they're at fault: for their model, what they've set up is probably a reasonable implementation. So please, no rants about Protonmail. Am I right in thinking that WKD was not really intended to be a trigger for opportunistic upgrade to PGP-encryption for messaging? Does it seem reasonable to add a directive to WELLKNOWN/policy, so that any WKD client can see what a general domain policy is? I could see individual users having other preferences, and I guess there's no reason that an additional binary PGP packet, not signed by the key, couldn't be served up together with the key from the WKD server. But that's more extensive coding to handle and interpret. Tentatively, perhaps: email-encrypt-by-default: yes email-encrypt-by-default: no and then if not present, then the intent is unspecified. We would then add "email-encrypt-by-default: no" and then the WKD draft could clarify as an implementation consideration that "availability of the key does not imply routine use of the key is desired". -Phil Hi Phil, ignoring your proposal (it sounds valid to me), would it be an option to make the key a pure signing key? What's the use case to have an encryption key but not receive encrypted email by default? regards, Erich ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
WKD: conveying intent of encrypt-by-default?
Folks, I setup WKD for work a while back, to publish the PGP keys for those who had them. Then in November I removed the first key because it was causing Protonmail users to keep sending encrypted to the recipient and a lot of his communications turned out to be with Protonmail users. Now we've had this happening again, with someone else, and one very plausible outcome at this point is that we remove almost everyones' keys from WKD, leaving only those who sign security advisories, because WKD and the ecosystem right now is causing bigger problems than it solves. I think that there's a perfectly reasonable conflation of semantic intent. I'm not sure what the solution is, although I'm thinking that _perhaps_ the answer is to extend the allowed values in the "policy" file, to convey intent to a different audience than those uploading keys. Problem: we use PGP for signing and for certain transactions which need high confidentiality, but for the most part, for most of our staff, setting up a PGP-capable mail client with our mail-provider is a pain and we're not interested. We want the PGP keys _available_ for people to have a trusted path to the key, but that does _not_ mean that we want people to default to using PGP for all communications with us. While Protonmail is the triggering party here, I don't think that they're at fault: for their model, what they've set up is probably a reasonable implementation. So please, no rants about Protonmail. Am I right in thinking that WKD was not really intended to be a trigger for opportunistic upgrade to PGP-encryption for messaging? Does it seem reasonable to add a directive to WELLKNOWN/policy, so that any WKD client can see what a general domain policy is? I could see individual users having other preferences, and I guess there's no reason that an additional binary PGP packet, not signed by the key, couldn't be served up together with the key from the WKD server. But that's more extensive coding to handle and interpret. Tentatively, perhaps: email-encrypt-by-default: yes email-encrypt-by-default: no and then if not present, then the intent is unspecified. We would then add "email-encrypt-by-default: no" and then the WKD draft could clarify as an implementation consideration that "availability of the key does not imply routine use of the key is desired". -Phil signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Seeking Assurance on Security and Memory Leaks in SuSE GnuPG
TL > I was pleased to receive a rapid response from Werner Koch, who explained that the nominated count_value of 1024 actually used a default count_value compatible with gpg 1.4, and then went on to explain that OpenPGP used an SHA1-based Key Distribution Function (KDF). Jacob B > KDF here is "Key Derivation Function", not "Key Distribution Function". You are correct: not sure how this happened. My original submission reflected a "Notes" paper I had been writing (for my own clarification) which included an acronyn list with the correct expansion. I guess this confirms my status as a non-expert, which is why I "Seek Assurance"! Jacob B > If I understand correctly, it probably did: your data was encrypted using AES256 using a key derived from your passphrase using the OpenPGP KDF and an integrity check value using SHA256 was included with the encrypted data. That was certainly my intention, using: time gpg2 -c --s2k-cipher-algo AES256 --s2k-digest-algo SHA256 \ --s2k-count count_value cleartext_file where the man gpg states: --s2k-cipher-algo name Use name as the cipher algorithm for symmetric encryption with a passphrase --s2k-digest-algo name Use name as the digest algorithm used to mangle the passphrases for symmetric encryption. The default is SHA-1. --s2k-count n Specify how many times the passphrases mangling for symmetric encryption is repeated. This value may range between 1024 and 65011712 inclusive. Werner noted [for Count 1024] For backward compatibility reasons with 1.4 the default count value is used in this case [and] You can't compare some AES-KDF to the SHAl based KDF of OpenPGP. The --s2k options mention "mangling passphrases" which sounds exactly like a KDF, but a default SHA-1 was used in one case, at least. TL > My Aug 27 submission highlighted a Spectra Secure YouTube (dated 29 Nov 2021) which noted that the --s2k parameters were ignored for key export without warning, and that this "bug" had been the case since 2017. Jacob B > ... that would be a very serious bug ... The Spectra Secure YouTube was: https://www.youtube.com/watch?v=j-qBChKG15Y "Password Managers: The Case Against GNU pass (feat gpg)". Around minute 4:31 it explains very clearly that the --s2k settings do not work (when exporting a key), showing screen evidence. In a later comment, Spectra Secure quotes "additional context on reddit" from skeeto at: https://www.reddit.com/r/commandline/comments/r4ndi9/comment/hmjbkmc/ , which states: "The exported S2K protection is different than than the protection used on the keyring, so you can't infer anything about GnuPG keys at rest unless you're storing them in exported format rather than on your keyring. This changed in GnuPG 2.1, and that's why the S2K options are silently ignored as of GnuPG 2.1. I'm the person who filed the bug report discussed in the video, and the responses to that report are how I learned what's going on.". This implies the "silent ignoring" is correct for exported keys, but may not be relevant to other functions. We now seem to find it can be relevant to other activities as well. In fact, all I can really infer is that practice does not match the man gpg, so it is difficult to decide what is (or should be) going on. I am not really in a position to examine the sources with any confidence, but would welcome suggestions for software which would permit me to check what was set up. Does John the Ripper (gpg-opencl), plus hashcat, detail the algorithms used, having broken a password? Tony ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
