Re: pinentry-gtk-2 dialog doesn't appear before getting input
Andreas Ronnquist wrote: > I have a problem on Debian unstable (running in Virtualbox), running the > Xfce desktop - > > I have my gpg key on a card (a Librem key, which basically is a > Nitrokey) when using pinentry to enter the card password, I first have > to press my mouse on the screen (or a key on my keyboard) to make the > password dialog appear. I think that it's related to window manager. For testing, you can manually invoke pinentry like: $ pinentry # run pinentry by command line (-gtk2 or any) confirm# shows a dialog box bye# finish the session $ Doing this makes it easy to identify a problem (from complicated interaction of gpg <-> gpg-agent <-> pinentry). > Is there any way to make the dialog appear at once, when it is ready to > take my passphrase entry, or some workaround of any kind? It seems for me that: You can somehow control the behavior of the window manager. In its configuration by "Focus" tab in "Window Manager Tweaks": https://docs.xfce.org/xfce/xfwm4/wmtweaks And/or the first entry of "Accessibility" tab which says "Raise windows when any mous button is pressed". Or "Focus" tab in "Preferences": https://docs.xfce.org/xfce/xfwm4/preferences Looking the commit log of xfwm4 (about "stacking"), it appears something has been changed. -- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gnupg private-keys encryption
> Change the passphrase. Tried this now. No change in the encryption scheme in 2.2.17. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Modern gnupg.conf setup
On 15. 12. 19 19:32, Robert J. Hansen wrote: > >> It seems I was right to have asked here after all. It's amazing how many >> outdated tutorials exist... > > That presumes they were ever accurate in the first place. Many of them > were not. > >>> personal-cipher-preferences AES256 CAMELLIA256 TWOFISH AES192 >>> CAMELLIA192 AES CAMELLIA128 >>> personal-digest-preferences SHA512 SHA384 SHA256 SHA224 RIPEMD160 >> >> Should these also be included in the default-preference-list? I think >> the latter is only used when generating new keys (setpref), yes? > > Not necessarily. Personal-cipher-preferences is the list of ciphers > you're willing to use, but the list of ciphers on your key (what's put > there via setpref) is the list of ciphers you ask *other people* to use. > > Will they often be the same? Yes. But not always, and there's a > subtlety there that's often overlooked. You might be willing to > generate traffic using ciphers you're not willing to accept. > cert-digest-algo SHA512 >>> >>> Still valid, still useful. >> >> This I'm uncertain about. Should probably be removed too? > > Probably not. > > The reason why cipher-algo and digest-algo are recommended against is > because GnuPG already has a robust mechanism for choosing a strong > cipher that you're willing to generate (via personal-cipher-preferences) > and the recipient is willing to receive (via prefs on the key). > > There is no such mechanism for certificate signatures. That's entirely > generated by you. You have zero knowledge of what algorithm other > people will use. If you want maximum interoperability, you have to use > SHA-1; everyone can read SHA-1 signatures. > > But that's SHA-1, and SHA-1 isn't exactly a highly recommended digest > any more. > > Use something better and stronger. SHA512 is probably the best option > right now. If someone can't read your certificate signatures, well -- > that's on them: they should be moving away from SHA-1. > >> The RFC 4880 standard (section 9) does say that 3DES and SHA-1 must be >> implemented, but the reason I included these is because I read on some >> websites that you do NOT want to use these at all due to their >> weaknesses and there should be some way of warning the user that weak >> algorithms are being used. > > I question the credentials of anyone calling 3DES "weak". It has one > and only one serious cryptographic weakness: due to its 64-bit block > size, it should not be used to encrypt more than about 4Gb of data with > the same session key. > > 40 years after it was first released, the best attack on it is a > meet-in-the-middle that requires -- hand to God, I am not making this up > -- 64 pebibytes of RAM, 2**112 operations, and several strategic nuclear > weapons to generate enough energy to run the computer. > > Let me repeat: I am not making that up. > > So, yeah, if your attacker has technology straight out of _Star Trek_ > and is willing to cause untold ecological catastrophe, you're hosed. > Otherwise, 3DES is still solid. > > That's not to mean it's perfect. It's not. It's slow, it shouldn't be > used to encrypt bulk data due to its 64-bit blocksize, and more. There > are lots of reasons to prefer other, better ciphers than 3DES. And > maybe I can understand people calling it "weak" because really, that's a > lot easier for people to understand than talking about block sizes and > clock-cycles-per-block and everything else. > > But it's *not weak*. And any website that tells you to avoid 3DES > because it's weak is, to be honest, either too ignorant to be taken > seriously, so patronizing they'll handwave away complex issues behind > the comforting veneer of "it's weak", or is outright lying to you. > > SHA-1, on the other hand... > > *At the present moment* SHA-1 is still trustworthy in the places where > it's baked into the RFC4880 spec. The attacks against it don't affect > the (few) places where it's baked into OpenPGP. But attacks can get > better quite suddenly, and it's a good idea to avoid SHA-1 whenever > possible. > > But please don't use weak-digest on SHA-1. The only thing it'll do is > drown you in false positives. 99.999% of the time when you get a > warning of "SHA-1 is being used You asked me to warn you about > it!", in fact nothing is amiss at all. > > A 'warning' that's wrong 99.999% of the time is worse than receiving no > warning at all. > > ___ > Gnupg-users mailing list > Gnupg-users@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > Hey, thanks for all the help. That was really an educational read. I ended up with this config file contents: keyid-format 0xlong with-fingerprint personal-cipher-preferences AES256 CAMELLIA256 TWOFISH AES192 CAMELLIA192 AES CAMELLIA128 personal-digest-preferences SHA512 SHA384 SHA256 SHA224 RIPEMD160 default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES ZLIB BZIP2 ZIP Uncompressed cert
Re: Usability of OpenSSL vs GNUPG
On Sat, Dec 14, 2019 at 08:05:04PM -0500, Dave via Gnupg-users wrote: I can’t recall encountering any similar complaints about OpenSSL. I find this somewhat curious, and am wondering if there are OpenSSL detractors out there that I simply haven’t come across OpenSSL definitely has its detractors. They were for example very vocal back in 2014 in the aftermath of the Heartbleed bug. OpenSSL command structure isn’t as complicated as it seems to me. For what I have seen, most of the criticisms against OpenSSL are directed at the code and/or the API rather than at the command line tools. This may reflect the fact that OpenSSL is probably more often used as a programming library than as a set of command line tools. That being said I have seen complaints about the command line OpenSSL tools as well. (I’ve heard a crypto-nerd once telling me that the only way to correctly generate a certificate signing request using OpenSSL’s req command was to type the command while sitting in a demonic circle after having sacrificed at least a dozen of chickens—or two dozens if the CSR is for a ECC certificate.) I suppose that OpenSSL is geared toward a very technical and security-aware user base, who aren’t likely to complain about usability issues I am not sure I’d buy that. All the criticisms I have seen against either GnuPG or OpenSSL came from very technical-minded people. By contrast, in my experience non-technical people showing up at cryptoparties are very much willing to use the software as it is, learning what they need to learn instead of complaining that the software should be simple enough that they shouldn’t have to learn anything. (Of course those are the people motivated enough to attend a cryptoparty. They may not reflect the larger group of users.) Cheers, - Damien signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Modern gnupg.conf setup
> It seems I was right to have asked here after all. It's amazing how many > outdated tutorials exist... That presumes they were ever accurate in the first place. Many of them were not. >> personal-cipher-preferences AES256 CAMELLIA256 TWOFISH AES192 >> CAMELLIA192 AES CAMELLIA128 >> personal-digest-preferences SHA512 SHA384 SHA256 SHA224 RIPEMD160 > > Should these also be included in the default-preference-list? I think > the latter is only used when generating new keys (setpref), yes? Not necessarily. Personal-cipher-preferences is the list of ciphers you're willing to use, but the list of ciphers on your key (what's put there via setpref) is the list of ciphers you ask *other people* to use. Will they often be the same? Yes. But not always, and there's a subtlety there that's often overlooked. You might be willing to generate traffic using ciphers you're not willing to accept. >>> cert-digest-algo SHA512 >> >> Still valid, still useful. > > This I'm uncertain about. Should probably be removed too? Probably not. The reason why cipher-algo and digest-algo are recommended against is because GnuPG already has a robust mechanism for choosing a strong cipher that you're willing to generate (via personal-cipher-preferences) and the recipient is willing to receive (via prefs on the key). There is no such mechanism for certificate signatures. That's entirely generated by you. You have zero knowledge of what algorithm other people will use. If you want maximum interoperability, you have to use SHA-1; everyone can read SHA-1 signatures. But that's SHA-1, and SHA-1 isn't exactly a highly recommended digest any more. Use something better and stronger. SHA512 is probably the best option right now. If someone can't read your certificate signatures, well -- that's on them: they should be moving away from SHA-1. > The RFC 4880 standard (section 9) does say that 3DES and SHA-1 must be > implemented, but the reason I included these is because I read on some > websites that you do NOT want to use these at all due to their > weaknesses and there should be some way of warning the user that weak > algorithms are being used. I question the credentials of anyone calling 3DES "weak". It has one and only one serious cryptographic weakness: due to its 64-bit block size, it should not be used to encrypt more than about 4Gb of data with the same session key. 40 years after it was first released, the best attack on it is a meet-in-the-middle that requires -- hand to God, I am not making this up -- 64 pebibytes of RAM, 2**112 operations, and several strategic nuclear weapons to generate enough energy to run the computer. Let me repeat: I am not making that up. So, yeah, if your attacker has technology straight out of _Star Trek_ and is willing to cause untold ecological catastrophe, you're hosed. Otherwise, 3DES is still solid. That's not to mean it's perfect. It's not. It's slow, it shouldn't be used to encrypt bulk data due to its 64-bit blocksize, and more. There are lots of reasons to prefer other, better ciphers than 3DES. And maybe I can understand people calling it "weak" because really, that's a lot easier for people to understand than talking about block sizes and clock-cycles-per-block and everything else. But it's *not weak*. And any website that tells you to avoid 3DES because it's weak is, to be honest, either too ignorant to be taken seriously, so patronizing they'll handwave away complex issues behind the comforting veneer of "it's weak", or is outright lying to you. SHA-1, on the other hand... *At the present moment* SHA-1 is still trustworthy in the places where it's baked into the RFC4880 spec. The attacks against it don't affect the (few) places where it's baked into OpenPGP. But attacks can get better quite suddenly, and it's a good idea to avoid SHA-1 whenever possible. But please don't use weak-digest on SHA-1. The only thing it'll do is drown you in false positives. 99.999% of the time when you get a warning of "SHA-1 is being used You asked me to warn you about it!", in fact nothing is amiss at all. A 'warning' that's wrong 99.999% of the time is worse than receiving no warning at all. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Usability of OpenSSL vs GNUPG
Hi, On Sun, Dec 15, 2019, at 2:05 AM, Dave via Gnupg-users wrote: > I’ve been playing around some with OpenSSL recently, and it seems to me > that the OpenSSL command structure is rather convoluted. I’ve read a > number of articles, blog posts, etc. that criticize GNUPG and even make > the case that people should stop using it, in large part because of > concerns around the GNUPG command structure and general usability. Most of the criticism I have seen is that it is difficult for the target users of a specific use case to use gpg effectively to protect themselves. This is things like message/email encryption/verification. > Yet > I can’t recall encountering any similar complaints about OpenSSL. I > find this somewhat curious, and am wondering if there are OpenSSL > detractors out there that I simply haven’t come across or if the > OpenSSL command structure isn’t as complicated as it seems to me. Or if > it seems to others that OpenSSL doesn’t get the same level of criticism > as GNUPG does for usability, although the tools seem to offer a > generally similar user experience. I haven't seen OpenSSL pitched as the GPG replacement here, possibly for the reasons you cite. Mostly I see, use application X (Signal, etc.) and don't believe email can reasonably be secured without ALL parties being "experts" at GPG. The one use case no one seems to have a replacement for is "encrypt this file on disk for me to use later." > I suppose that OpenSSL is geared toward a very technical and > security-aware user base, who aren’t likely to complain about usability > issues – while GNUPG is a tool that could be used by all sorts of > users, some of whom are definitely not technically inclined or > interested in details of information security. That alone could explain > the difference, I suppose. But I’m wondering if anyone has any other > thoughts around this topic. My understanding is that most people encounter OpenSSL configured by someone else who is presumably a technical expert. What usecases do you have in mind? regards, bex > > > Thanks, > > > Dave > > ___ > Gnupg-users mailing list > Gnupg-users@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Modern gnupg.conf setup
Thank you kindly for your very informative answers. It seems I was right to have asked here after all. It's amazing how many outdated tutorials exist i.e. googling for "perfect pgp keypair" gives at least three "wrong" articles among the top few results. Having read the GnuPG docs a bit it appears a lot of options I listed are already enabled by default by a recent gpg, so I removed them. On 15. 12. 19 01:31, Robert J. Hansen wrote:> > Instead, try this: > > personal-cipher-preferences AES256 CAMELLIA256 TWOFISH AES192 > CAMELLIA192 AES CAMELLIA128 > personal-digest-preferences SHA512 SHA384 SHA256 SHA224 RIPEMD160 > Should these also be included in the default-preference-list? I think the latter is only used when generating new keys (setpref), yes? Alas: personal-cipher-preferences AES256 CAMELLIA256 TWOFISH AES192 CAMELLIA192 AES CAMELLIA128 personal-digest-preferences SHA512 SHA384 SHA256 SHA224 RIPEMD160 default-preference-list SHA512 SHA384 SHA256 SHA224 RIPEMD160 AES256 CAMELLIA256 TWOFISH AES192 CAMELLIA192 AES CAMELLIA128 ZLIB BZIP2 ZIP Uncompressed >> cert-digest-algo SHA512 > > Still valid, still useful. > This I'm uncertain about. Should probably be removed too? The documentation says: --cert-digest-algo name Use name as the message digest algorithm used when signing a key. Running the program with the command --version yields a list of supported algorithms. *Be aware that if you choose an algorithm that GnuPG supports but other OpenPGP implementations do not, then some users will not be able to use the key signatures you make, or quite possibly your entire key.* Source: https://www.gnupg.org/documentation/manuals/gnupg/GPG-Esoteric-Options.html#GPG-Esoteric-Options >> disable-cipher-algo 3DES IDEA CAST5 Blowfish > > 3DES is a MUST algorithm, according to the spec. If you want to disable > the others that's your business -- but it's already implicit by not > including them in your personal-cipher-preferences. This line can be > removed entirely. > >> weak-digest SHA1 > > Again, SHA-1 is a MUST. > The RFC 4880 standard (section 9) does say that 3DES and SHA-1 must be implemented, but the reason I included these is because I read on some websites that you do NOT want to use these at all due to their weaknesses and there should be some way of warning the user that weak algorithms are being used. disable-cipher-algo 3DES weak-digest SHA1 If some client can't support newer algorithms like SHA-2 and AES then it's better if that person upgraded their software rather than continue to use SHA-1 and 3DES. Best regards, Mistave. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
