Real-world current impact of disabling SHA1

[Daniel Kahn Gillmor]

On Fri 2017-02-24 12:37:34 -0500, Phil Pennock wrote:
> There are various claims going around about how GnuPG should be
> disabling SHA1 now;

 [ ... ]

To be fair, we should have been *deprecating* SHA1 many years ago (since
Wang et al in 2005).  we're late.  if we'd been deprecating it for years
it would be easier to consider disabling it now.

> This email is to summarize the current practical reality of trying
> to move away;

Thanks for doing this, it's good to have concrete datapoints.

fwiw, i ran with --weak-digest SHA1 for several months back when we
introduced --weak-digest to see how it would work for me.  It turned out
to be a rough user experience, because there were enough tools out there
that were still generating things with SHA1 :/

I just ran some similar tests myself with GnuPG 2.1.18 (libgcrypt
1.7.6-beta) on a keyring with 3402 OpenPGP certificates.  In
preparation, i did the following in an empty directory on a tmpfs (if
everything is RAM-backed i don't have to worry that i'm confounding
measurements with with disk I/O performance):

    gpg --export > keys-to-import.txt
    gpg --export-ownertrust > ownertrust.txt
    mkdir -m 0700 normal without-sha1
    echo weak-digest SHA1 > without-sha1/gpg.conf

Then i ran my comparison tests, like so:

    for GNUPGHOME in normal without-sha1; do
      export GNUPGHOME
      printf "=====%s=====\n" "$GNUPGHOME"
      time gpg --quiet --batch --import < keys-to-import.gpg
      time gpg --quiet --batch  --import-ownertrust < ownertrust.txt
      time gpg --batch --check-trustdb
      time gpg --with-colons --list-keys | grep -c ^pub:
    done

Full output is at the end of this e-mail.

Phil wrote:

>  * 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)

A little more than half of the certificates in my test keyring had no
self-sigs with anything other than SHA1.  Since GnuPG discards certs
with no valid self-sig at import time, the without-sha1 keyring is
significantly smaller.

Still, i went from 123 valid certificates to 89 valid certificates when
i dropped SHA1.

I suspect that the self-sig issue is the main concern -- *not* links
between keys.  People can fix their self-sigs just by re-signing their
own keys.

it's also possible that debian developers are disproportionately
overrepresented in my keyring, and this is a group of folks who have
been actively migrating away from SHA1 already, which would explain why
my results aren't quite as terrible as Phil's are.

>  * 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

For m, the timing for each stage of the test is comparable for what we'd
expect, given the sizes of the different keyrings -- so the timing is
significantly faster for the SHA1-less keyring, not the other way
around.  i don't see any evidence that the workflow i used shows any
performance degradation when used with --weak-digest sha1.

The difference between my test and Phil's test is that i've done a clean
import, so the keyring i'm working with is already pruned. i wonder if
the performance penalty comes from gpg discovering keys that it
considers invalid already in the keyring.

If so, it'd be nice to find a way to fix this performance problem.  At
the very least, 

Regards,

        --dkg

Here's the results from my own tests:

----------------------------------------
=====normal=====
gpg: Note: signatures using the MD5 algorithm are rejected

real	3m48.197s
user	0m46.316s
sys	3m0.476s
gpg: inserting ownertrust of 128
gpg: inserting ownertrust of 3
gpg: inserting ownertrust of 6
gpg: inserting ownertrust of 128
gpg: inserting ownertrust of 128
gpg: inserting ownertrust of 128
gpg: inserting ownertrust of 3
gpg: inserting ownertrust of 3
gpg: inserting ownertrust of 128
gpg: inserting ownertrust of 3
gpg: inserting ownertrust of 2

real	0m0.003s
user	0m0.000s
sys	0m0.004s
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: Note: signatures using the MD5 algorithm are rejected
gpg: depth: 0  valid:   1  signed: 123  trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: depth: 1  valid: 123  signed: 577  trust: 122-, 0q, 1n, 0m, 0f, 0u
gpg: next trustdb check due at 2017-03-07

real	0m6.341s
user	0m5.316s
sys	0m1.024s
gpg: Note: signatures using the MD5 algorithm are rejected
3402

real	0m2.011s
user	0m1.940s
sys	0m0.076s
=====without-sha1=====
gpg: Note: signatures using the SHA1 algorithm are rejected
gpg: key 4E3E63D49A17C533: no valid user IDs
[ …hundreds more "no valid user IDs"… ]
gpg: Note: signatures using the MD5 algorithm are rejected
[ …hundreds more "no valid user IDs"… ]

real	0m53.606s
user	0m13.460s
sys	0m39.004s
gpg: inserting ownertrust of 128
gpg: inserting ownertrust of 3
gpg: inserting ownertrust of 6
gpg: inserting ownertrust of 128
gpg: inserting ownertrust of 128
gpg: inserting ownertrust of 128
gpg: inserting ownertrust of 3
gpg: inserting ownertrust of 3
gpg: inserting ownertrust of 128
gpg: inserting ownertrust of 3
gpg: inserting ownertrust of 2

real	0m0.006s
user	0m0.004s
sys	0m0.000s
gpg: Note: signatures using the SHA1 algorithm are rejected
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid:   1  signed:  89  trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: depth: 1  valid:  89  signed: 320  trust: 88-, 0q, 1n, 0m, 0f, 0u
gpg: next trustdb check due at 2017-03-12

real	0m2.496s
user	0m2.200s
sys	0m0.292s
gpg: Note: signatures using the SHA1 algorithm are rejected
1399

real	0m0.816s
user	0m0.764s
sys	0m0.052s
----------------------------------------



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: </pipermail/attachments/20170225/479a159e/attachment-0001.sig>