Real-world current impact of disabling SHA1

[Phil Pennock]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 996 bytes
Desc: Digital signature
URL: </pipermail/attachments/20170224/6740023d/attachment.sig>