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
----------------------------------------
signature.asc
Description: PGP signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
