Re: Certified OpenPGP-encryption after release of Thunderbird 78
W dniu 30.05.2020 o 01:26, Robert J. Hansen pisze: >> 1. Will key management and crypto happen in the same process as >> IMAP/POP/SMTP, GUI, JavaScript and everything else? If so - do you >> believe it's acceptable? > > It should be an easy learning curve for Enigmail users. That isn't the > same as finding it acceptable, though. > > Back in the mid-'90s PGP came out with a GUI for PGP 5, and it's > universally agreed at user interface was horrific. (See "Why Johnny > Can't Encrypt" for a detailed teardown.) The problem was that this > horrific user interface became the standard user interface, and most > OpenPGP key managers ever since have adopted it. Those that haven't > adopted it, nobody uses, because their UI is so different than > everything else. I wasn't asking if GUI is acceptable. I was asking if crypto and GUI happen in the same process (the main TB process). Since they seem to be using a library for PGP it's quite probable. And if so - is that acceptable in your opinion? >> 2. Is there any real plan to have working smartcard support in the >> near future? > > No. There's some talk about supporting it, but as far as I know there's > no plan to do it. It's still at the "you know, it'd be kind of nice > if..." stage, not the "we really should do this" stage. Double nice. Time to check Claws I think. -- Grzegorz Kulewski g...@leniwiec.biz +48 663 92 88 95 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Certified OpenPGP-encryption after release of Thunderbird 78
W dniu 30.05.2020 o 01:07, Robert J. Hansen pisze: >> If TB 78 is going to have native support of openGPG encryption, then the >> original person in the thread should be able to export all of the keys >> in their key rings, and import all of those keys into TB 78, or am I >> missing one of the gotchas with >> TV 78 and it's openGPG encryption support. > > You're missing the gotcha of "as of -Beta3, the new Thunderbird *cannot > even import a key*." > > I'm not kidding. It is so far from complete that Kai Englert, who leads > the TB78 OpenPGP effort, recently proposed postponing OpenPGP support in > TB until version 78.2, or about a three-month delay. > > At present, as of -Beta3, TB78's OpenPGP support is badly broken. Nice. Since you seem to be following OpenPGP-in-TB78 development: 1. Will key management and crypto happen in the same process as IMAP/POP/SMTP, GUI, JavaScript and everything else? If so - do you believe it's acceptable? 2. Is there any real plan to have working smartcard support in the near future? -- Grzegorz Kulewski ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Comparison of RSA vs elliptical keys
W dniu 12.05.2020 o 17:04, Sylvain Besençon via Gnupg-users pisze: > In the FAQ, it is written: >> Will GnuPG ever support RSA-3072 or RSA-4096 by default? >> Probably not. The future is elliptical-curve cryptography, which will bring >> a level of safety comparable to RSA-16384. Every minute we spend arguing >> about whether we should change the defaults to RSA-3072 or more is one >> minute the shift to ECC is delayed. Frankly, we think ECC is a really good >> idea and we’d like to see it deployed as soon as humanly possible. > (https://www.gnupg.org/faq/gnupg-faq.html#default_rsa2048) > > So, I guess the key size is not the only criteria to evaluate the strength of > a cipher and ECC still provides better results despite shorter keys. > > However, I would be interested to know which ECC cipher would you recommend > to replace RSA. I am not a cryptographer and I don't find any information (or > more honestly: information that I can understand) about Curve 25519, NIST > P-256 (and greater), Brainpool, or secp256k1. Disclaimer: I am not a cryptographer either, let's just say I am an advisor. So, anybody, please correct me, if needed. 1. In terms of key size Curve 25519 and P-256 should have same strength: ~128 bits (== comparing with good symmetric cipher, like AES). Generally decent ECC strength = ~0.5 * key_length_in_bits. 2. Curve 25519 is very easy to implement in such a way that the implementation is fast. Implementations of other curves are usually slower. 3. Curve 25519 is generally easier to implement and easier to implement in such a way that avoids many common security pitfalls, like vulnerability to timing attacks. 4. The design of Curve 25519 is public, (is believed to be) software patent free and all constants in it are derived in an easily explainable ways. There are no "magic numbers" out of nowhere that may be just random or maybe were chosen by designers to make some kind of backdoor - but you can never prove that they are innocent since obviously you can't prove that random number was indeed chosen truly randomly. 5. Curve 25519 was designed by DJB, an (mostly) independent security expert while others were designed/standardized by big organizations that (given indirect evidence and rumors) may not be that trustworthy. 6. This is why many new (and not only, see SSH) protocols tend to choose Curve 25519. But in PGP you should be careful because many implementations (and/or older versions) don't support it. So if you want portability/interoperability you may want some other curve or RSA, especially for the main and signing key. 7. If you want something stronger than Curve 25519 that (is believed to) share similar benefits try Curve 448 (~224 bits of security). But I am not sure if PGP implements it (yet?). -- Grzegorz Kulewski ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Performance of Yubikey fw >= 5.2.3 and Curve25519 in OpenPGP
Hello, Some time ago Yubico released Yubikeys 5 with new firmware capable of doing Curve25519 in OpenPGP (and not only). Unfortunately they don't offer any benchmarks so one can't be sure if the performance is decent vs. for example RSA 2048 and 4096. Also it seems that nobody published such benchmarks independently. Does anybody here have Curve25519 enabled Yubikey and did/could do such benchmarks? Thank you in advance! -- Grzegorz Kulewski ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Automating and integrating GPG
Hello, I am working on a project (in Python and bash) that requires me to use GPG in "headless mode" to generate keys and edit OpenPGP smartcard (to set some properties and transfer some of the generated keys). This includes transfering any passwords and PINs from my program to GPG, instead of requiring user to enter them using pinentry. I wonder what method of integration of GPG with such project is best, most future-proof and recommended and are there any other advices you may give me? Thank you in advance. -- Grzegorz Kulewski ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
