There are various claims going around about how GnuPG should be disabling SHA1 now; the competent cryptographers I know are pointing out that a collision is not a second pre-image, don't panic and cargo-cult (but also yes it's time and past time to be making sure we have a clear path away). I'm not a cryptographer. I do like to have hard facts to base decisions on when I can.
This email is to summarize the current practical reality of trying to move away; I took a copy of my ~/.gnupg directory, pointed the `GNUPGHOME` environment variable to that copy, and set `weak-digest SHA1` in the `gpg.conf` in that is used, then invoked `gpg --update-trustdb`. % gpg --version gpg (GnuPG) 2.1.18 libgcrypt 1.7.6 pubring.kbx is 195 MiB. There are a few secret keys in this keyring, including some expired but with signatures out expanding the trust set; the primary key is MSD ranking 6544 in the strong-set. So in a "normal" world, I can verify trust-paths to a lot of keys and I would expect a lot of verifiable keys. The _only_ difference in `gpg.conf` is the `weak-digest SHA1` setting. -------------------------8< weak-digest SHA1 >8------------------------- gpg: Note: signatures using the SHA1 algorithm are rejected gpg: marginals needed: 3 completes needed: 1 trust model: pgp gpg: Note: signatures using the MD5 algorithm are rejected gpg: depth: 0 valid: 4 signed: 16 trust: 0-, 0q, 0n, 0m, 0f, 4u gpg: depth: 1 valid: 16 signed: 9 trust: 0-, 3q, 1n, 7m, 5f, 0u gpg: depth: 2 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 1f, 0u gpg: next trustdb check due at 2017-03-12 gpg2.1 --update-trustdb 3831.13s user 8877.51s system 99% cpu 3:31:49.39 total -------------------------8< weak-digest SHA1 >8------------------------- ----------------------8< normal, SHA1 not weak >8----------------------- gpg: Note: signatures using the MD5 algorithm are rejected gpg: depth: 0 valid: 4 signed: 78 trust: 0-, 0q, 0n, 0m, 0f, 4u gpg: depth: 1 valid: 78 signed: 576 trust: 0-, 29q, 2n, 27m, 20f, 0u gpg: depth: 2 valid: 303 signed: 1478 trust: 0-, 173q, 2n, 90m, 38f, 0u gpg: depth: 3 valid: 788 signed: 1445 trust: 0-, 479q, 3n, 270m, 36f, 0u gpg: depth: 4 valid: 442 signed: 927 trust: 0-, 320q, 6n, 96m, 20f, 0u gpg: next trustdb check due at 2017-02-25 gpg2.1 --update-trustdb 595.94s user 125.16s system 99% cpu 12:01.38 total ----------------------8< normal, SHA1 not weak >8----------------------- For those interested in the time-discrepancies: this is a 3.13.0-110-generic kernel for Ubuntu on an Atom computer which is a few years old; /proc/cpuinfo reports two cores, as: Intel(R) Atom(TM) CPU D2500 @ 1.86GHz Summary: * Normally, I have 1611 valid non-ultimate keys in my keyring * This drops to 17 keys without trusting SHA1 * So I get to keep trust-paths to just over 1% of my keyring; I lose trust-paths to 98.9% of my trusted links * Disabling SHA1 today utterly breaks the current web-of-trust * We're going to need to spend _years_ re-issuing signatures with a newer hash algorithm before we can safely disable SHA1 without totally destroying WoT (unless a crypto break does appear and we have to disable it for the other kind of safety) Also: * Something about disabling SHA1 does nasty things to GnuPG's performance, as scanning two more depth levels takes 12 minutes instead of 222 minutes for just two depth levels Regards, -Phil
signature.asc
Description: Digital signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users