Re: Future OpenPGP Support in Thunderbird
> 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. It does not. > 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. There's excellent academic research into why. I heartily recommend reading this paper: "Secrecy, Flagging, and Paranoia: Adoption Criteria in Encrypted Email". Shirley Gaw, Ed Felten, and Patricia Fernandez-Kelly, out of Princeton University. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.136.5612=rep1=pdf ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Configuration Failure Gnugp
> i am not able to follow your documentation and get Gnugp up and running > locally. I have already tried to download missing dependencies and > libraries and move them into the right directory, but that is not > working as i am getting the same error message over and over again. You will almost certainly be better off grabbing a pre-built MacOS binary from GPGTools. Building from source is regrettably complicated due to all the prerequisites that need to be installed first. If you absolutely must have your own build we'll help you through the process, but GPGTools and/or Homebrew will give you a much easier way to get up and running with GnuPG. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
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. 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
Configuration Failure Gnugp
Hello Team, i am not able to follow your documentation and get Gnugp up and running locally. I have already tried to download missing dependencies and libraries and move them into the right directory, but that is not working as i am getting the same error message over and over again. See my Error message below: - (base) anastasias-mbp:gnupg-2.2.17 anastasia.reimer$ ./configure && make && sudo make install checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... build-aux/install-sh -c -d checking for gawk... no checking for mawk... no checking for nawk... no checking for awk... awk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking build system type... x86_64-apple-darwin18.7.0 checking host system type... x86_64-apple-darwin18.7.0 configure: autobuild project... gnupg configure: autobuild revision... 2.2.17 configure: autobuild hostname... anastasias-mbp.hamburg.de.ibm.com configure: autobuild timestamp... 20191014-095950 checking for style of include used by make... GNU checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking whether gcc understands -c and -o together... yes checking dependency style of gcc... gcc3 checking how to run the C preprocessor... gcc -E checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking minix/config.h usability... no checking minix/config.h presence... no checking for minix/config.h... no checking whether it is safe to define __EXTENSIONS__... yes checking whether SELinux support is requested... no checking whether to allocate extra secure memory... no checking calibrated passphrase-stretching (s2k) duration... 100 milliseconds checking whether to enable trust models... yes checking whether to enable TOFU... yes checking whether to enable libdns... yes checking whether to enable the RSA public key for gpg... yes checking whether to enable the ECDH public key for gpg... yes checking whether to enable the ECDSA public key for gpg... yes checking whether to enable the EdDSA public key for gpg... yes checking whether to enable the IDEA cipher for gpg... yes checking whether to enable the CAST5 cipher for gpg... yes checking whether to enable the BLOWFISH cipher for gpg... yes checking whether to enable the AES128 cipher for gpg... yes checking whether to enable the AES192 cipher for gpg... yes checking whether to enable the AES256 cipher for gpg... yes checking whether to enable the TWOFISH cipher for gpg... yes checking whether to enable the CAMELLIA128 cipher for gpg... yes checking whether to enable the CAMELLIA192 cipher for gpg... yes checking whether to enable the CAMELLIA256 cipher for gpg... yes checking whether to enable the MD5 hash for gpg... yes checking whether to enable the RIPE-MD160 hash for gpg... yes checking whether to enable the SHA-224 hash for gpg... yes checking whether to enable the SHA-384 hash for gpg... yes checking whether to enable the SHA-512 hash for gpg... yes checking whether to enable the ZIP and ZLIB compression algorithm... yes checking whether to enable the BZIP2 compression algorithm... yes checking whether to enable external program execution... yes checking whether to enable photo ID viewing... yes checking whether to use a fixed photo ID viewer... no checking for the size of the key and uid cache... 4096 checking whether use of capabilities is requested... no checking whether smartcard support is requested... yes checking whether to enable the internal CCID driver... auto checking whether to auto start dirmngr... yes checking whether to enable maintainer-specific portions of Makefiles... no configure: checking for programs checking whether make sets $(MAKE)... (cached) yes checking whether build environment is sane... yes checking whether make supports nested variables... (cached) yes checking for gawk... (cached) awk checking for gcc... (cached) gcc checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ISO C89... (cached) none needed checking whether gcc understands -c
Re: Future OpenPGP Support in Thunderbird
On 14.10.2019 18:54, Juergen Bruckner via Gnupg-users wrote: > Hello to all, > > well it's a good thing, that openPGP shall be included to TB directly. > > But ... as the Mozilla wiki [1] states in the FAQ-Section the following: > > > Q: Will OpenPGP cards be supported for private key storage ? > > A: Probably not, because we don't use the GnuPG software that's usually >required to access OpenPGP smartcards. I agree OpenPGP smartcard/token support is a must have, and brought this up during this during this weekend's OpenPGP summit; please see the [notes] section "Workshop: Thunderbird & OpenPGP" for some of the discussion, specifically """ Although RNP doesn't support smartcards currently, a potential solution 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 only works if the user has installed software (scd etc.) in addition to Thunderbird. How would this work? GnuPG as an optional dependency? Outsourcing smartcard handling to scdaemon (scd), which is available cross-platform through Unix socket or TCP/IP (windows) with usual user system protection? Or... extend the RNP library to talk to scd? Needs discussion and contributors, but that should wait until we're certain what library TB will use. """ References: [notes] https://wiki.gnupg.org/OpenPGPEmailSummit201910Notes -- 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
Re: Future OpenPGP Support in Thunderbird
Hello to all, well it's a good thing, that openPGP shall be included to TB directly. But ... as the Mozilla wiki [1] states in the FAQ-Section the following: Q: Will OpenPGP cards be supported for private key storage ? A: Probably not, because we don't use the GnuPG software that's usually required to access OpenPGP smartcards. This will not be usefull for me or my company, as we only use PGP Keys stored on smartcards. So I guess we will have to take TB down and find other solutions. m2c Juergen [1] https://wiki.mozilla.org/Thunderbird:OpenPGP:2020 -- Juergen M. Bruckner juer...@bruckner.tk smime.p7s Description: S/MIME Cryptographic Signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
On Mon, 14 Oct 2019 10:54, Phillip Susi said: >> encryption protocol is S/MIME and the last time I checked S/MIME (well, >> CMS for the nitpickers) does not supoport any kind of authenticated >> encryption. In contarst OpenPGP provides this nearly for 2 decades. > > What do you mean? S/MIME authenticates the user's identity via the CA. 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. 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). 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
Werner Koch via Gnupg-users writes: > Still, TB is still subject to those attacks because their primary > encryption protocol is S/MIME and the last time I checked S/MIME (well, > CMS for the nitpickers) does not supoport any kind of authenticated > encryption. In contarst OpenPGP provides this nearly for 2 decades. What do you mean? S/MIME authenticates the user's identity via the CA. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
On 10/14/19 3:40 AM, Binarus wrote: > > On 13.10.2019 22:27, Jeff Allen via Gnupg-users wrote: >> On 10/13/19 2:21 AM, Patrick Brunschwig wrote: >>> The vast majority of users of Enigmail (somewhere around 98%) don't use >>> external built keys. >> >> How do you know this? >> > > 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. >>> 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?" > I disagree with the second part of the statement, though. Most of the > people who think about privacy and email encryption / authentication at > all are educated, non-average users who want to be sure that there are > no backdoors in their software and that they use it as safely as > possible (meaning that they care about software, algorithms and > ciphers), and who want to backup their keys (meaning that they care > where the keys are stored). And yes, I want to decide on my own if my > key is ED25519, RSA1024 or RSA4096 :-) I agree and think Patrick underestimates the number of GnuPG/Enigmail users who care a lot about the details. My argument in the other thread was that folks who value privacy and encryption but can't be burdened by the details have reasonably secure easy-to-use options available. Enigmail is, of course, one of them. >>> The most important aspects from our side are the following: The chosen >>> solution must run smoothly for the ~20M users of Thunderbird without >>> causing a large amount of support/setup issues. >> >> Presumably those ~20,000,000 will have to opt-in to use Thunderbird >> encryption. Most won't for the same reason they don't install and use >> Enigmail now. They don't particularly care about privacy, and the few >> who do care correspond with people who don't. >> > > 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. > 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. >>> We want to have >>> something that satisfies as many users of Enigmail as possible. We >>> certainly don't want to have people run away from Thunderbird because of >>> OpenPGP. >> >> [Snip] >> >> Is there any reason to think that folks who object to easy-to-use >> proprietary encrypted email solutions from ProtonMail and Tutanota will >> embrace a proprietary encrypted email solution from Thunderbird? >> > > 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, GMX, etc. While you don't pay a yearly fee, you trade your privacy for a few bucks. You open yourself to tracking and targeted advertising. Your email is anything but private. A couple years back both Google and Yahoo claimed to be working on E2EE. I wonder why it never happened? The free versions of ProtonMail, Tutanota and Mailfence at least preserve your privacy. They aren't monetized through advertising and tracking. Instead they sell premium services to people who want more capacity or features. Many people I know do email exclusively on their smart phones. They don't use an MUA and don't care about POP3, IMAP or SMTP. Their view of using email services in a reasonable manner doesn't comport with yours or mine. I hope I am wrong and Thunderbird's
Re: Future OpenPGP Support in Thunderbird
On 14.10.2019 09:17, Patrick Brunschwig wrote: > Binarus wrote on 13.10.2019 18:27: > [...] >> 1) The schedule >> >> We have all been educated to update our applications (notably, "internet >> applications" like browser and email clients) as soon as updates are >> available; at least, this is true for security updates. >> >> Despite release plans, I think nobody knows for sure how much time >> actually will pass between TB 72's predecessor and TB 78, and how many >> security updates will be released between these versions. >> >> During that time, I either can't use Enigmail (if I decide to install >> the security updates), or I have to ignore the security updates >> (possibly putting me to risk). >> >> Did I understand this correctly? > > The current stable version of Thunderbird is 68 (and 60 for a few more > weeks); the next stable version will be 78. Users of Enigmail staying on > the stable version of Thunderbird will receive all security updates > until TB 78 will be available. Thunderbird 69 ... 77 are only released > as beta versions that are not intended for end users. > I see. Thank you very much for the clarification. This relieves a lot of tension. Regards, Binarus ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
On 13.10.2019 22:27, Jeff Allen via Gnupg-users wrote: > On 10/13/19 2:21 AM, Patrick Brunschwig wrote: >> The vast majority of users of Enigmail (somewhere around 98%) don't use >> external built keys. > > How do you know this? > I don't know either, but perhaps it is in the debug logs the Enigmail team analyzes? >> 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. There is plenty of software to encrypt single files or directories for Windows, including the software which is part of the O/S. People probably tend to go the easiest way, even if another solution would be safer and technically superior. I don't know the situation under Linux well enough to comment. I disagree with the second part of the statement, though. Most of the people who think about privacy and email encryption / authentication at all are educated, non-average users who want to be sure that there are no backdoors in their software and that they use it as safely as possible (meaning that they care about software, algorithms and ciphers), and who want to backup their keys (meaning that they care where the keys are stored). And yes, I want to decide on my own if my key is ED25519, RSA1024 or RSA4096 :-) >> The most important aspects from our side are the following: The chosen >> solution must run smoothly for the ~20M users of Thunderbird without >> causing a large amount of support/setup issues. > > Presumably those ~20,000,000 will have to opt-in to use Thunderbird > encryption. Most won't for the same reason they don't install and use > Enigmail now. They don't particularly care about privacy, and the few > who do care correspond with people who don't. > 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. 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. >> We want to have >> something that satisfies as many users of Enigmail as possible. We >> certainly don't want to have people run away from Thunderbird because of >> OpenPGP. > > [Snip] > > Is there any reason to think that folks who object to easy-to-use > proprietary encrypted email solutions from ProtonMail and Tutanota will > embrace a proprietary encrypted email solution from Thunderbird? > 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). 2) None of that services supports IMAP or POP3. I would be totally crazy if I would make myself totally dependent on companies or services which won't let me download my messages and integrate them into my email client. What happens if those companies suddenly stop their service and you haven't downloaded your messages yet (which anyway seems to be impossible)? Or if you decide that you want to use another service? How long will you be able to access your messages after you have stopped paying your old service? Will they delete your messages until the quota for free usage is reached again? I insist on having all important data, including email messages, in-house and under my complete control, and I strongly advise each of my customers to do the same. So far, all of them are following that advice. Therefore, such services never will have any chance to do business with my customers. 3) I have several email addresses. I am definitely not ready to use a different website or different software for each of them. That is, there is absolutely no chance that I ever will use a service which does not provide POP3 or IMAP (or, for the protocol, their successors). I want *one* MUA (like Thunderbird) to be able to manage *all* of my email messages in *one* place (For example, ever needed to search for a message for which you can't remember the account it was received on? - The global search in TB is very handy here. Further reasons: junk filtering, action filters (automatically moving certain messages in subfolders) and so on, all managed at one place, public folders, shared folders and so on). 4) I doubt that these services can be legally used
Re: Future OpenPGP Support in Thunderbird
Binarus wrote on 13.10.2019 18:27: [...] > 1) The schedule > > We have all been educated to update our applications (notably, "internet > applications" like browser and email clients) as soon as updates are > available; at least, this is true for security updates. > > Despite release plans, I think nobody knows for sure how much time > actually will pass between TB 72's predecessor and TB 78, and how many > security updates will be released between these versions. > > During that time, I either can't use Enigmail (if I decide to install > the security updates), or I have to ignore the security updates > (possibly putting me to risk). > > Did I understand this correctly? The current stable version of Thunderbird is 68 (and 60 for a few more weeks); the next stable version will be 78. Users of Enigmail staying on the stable version of Thunderbird will receive all security updates until TB 78 will be available. Thunderbird 69 ... 77 are only released as beta versions that are not intended for end users. -Patrick ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Cannot decrypt from smartcard using gnupg-2.2, can from 2.0
alejandro Cortez wrote: > gpg: public key decryption failed: Invalid ID This means that something goes wrong in your private key file for your token, I suppose. > Can anyone help debug this? You can see more information, by following command line: $ gpg-connect-agent "KEYINFO --list" /bye This doesn't reveal secret (but your serial number). The example output (of mine) is like: == $ gpg-connect-agent "KEYINFO --list" /bye S KEYINFO A97A7983102513844456E5B687E46B936B14155C D - - - P - - - S KEYINFO 65F67E742101C7FE6D5B33FCEFCF4F65EAF0688C T D276000124010200F5170001 OPENPGP.2 - - - - - S KEYINFO 101DE7B639FE29F4636BDEECF442A9273AFA6565 T D276000124010200F5170001 OPENPGP.1 - - - - - S KEYINFO 5D6C89682D07CCFC034AF508420BF2276D8018ED T D276000124010200F5170001 OPENPGP.3 - - - - - OK $ == The third column is a keygrip. The fifth column is an application ID (vendor id + serial number) of the card. The sixth column is the key identifier. The key identifier "OpenPGP.2" is used for decription process. I suspect you have some different string there, for some reason. -- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
