Re: FAQ October 2019 update
Hi, On Tue, Oct 15, 2019 at 03:17:58PM -0400, Robert J. Hansen wrote: ... Those were the high-priority changes that needed to be made. If anyone has other suggestions, speak up: I'm listening. :) A while ago (I can’t find the e-mail anymore) I suggested a few changes that somehow didn’t find their way to the FAQ and then I forgot about them. Allow me to submit them again. Those changes are all related to the fact that modern (≥ 2.1) GnuPG automatically creates a revocation certificate whenever it creates a new key pair, and stores it in $GNUPGHOME/openpgp-revocs.d. In section 7,17 (What’s a ‘revocation certificate’?), it’s no longer recommended to create a revocation certificate immediately after generating a new GnuPG certificate. Instead, this section may state that GnuPG already creates one when creating a GnuPG certificate, and that it can be found in $GNUPGHOME/openpgp-revocs.d. Similarly, section 8.5 (“What should I do after making my certificate”) should no longer say to generate a revocation certificate, but again may indicate where to find the one automatically generated by GnuPG, and advise to store it in a safe place. In the same section, the subsection “How do I generate a revocation certificate” could be moved elsewhere, as it is no longer something you “should do after making [your] certificate”. In section 10 (“What are some common bast practices?”), the advice “Generate a revocation certificate and keep it safe” should be removed and optionally replaced by “Keep your (automatically generated) revocation certificate safe”. Cheers, - Damien signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: FAQ October 2019 update
On 15/10/2019 21:59, Robert J. Hansen wrote: > Should they update? Yes. Is the problem mitigated by an update? Yes. > But will they? Probably not before wedging their keyring. Given that > high-profile people in the community have had our certificates defaced, > it's possible someone will say "I want to ask dkg a question," pull down > his cert, get wedged, and... etc. I can confirm that this happens and users are being b0rked because of trolls. Street level rumour is that GnuPG key exchange is broken and you should not use it. It doesn't matter what the truth is - it is the public perception that recent SKS events made it unusable, this was advertised across the media all over the place and the image stuck. Additionally, poor handling of SKS fiasco by GnuPG community hurt it's credibility a lot, so a clear signal that this issue was treated seriously would be beneficial. Should it be advertised as a new go-to standard or as transitional standard, beta/alpha/whatever - I don't know, it's debatable. Cheers, Chris ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: A place for discussing WKD spec clarifications?
On Tue, 15 Oct 2019 09:06, Bjarni Runar Einarsson said: > Would the GnuPG issue tracker be a good place to file "bug > reports" against the spec, to work towards clarifications? That is okay for bug reports, but often it is more important to get the opinions from more people than those who triage the bug reports. I thing gnupg-devel@ gnupg.org would be an appropriate place for discussing such topics. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GPG Agent discarding cache before ttl/max ttl
On Tue, 15 Oct 2019 09:14, Chip Senkbeil said: > Is there some separate setting for GPG agent to discard its cache > earlier than the ttl/max ttl settings? I've checked the GPG agent You can follow the cache operations by adding log-file /some/log/file debug cache to gpg-agent.conf and reload it (gpgconf --reload gpg-agent). This will give you some insights on what is going on. The stadard way to flush the cache is bei sending a HUP to gpg-agent (or the above reload command). If your system has a method to run a script on suspend or lid closing it may already do just that. I consider this a good idea but we can't do that by default in GnuPG because systems differ to much on how to detect a lid closing event or similar. Thus there is also no way to avoid it using a GnuPG option. > enable-ssh-support Its the default anyway > fixed-list-mode You can remove that too it has no effect anymore. > # When making an OpenPGP certification, use a stronger digest than > the default > # SHA1: > cert-digest-algo SHA256 It is the default for a long time now. Only gpg 1.4 still defaults to SHA-1 but you are not using that. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: FAQ October 2019 update
Let's start with the most important thing: > I am sorry for having to write these harsh comments I didn't find your comments harsh, but thank you for being considerate. :) >> * Every reference to the SKS keyserver network now points to >> keys.openpgp.org. Reason: the SKS attacks a few months ago. > > I have to object against this change. The SKS server network is still > useful and definitely more useful than an non-matured and centralized > keyserver. I can't agree with this. SKS is effectively dead. Older GnuPG installations can still get utterly wedged if they pull down a poisoned certificate from SKS. There are a *lot* of these older installations out there in the wild, and what we suggest to them should not lead them into wedging their system. Should they update? Yes. Is the problem mitigated by an update? Yes. But will they? Probably not before wedging their keyring. Given that high-profile people in the community have had our certificates defaced, it's possible someone will say "I want to ask dkg a question," pull down his cert, get wedged, and... etc. I think it's dangerous to our users to continue to recommend SKS in the face of a well-known poisoning problem. > suggesting the use of that specific keyserver is a no-go. I'm fine with this. My major concern is removing SKS recommendations. >> * All references to 2048-bit crypto are updated to refer to 3072-bit >> crypto. Reason: GnuPG now defaults to 3072-bit RSA. > > Okay. But this > > +your certificate uses 2048-bit keys we recommend retiring them and > +migrating to a new keypair of at least 3072 bits length. You can do > > is a no-go because we will have a hard to time to convice people that > this is just a geek suggestion and that for almost all general use of > gpg the existsing keys are still fine. Actually 2k keys are still > allowed in Germany for restricted communication and there is no need for > an immediate rush to 3k. I agree there is no immediate rush: the US guidance says they're safe until 2030. But for many years we advised people to use 2048-bit keys, now we're generating 3072-bit keys by default. At the very least the old guidance on 2048-bit keys needs to be dropped. Whether we explain it away as "we're now using 3072-bit keys by default, in order to get a long head start on 2048's obsolescence" or "we're going to be moving to ECC in the near future" matters little to me, but we need to explain the shift away from 2048. > I also wonder why you removed this > > -If you need more security than RSA-2048 offers, the way to go would be > -to switch to elliptical curve cryptography — not to continue using > -RSA. Because it raises an immediate question of, "then why does GnuPG default to RSA-3072, if the FAQ's guidance is past -2048 to use ECC?" The FAQ's statement collides with what GnuPG actually does. > That is a matter of minutes. I only had a brief look at it but I can't > see that your changes are subject to frequently asked questions here. There were three major changes: keyservers, key lengths, and an email address. All three existed in prior iterations of the FAQ. If you think they should be dropped, I'm all for that conversation, but please keep in mind that I'm not adding new subjects to the FAQ: in this pass I was updating existing content. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: FAQ October 2019 update
On Tue, 15 Oct 2019 15:17, Robert J. Hansen said: > * Every reference to the SKS keyserver network now points to > keys.openpgp.org. Reason: the SKS attacks a few months ago. I have to object against this change. The SKS server network is still useful and definitely more useful than an non-matured and centralized keyserver. I am okay with removing explicit reference to the SKS network for now but suggesting the use of that specific keyserver is a no-go. > * All references to 2048-bit crypto are updated to refer to 3072-bit > crypto. Reason: GnuPG now defaults to 3072-bit RSA. Okay. But this +your certificate uses 2048-bit keys we recommend retiring them and +migrating to a new keypair of at least 3072 bits length. You can do is a no-go because we will have a hard to time to convice people that this is just a geek suggestion and that for almost all general use of gpg the existsing keys are still fine. Actually 2k keys are still allowed in Germany for restricted communication and there is no need for an immediate rush to 3k. I also wonder why you removed this -If you need more security than RSA-2048 offers, the way to go would be -to switch to elliptical curve cryptography — not to continue using -RSA. GnuPG's future default is already ECC and some hosted mail services are already creating such keys. GnuPG will switch to that with 2.3 which is not that far away. > (Note: I just committed the FAQ changes. It may take a couple of days > for the documentation on the website to be regenerated.) That is a matter of minutes. I only had a brief look at it but I can't see that your changes are subject to frequently asked questions here. The GnuPG FAQ is for all GnuPG users and should not again start reflect the view of some crypto geeks or give advises which will lead only to trouble. I am sorry for having to write these harsh comments: In contrast to discussions on the mailing list the FAQ reflects the opinion of the GnuPG project and as such substantial changes need to be discussed first. I would suggest to create a branch and revert the changes in master until an agreement has been reached. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
FAQ October 2019 update
The last time I gave the FAQ a thorough read-and-review was in October 2017, so it was time for a review. I fought off the urge to rewrite the thing entirely -- I really don't like how it flows, but I view my job as maintainer is more about making minor incremental changes than total rewrites whenever the whim seizes me. Anyway, the major changes: * Every reference to the SKS keyserver network now points to keys.openpgp.org. Reason: the SKS attacks a few months ago. * All references to 2048-bit crypto are updated to refer to 3072-bit crypto. Reason: GnuPG now defaults to 3072-bit RSA. * PGPNET's email address has changed. ... Those were the high-priority changes that needed to be made. If anyone has other suggestions, speak up: I'm listening. :) (Note: I just committed the FAQ changes. It may take a couple of days for the documentation on the website to be regenerated.) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
> I'm confused. I thought the whole efail thing was about crafting a > plain text message that says "Good signature verified" and fools the > user even though it was never run through pgp or had its signature > verified with s/mime. I'd suggest reading the Efail paper. The vast majority of the news coverage was shoddy. Efail included two *completely separate* attacks in their paper, which the news media overwhelmingly conflated into a single attack. I'll call them Efail-1 and Efail-2 here. Efail-1 was what Werner is talking about here. It was a pretty bad blow to S/MIME, but far less so to OpenPGP, since OpenPGP has had countermeasures in place for almost twenty years. Efail-1's impact on OpenPGP was, is, minimal. Efail-2 wasn't an attack on OpenPGP at all, but instead showed how poorly email clients and/or email plugins communicated with GnuPG. It was possible for GnuPG to give a correct warning that someone was playing games with the message, and for the email client to disregard this warning and present it to the user as authentic. Efail-1 had minimal applicability to GnuPG; Efail-2 had none whatsoever (except, arguably, some of the messages GnuPG gave were ambiguous: I think they were, but Werner disagrees). ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
Werner Koch writes: > authenticated encryption is different from signed and encrypted mails. > There are relative easy attacks on the encryption layer if standard > encryption modes like CBC (as in S/MIME) are used. Whether this really > affects users is a different question but they can be used to leverage > implementation flaws in MUAs to full plaintext leaks. This is known for > 20 years and made it last year again to the media under the term EFAIL. I'm confused. I thought the whole efail thing was about crafting a plain text message that says "Good signature verified" and fools the user even though it was never run through pgp or had its signature verified with s/mime. > Granted, encrypted+signed mails can to a large extend also mitigate the > threat. But there are still reasons why signatures can't be used or > need to be verified only at a latter time in the workflow. > > OpenPGP had a mitigation against this since 2000 and was widely deployed > by 2003. However S/MIME never implemented this despite of 10 years old > RFCs describing methods for such a mitigation, called authenticated > encryption (AE or AEAD). AFAICS, that is for encryption+sign. If you just want to sign, it sounds like you are saying that is broken. I don't see how. You can't modify the message and keep the hash unchanged, and you can't encrypt a new hash because you don't have the sender's private key. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
GPG Agent discarding cache before ttl/max ttl
Hey folks! Been using GPG for a couple of months to encrypt, sign, and authenticate and it's been great! I'm trying to understand the scenarios in which the GPG agent will remove an entry from its cache. I've got my default and max cache (both cache-ttl and cache-ttl-ssh) set to one day such that I don't need to enter my password upon accessing my mail on a timer, etc. This works great until my laptop goes to sleep, I close the lid, etc. At that point, it appears to me that the agent tosses out the cache regardless of the length of time. This was not the case when I had GPG configured on a Mac, but when I switched to Fedora 30, I began having this problem. It's a little frustrating because I frequently enter and exit a dock for work, closing and re-opening my laptop, as I dart between meetings, resulting in me needing to re-enter passwords through pinentry more frequently than I'd desire. Is there some separate setting for GPG agent to discard its cache earlier than the ttl/max ttl settings? I've checked the GPG agent process and its still the same instance that had been running since I booted the laptop, so I don't believe it's the case where the agent is getting killed and restarted. For reference, here's my gpg-agent.conf file: pinentry-program /usr/local/bin/my-pinentry-gui default-cache-ttl 604800 max-cache-ttl 604800 default-cache-ttl-ssh 604800 max-cache-ttl-ssh 604800 enable-ssh-support I've got a custom bash script for the pinentry program that selects an appropriate pinentry process based on OS and capabilities (GUI/terminal). And my gpg.conf file: # NOTE: Apparently does nothing with gpg2 use-agent # When outputting certificates, view user IDs distinctly from keys: # NOTE: Since 2.0.10, seems to be obsolete as always used, but no harm in # keeping it here fixed-list-mode # Long keyids are more collision-resistant than short keyids (it's trivial to # make a key with any desired short keyid) keyid-format 0xlong # When multiple digests are supported by all recipients, choose the strongest # one: personal-digest-preferences SHA512 SHA384 SHA256 SHA224 # Preferences chosen for new keys should prioritize stronger algorithms: default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 BZIP2 ZLIB ZIP Uncompressed # You should always know at a glance which User IDs gpg thinks are legitimately # bound to the keys in your keyring: verify-options show-uid-validity list-options show-uid-validity # When making an OpenPGP certification, use a stronger digest than the default # SHA1: cert-digest-algo SHA256 # Prevent version string from appearing in your signatures/public keys no-emit-version # Never ask to insert smartcard if it wasn't already inserted to begin with # NOTE: Currently broken as the functionality appears to have been removed by # commit 8c219602515ae1dba5bc0da31077852dab61809e when g10/gluecard.c # was removed. From the latest commit, it seems like appropriate logic # could be added back in agent/divert-scd.c in the main loop of # ask_for_card function limit-card-insert-tries 1 expert ~ Chip Senkbeil signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
On 14.10.2019 22:45, Werner Koch wrote: > On Mon, 14 Oct 2019 20:43, Kristian Fiskerstrand said: > >> was suggested by Kristian and Andre: talking to SCDaemon (scd) with IPC. >> Details need to be discussed, but it would be an optional solution, that > > Given that TB already has smartcard support it would be easy if the new > code just makes use of that code. Of course the code then needs to > touch the NSS part of Mozilla and can't just go with RNP. That would be > a more integrated solution than any other hack. > > Right, separate software will be required but that is the usual case > with smartcards. For example Scute can be used to provide card services > via GnuPG (and also allow for on-disk GnuPG. Note that GnuPG 2.3 will > be much more flexible in regard to smartcard use and how it can interact > with TB via Scute. Scute might very well be a good alternative to reach out to, but I'm not too optimistic regarding the likelihood of getting anything related to OpenPGP directly into NSS, hence expecting anything that requires development needs to be done through other vectors. -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Corruptissima re publica plurimæ leges The greater the degeneration of the republic, the more of its laws signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
