Re: A place for discussing WKD spec clarifications?
On Tue 2019-10-15 23:01:33 +0200, Werner Koch via Gnupg-users wrote: > 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. WKD is a useful spec, and an increasingly important part of the OpenPGP ecosystem. If we want general e-mail discussion about WKD concerns, i'd suggest using the open...@ietf.org mailing list, as it will reach implementers of more WKD clients than just gnupg-users. That said, e-mail discussion is not the same as a tracker that allows us to keep a list of currently-known issues and concerns. If https://dev.gnupg.org/ is not appropriate for that sort of issue tracking, perhaps we could set up an issue tracker on gitlab associated with the WKD spec? I'd be happy to set up such a tracker at (say) https://gitlab.com/openpgp-wg/web-key-directory/issues if folks are OK with it. Werner, does that sound OK to you? As usual for any IETF-related interoperability discussion, i'd expect any major issues to *also* go to the mailing list for visibility and robust archiving, but i think that having an actively-maintained, publicly-accessible issue tracker related to this important work would be concretely useful. --dkg 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 2019-10-15 22:57:16 +0200, Werner Koch via Gnupg-users wrote: > 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. It would be great to learn what the most common lid-closing events on popular platforms are, so that gpg-agent can do this cache-flushing behavior automagically at least for users on those platforms. On systems with D-Bus, following the freedesktop.org IPC standards, it looks like the following signal appears on the system bus when the machine goes to sleep: destination=(null destination) path=/org/freedesktop/login1; interface=org.freedesktop.login1.Manager; member=PrepareForSleep boolean true Debian systems these days typically use the dbus standard -- and i'd be happy to try to integrate detection of this signal into the debian gpg-agent packaging, if anyone wants to propose a way to do it. i'm not a D-Bus guru by any stretch of the imagination, so i'm not sure what the right next step is, guidance is definitely welcome. > On Tue, 15 Oct 2019 09:14, Chip Senkbeil said: >> enable-ssh-support > > Its the default anyway This is the default, but its presence in gpg-agent's configuration file is also used as a signal in some OSes (debian at least) as for whether to export an SSH_AUTH_SOCK that points to gpg-agent's ssh-agent emulation socket. See /etc/X11/Xsession.d/90gpg-agent for more details. Regards, --dkg signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Fwd: Cannot decrypt from smartcard using gnupg-2.2, can from 2.0
I just realized my reply did not go to the list. -- Forwarded message - From: alejandro Cortez Date: Tue, Oct 15, 2019 at 9:43 AM Subject: Re: Cannot decrypt from smartcard using gnupg-2.2, can from 2.0 To: Niibe Yutaka On Mon, Oct 14, 2019 at 12:18 AM Niibe Yutaka wrote: > $ gpg-connect-agent "KEYINFO --list" /bye > On 2.0, this only prints OK. On 2.2, only one KEYINFO line is printed and the 4th to final column looks like: D - - - P - - - I have two different smartcards (both nitrokey pro). One of them is for a different key and does not experience any problems (it is loaded with a master key instead of a subkey). The output of KEYINFO is two lines and the 4th - final column looks like this: T OPENPGP.3 - - - - - D - - - P - - - So neither a working nor broken smartcard shows output like yours. Are there any other methods to debug this perhaps? ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Android
Am 16.10.19 um 13:02 schrieb Daniel Bossert: > Is anybody using pgp on Android? I did some years ago, would like to, > but am afraid of security reason. > > I have safed my keys on my laptop only. > > How are you handling it in ages of mobiles? I use K-Mail and Openkeychain https://www.openkeychain.org/ If you want to store something safely you may use https://play.google.com/store/apps/details?id=com.sovworks.eds.android&hl=en I imported my key pair from a Linux PC. BurkS signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: are angle brackets around email address allowed for auto-key-locate?
On Wed, 2019-10-16 at 14:19 +0200, Werner Koch wrote: > On Tue, 15 Oct 2019 22:23, David Hebbeker said: > > The manual [1] says that GnuPG can automatically retrieve keys for > > emails in the "u...@example.com" form. Does this exclude emails > > wrapped by angle brackets like ""? > > That is fine. Hi Werner and everyone, thank you for your response, I was hoping that this would be possible. On the other hand, I have experienced a behavior I could only explain with auto-key-locate being restricted to the pure form. Maybe you can enlighten me on this case. I demonstrate this behavior on a system which uses the attached configuration file gpg.conf. I tested this with GnuPG 2.1.18 and 2.2.12. Preparation === rm msg.* echo "hello world" > msg.txt gpg --batch --yes --delete-keys edward...@fsf.org Bad Case (does not work) gpg --always-trust -e -r "" msg.txt gpg: : skipped: No public key gpg: msg.txt: encryption failed: No public key Good Case (works) = gpg --always-trust -e -r "edward...@fsf.org" msg.txt gpg: key 9FF2194CC09A61E8: 7454 signatures not checked due to missing keys gpg: key 9FF2194CC09A61E8: public key "Edward, the GPG Bot " imported gpg: no need for a trustdb check with 'always' trust model gpg: Total number processed: 1 gpg: imported: 1 gpg: automatically retrieved 'edward...@fsf.org' via keyserver Note: The only difference is the missing angle brackets. Can you please explain the difference? That would be of great help! Thanks Davidkeyserver hkp://keyserver.ubuntu.com:80 # Used for encryption auto-key-locate keyserver # Used for verifying signatures auto-key-retrieve signature.asc Description: This is a digitally signed message part ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Android
On 10/16/2019 3:45 PM, Michał Górny via Gnupg-users wrote: > On Wed, 2019-10-16 at 13:02 +0200, Daniel Bossert wrote: >> Hi >> >> Is anybody using pgp on Android? I did some years ago, would like to, but am >> afraid of security reason. >> >> I have safed my keys on my laptop only. >> >> How are you handling it in ages of mobiles? >> > > Get yourself a hardware key, and use that. I've been successfully using > USB NitroKey with OpenKeychain (for mail) and TermBot, though I admit > it's not the most convenient solution. FWIH, NFC keys are more > convenient; that is, if someone considers it safe to keep NFC enabled > with Google Pay installed. > On AndroidI use k9mail with openkeychain and one subkey which has only the sign capability. The use of subkey makes it possible to revoke only that subkey incase of lost of theft without having to revoked all your key. -- John Doe ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
On 16.10.2019 13:07, Patrick Brunschwig wrote: > worry for me. The main problem is the additional complexity that it > brings if you require an external component that you cannot *fully* > control. This covers topics like different behavior of different > versions, but also configuration issues, users rights to install > something on their PC and more. Gpgme may handle some of these issues, > but the fact remains: an external component makes things a lot more > complex, especially for support. I think this is the usual trade-off. One has to put time - either in understanding the APIs and command line parameters of a library / utility, and to keep up with changes, or - in re-inventing the wheel, which in this case for sure will cost much more time and eventually produce catastrophic security breaches and software which is drastically inferior compared to what we have now. After all, everybody uses libraries and utilities. It is just reasonable to have an expert work on a library or utility which uses techniques and mathematical stuff which non-specialists never will understand in detail, and have the non-specialists use that library or utility, instead of letting them re-develop the same stuff, probably introducing all sorts of security flaws and producing inferior software. When I have a bash script under Linux which invokes a compiler using a complicated command line, I wouldn't come to the idea to re-develop that compiler and integrate it directly into bash because that compiler's command line switches could change in the next version ... I am still convinced that re-writing GnuPG (including all functions like hardware tokens, subject encryption etc.) in a secure manner is a hundred times more complex and a million times more error-prone than tracking a few changes to its command line switches or error codes ever could be. Apart from that, there is GpgME, as already has been stated. Regarding the user rights to install software: That was the reason why I thought about bundling the installers and installing both parts in the same directory. Even updates to GnuPG then could be handled by TB's update system (this is only an educated guess - I don't know if the licenses would allow this). If TB would use GpgME, this problem even would not exist in the first place. GpgME would just be another library lying around in TB's installation directory (under Windows, probably a DLL) and for sure could be updated via TB's update system. Just my 2 cents ... Regards, Binarus ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Android
On Wed, 2019-10-16 at 13:02 +0200, Daniel Bossert wrote: > Hi > > Is anybody using pgp on Android? I did some years ago, would like to, but am > afraid of security reason. > > I have safed my keys on my laptop only. > > How are you handling it in ages of mobiles? > Get yourself a hardware key, and use that. I've been successfully using USB NitroKey with OpenKeychain (for mail) and TermBot, though I admit it's not the most convenient solution. FWIH, NFC keys are more convenient; that is, if someone considers it safe to keep NFC enabled with Google Pay installed. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Android
On Wed, Oct 16, 2019 at 01:02:10PM +0200, Daniel Bossert wrote: Is anybody using pgp on Android? I did some years ago, would like to, but am afraid of security reason. Hi Daniel, I'm using gnupg with Termux (Linux as app) on Android. And ssh for file transfers too. Works for me, as I'm comfortable with commandline interfaces, even on mobiles. Cheers, JC -- Doctorow's Law: Anytime someone puts a lock on something you own, against your wishes, and doesn't give you the key, they're not doing it for your benefit. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Android
YubiKeys are supported. You can use NFC key to perform crypto gimmicks or plug USB one. OpenKeychain does support quite large palette of hardware tokens. Paired with K-9 it actually provides relatively good UX.___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
Werner Koch wrote on 16.10.2019 13:54: > On Wed, 16 Oct 2019 13:07, Patrick Brunschwig said: > >> something on their PC and more. Gpgme may handle some of these issues, >> but the fact remains: an external component makes things a lot more >> complex, especially for support. > > Right GPGME handles this all pretty well and I have suggested often > enough that you should move to GPGME so that we can better support > Enigmail. Your comment about external components is right from a > company POV; however Enigmail is also an external component to TB and > thus TB suffers from very similar problem. GpgOL and GnuPG both are Which is why the step to implement OpenPGP in Thunderbird is the right way to go. > maintained by us and thus I know very well this helps to reduce > friction. We're getting slightly off-topic, but still: You're perfectly right with everything you say. But you seem to underestimate the difference between zipping an extension that is pure JavaScript, and preparing an extension that needs to contain compiled libraries for multiple platforms in order to cater for all variants of pre-installed GnuPG installations and all variations of Thunderbird installations (to be precise, at the very least I'd have to ship for 6 platforms: Win/mac/Linux * 32/64 bit). Frankly speaking, if I would consider to switch to a library instead of calling GnuPG directly, I would at first evaluate OpenPGP.js in Enigmail -- that would be a lot more natural. -Patrick ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
SSH CA + gpg-agent + gnuk => error
Hi guys, I have a question regarding the interaction of SSH with gpg-agent (and possibly also gnuk). I started out with the following setup: Every admin has his own ssh private key. All private keys are signed with an SSH CA. The server trust the CA, and thus the admins can login. No need to deploy individual keys, only the CA. Great. Now I wanted to store my private key in gnuk to protect it better. So I generated a new ECC key in gnuk, imported the public keys in gpg. Added the keygrip everything to "~/.gnupg/sshcontrol" "ssh-add -L" shows me the key. I signed it with the CA. ssh tries to use the key... ... and this is where the error pops up. ssh tells me: sign_and_send_pubkey: signing failed: agent refused operation and gpg-agent tells me: gpg-agent[21629]: ssh request handler for sign_request (13) started gpg-agent[21629]: DBG: detected card with S/N D276000124010200FFFE43032234 gpg-agent[21629]: smartcard signing failed: General error gpg-agent[21629]: ssh sign request failed: General error Without the CA (when I deploy my key explicitly on the server) it works fine. I'm not sure where the issue comes from. >From my understanding of ssh's internal workings, gnupg should not even get >informed that now a CA is used. Out of curiosity I tried the hole thing again, but without gnuk. Instead I stored the private key in gpg. And that works even with the SSH CA. Any ideas? Am I missing something obvious here? Or could this be a bug? Thanks & Regards Simon ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Android
On 16-10-2019 13:02, Daniel Bossert wrote: > Is anybody using pgp on Android? I did some years ago, would like to, > but am afraid of security reason. I use APG for old pgp 2.x keys and OpenKeyChain integrated in k9 mail for modern keys. The secret keys are protected by a password, that's my key protection. When I loose my phone, or when it gets stolen or confiscated, I'll revoke the key and create a new one. I don't believe anyone can protect a file on a phone against a skilled forensics lab. Even the best protected mobiles get cracked eventually (see the recent bootrom exploit in almost all iPhones for example). -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: are angle brackets around email address allowed for auto-key-locate?
On Tue, 15 Oct 2019 22:23, David Hebbeker said:
> The manual [1] says that GnuPG can automatically retrieve keys for
> emails in the "u...@example.com" form. Does this exclude emails wrapped
> by angle brackets like ""?
That is fine. Find below our test addresses.
Salam-Shalom,
Werner
ps.
Here is our test data set. The second string is the exepcted result, if
it is NULL we can't extract a mail address from the string:
{ "Werner Koch ", "w...@gnupg.org" },
{ "", "w...@gnupg.org" },
{ "w...@gnupg.org", "w...@gnupg.org" },
{ "w...@gnupg.org ", NULL },
{ " w...@gnupg.org", NULL },
{ "Werner Koch (test) ", "w...@gnupg.org" },
{ "Werner Koch (test)", "w...@gnupg.org" },
{ "Werner Koch ", NULL },
{ "Werner Koch ", NULL },
{ "", "f...@example.org" },
{ "", "f...@example.org" },
{ "<.f...@example.org>", ".f...@example.org" },
{ "", "fo...@example.org" },
{ "", "foo.@example.org" },
{ "", NULL },
{ "", NULL },
{ "", NULL },
{ "<@example.org>", NULL },
{ "", NULL },
{ "<@f...@example.org>", NULL },
{ " ()", "f...@example.org" },
{ " ()", "fo()o...@example.org" },
{ " ()", "fo()o...@example.org" },
{ "fo()o...@example.org", NULL},
{ "Mr. Foo ", "f...@example.org"},
{ "Surname, Forename | company ", "f...@example.org"},
/* The next one is for sure not RFC-822 correct but nevertheless
* the way gpg does it. We won't change it because the user-id
* is only rfc-822 alike and not compliant (think only of our
* utf-8 requirement). */
{ "\"\" ", "f...@example.org"},
--
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: Future OpenPGP Support in Thunderbird
On Wed, 16 Oct 2019 10:46, Martijn Brinkers said: > I actually spend a lot of time investigating the impact of EFAIL on > S/MIME and it's my opinion that the real impact has been overblown. In > all my experiments, and I can tell you I have done a lot of them, I have > not been able to force a mail client to actually forward the decrypted > content to a remote system. I recall that you mentioned this in the past and I have not seen any statement to the contrary. In fact the whole attack is nearly 20 years old and even back then it was hard to construct a case where the non-authenticated encryption could be abused. When the PGP folks and me discussed the attack around the year 2000, we knew that and suggested signed mails as a solid counter-measurement. The MDC was then introduced mainly to counter the more or less theoretical attack and to be on the safe side in case better attacks would be developed. The media and political coverage (we had working groups and internal meetings) of the efail paper however required some extra measurements to take. > I think the problem with the paper was that they discusses two separate > issues. The issue with Efail-2 was serious but that was more an mail > client issue. I fully agree here. As usual reports about the MUA failures spread for months without mentioning that all the major MUAs fixed the bug within a few days or weeks or even had fixed it at the time the paper was published. 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: Future OpenPGP Support in Thunderbird
On Wed, 16 Oct 2019 13:07, Patrick Brunschwig said: > something on their PC and more. Gpgme may handle some of these issues, > but the fact remains: an external component makes things a lot more > complex, especially for support. Right GPGME handles this all pretty well and I have suggested often enough that you should move to GPGME so that we can better support Enigmail. Your comment about external components is right from a company POV; however Enigmail is also an external component to TB and thus TB suffers from very similar problem. GpgOL and GnuPG both are maintained by us and thus I know very well this helps to reduce friction. The move to integrate OpenPGP in TB is important but also pretty risky if it won't work for everyone right away from the start. The big advantage of TB/Enigmail is that it is cross-platform and often the only way to have encrypted mail on macOS. I know several media companies who badly suffered when GpgTools were not able to get their plugin working on a new macOS version. Their journalists were then forced to use TB and not their, for whatever reason, beloved apple mailer. Let's hope that at least of one is always working. 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: Future OpenPGP Support in Thunderbird
Binarus wrote on 16.10.2019 10:47: > > On 14.10.2019 16:15, Jeff Allen via Gnupg-users wrote: >>> I don't know either, but perhaps it is in the debug logs the Enigmail >>> team analyzes? >> >> I have used Enigmail since its inception and have never knowingly >> submitted a log or answered a survey and have always assumed Enigmail >> does not phone home. > > I am sure that it doesn't phone home. However, to give an example, I had You can be certain that I'd never implement that. [...] > I suppose that the Enigmail team gets quite a lot of such debug logs. > But I still can't tell (and currently don't have the time to > investigate) if those logs can tell which keys had been generated by > Enigmail and which had been generated externally, so the whole thing was > a guess anyway. Yes, I did and do get quite a lot of debugging log files, and even more support requests. And I really speak from experience when I say that the vast majority of the users of Enigmail don't store their private keys on external devices. [...] > So why not take Enigmail, integrate it into TB, and bundle Gpg4Win setup > with TB setup? All software they ever could develop themselves will be > inferior compared to that package, at least in the first time. I have almost 17 years of experience with supporting Enigmail. About 90% of all support requests that I get turn out to be setup issues with GnuPG. Interestingly, most of them are on Linux, even though all Linux distributions I know ship GnuPG. The bundling/shipping would not be a worry for me. The main problem is the additional complexity that it brings if you require an external component that you cannot *fully* control. This covers topics like different behavior of different versions, but also configuration issues, users rights to install something on their PC and more. Gpgme may handle some of these issues, but the fact remains: an external component makes things a lot more complex, especially for support. -Patrick ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Android
Hi Is anybody using pgp on Android? I did some years ago, would like to, but am afraid of security reason. I have safed my keys on my laptop only. How are you handling it in ages of mobiles? Regards Daniel ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
> 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. I actually spend a lot of time investigating the impact of EFAIL on S/MIME and it's my opinion that the real impact has been overblown. In all my experiments, and I can tell you I have done a lot of them, I have not been able to force a mail client to actually forward the decrypted content to a remote system. The CBC attack is serious because modifying encrypted content is not something you expect from a security point of view. But the real life impact is not as big as they wanted us to believe (IMHO). I have asked the EFAIL authors for examples on real life attacks (of the CBC problem related to S/MIME) but I never got a real answer whether they were able to use the attack in real life situation. I think the problem with the paper was that they discusses two separate issues. The issue with Efail-2 was serious but that was more an mail client issue. Kind regards, Martijn ___ 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 16:15, Jeff Allen via Gnupg-users wrote: >> I don't know either, but perhaps it is in the debug logs the Enigmail >> team analyzes? > > I have used Enigmail since its inception and have never knowingly > submitted a log or answered a survey and have always assumed Enigmail > does not phone home. I am sure that it doesn't phone home. However, to give an example, I had a problem some years ago where Enigmail didn't work correctly any more when a certain other extension was installed, or vice versa. I published that problem somewhere (can't remember exactly) and got the advice to turn on Enigmail debugging and send the debug log to a certain email address or to publish it (again, can't remember). Of course, I followed that advice (after having examined the log file and having convinced myself that there was no critical data in it, as expected). I suppose that the Enigmail team gets quite a lot of such debug logs. But I still can't tell (and currently don't have the time to investigate) if those logs can tell which keys had been generated by Enigmail and which had been generated externally, so the whole thing was a guess anyway. The vast majority of users also don't use GnuPG for anything else than email. These users don't care where their key is stored, nor which software under the hood is used for the crypto. All they care is that encryption works smoothly. >>> >>> And this? >>> >> >> I am also not sure about this. As far as it concerns Windows, the first >> part of the statement may be true. > > All the statements might be true. My question was "How do you know?" Good point. I see. >> I am not sure where this will lead to. It sounds as if you were >> suggesting to give up on privacy, encryption and authentication for that >> reason. > > Not at all. My point was that I doubt OpenPGP's inclusion in > Thunderbird will have a major impact on the number of people encrypting > their email I think that even a minor impact would be desirable. The problem is: If it is done wrong (essential features missing, e.g. subject encryption, no exchange of keys with external tools, no hardware token support etc.), it could prevent a large part of today's encryption users from using encryption in the future, i.e. it even could reduce encryption prevalence. Personally, I am not sure what I'd do if the integration of PGP in TB would be broken (i.e. no subject encryption, no control over key generation and so on). Theoretically, I could move to another MUA which provides a reasonable workflow for PGP, but due to pressure of time and due to flaws or missing features in other MUAs I eventually would have to stick with TB, even if I couldn't reasonably use PGP any more. >> While I agree with you that this problem exists and is quite difficult >> to solve (eventually it needs another decade), I am absolutely sure that >> bad and difficult software will make it worse, but good and usable >> software will help in solving it. The fact that the problem exists does >> not mean that nobody should try to solve it by providing easier-to-use, >> fully integrated software with reasonable default settings. > > Here we disagree. I believe that existing software is not that > difficult to use. The problem, if there is one, is that most people > simply aren't interested. Twenty years ago I thought that everyone > would soon be using end-to-end encrypted email. Twenty years from now > they still won't be. Here the integration could really help. For example, keys could be automatically generated whenever a new email account is created in TB. Then, when sending the first message using that account, a dialog could popup asking the user: "We already have completely setup your PGP keys. Do you want to authenticate this and further messages, and do you want to attach your public key to each message so that the correspondents can encrypt their replies to you, and do you want to upload your public key to server x.y.z so that everybody can send you encrypted messages and can verify your signature?" I bet that 80% of users would answer this dialog by clicking "Yes", and I think this would really help. But once again, if too many features are missing in the integration, this will throw back email encryption prevalence by one or two decades because TB / Enigmail presumably is the most widespread software for email encryption, and I am not sure how many users could move to another MUA if PGP is broken / not fully usable in TB. >> There are many reasons to think so (the following applies to ProtonMail >> as well as Tutanota): >> >> 1) To actually use those services in a reasonable manner, you have to >> opt-in for a paid contract. For most of us, this is a matter of >> principle. Why should we pay for a thing that used to be free all the >> time? (Note: I don't want to judge that attitude - I am just stating how >> it is). > > > > But "free" email has never been free from the likes of Gmail, Yahoo, >
