Re: file size change in trustdb.gpg after recovery

[Daniel Kahn Gillmor]

On Sat 2017-02-25 07:23:39 -0500, Michal Novotny wrote:

> I have got a trustdb that gives the following output on --check-trustdb:
>
>   gpg: public key of ultimately trusted key 3ADE2987ABBFDB66 not found
>   gpg: public key of ultimately trusted key 831FE43EDDD16F3D not found
>   gpg: marginals needed: 3  completes needed: 1  trust model: pgp
>   gpg: depth: 0  valid: 6468  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 6468u
>   gpg: next trustdb check due at 2021-01-18

I don't know about the size change of the trustdb.gpg -- hopefully
someone else can weigh in on that.

But i want to point out that 6468 ulimately-trusted keys is a *very*
unusual arrangement.  any one of these keys can certify any other key
and gpg will rely on those certifications.  You should think of ultimate
ownertrust in the same way that you think of adding a new root CA to
your X.509 certificate validation stack (e.g. for your web browser).
Anyone with this capacity can pretty easily inject itself in your
communications stream by adding OpenPGP public keys ("OpenPGP
certificates") that your tools will happily believe are valid for the
identities they claim.

I'm not saying that this is *never* what anyone would want to do, but
i've never seen a use case present itself where this was what the user
actually wanted to enable > 6K parties to be able to do.

Regards,

--dkg


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: 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

real3m48.197s
user0m46.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

real0m0.003s
user0m0.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

real0m6.341s
user0m5.316s
sys 0m1.024s
gpg: Note: signatures using the MD5 algorithm are rejected
3402

real0m2.011s
user0m1.940s
sys 0m0.076s
=without-sha1=
gpg: Note: 

Re: SHA1 collision found

[Daniel Kahn Gillmor]

On Sat 2017-02-25 09:09:20 -0500, MFPA wrote:
> On Friday 24 February 2017 at 3:15:23 PM, in 
> , ved...@nym.hush.com wrote:-
>
>> Even for v3 keys, which were not SHA1 hashed, the only way to
>> generate a new key with the same fingerprint, would be to allow the
>> key size to vary (usually to a bizarre key size that would be quite
>> suspect, and not believed).
>
> Is that why the majority of keys are exactly 1024, 2048, etc. bits, or 
> is there a technical reason?

I think the reason that a majority of keys have "round" key sizes is
habit, and that the tools make it easy to generate them that way.

The size variation that vedaal describes is due to the definition of the
v3 fingerprint:

 https://tools.ietf.org/html/rfc2440#section-11.2

   The fingerprint of a V3 key is formed by hashing the body (but not
   the two-octet length) of the MPIs that form the key material (public
   modulus n, followed by exponent e) with MD5.

As a toy example, consider the case where p = 0x1411304f and q =
0x141120c5, so n = 0x0192af7bf8830ccb and e = 0x010001

These MPIs are stored in full octets, so the material hashed for the v3
fingerprint is (in hex)

01 92 af 7b f8 83 0c cb 01 00 01
   |- n ---|-- e ---|

if i want to find a key with the same v3 fingerprint, i just need to
vary the boundary between the two, for example like this:

01 92 af 7b f8 83 0c cb 01 00 01
   |- n | e |

the bytestring hashed (and therefore the fingerprint) is exactly the
same as before, but n is 8 bits shorter, and e is 8 bits longer.

now, it's probably obvious to anyone who bothers to inspect the public
key that this is not a good key -- at the very least, n is clearly not
the product of two primes ;) But RSA will still work with it.  If the
goal is to produce a key with the same fingerprint, it's trivial to do.

This is one of the reasons why the modern GnuPG suite no longer supports
these archaic keys.  it's simply not a reasonable or safe-to-use format.

The OpenPGPv4 fingerprint includes explicit sizes of the components in
the material hashed, so it doesn't have this problem.

  --dkg


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: export-minimal doesn't affect export-secret-key?

[Peter Lebbing]

On 22/02/17 23:48, Daniel Kahn Gillmor wrote:
> I just confirmed this.  I've put it in the bugtracker so it doesn't get
> lost:
> 
>https://bugs.gnupg.org/gnupg/issue2973

Thanks!

I'd like to add to the bug report that I also observe this behaviour
with GnuPG 1.4.18 on Debian jessie/stable (package 1.4.18-7+deb8u3) and
GnuPG 2.0.26 on the same (package 2.0.26-6+deb8u1). So it is not just 2.1.

However, I think I can't actually add that to the bug report myself
because I only just created an account on bugs.gnupg.org :-).

Cheers,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SHA1 collision found

[MFPA]

Hi


On Friday 24 February 2017 at 3:15:23 PM, in
, ved...@nym.hush.com
wrote:-

> Even for v3 keys, which were not SHA1 hashed, the
> only way to
> generate a new key with the same fingerprint, would
> be to allow the
> key size to vary (usually to a bizarre key size that
> would be quite suspect, and not believed).

Is that why the majority of keys are exactly 1024, 2048, etc. bits, or 
is there a technical reason?


-- 
Best regards

MFPA  

War is a matter of vital importance to the State.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

file size change after trustdb recovery

[Michal Novotny]

Hello,

I have got a trustdb that gives the following output on --check-trustdb:

  gpg: public key of ultimately trusted key 3ADE2987ABBFDB66 not found
  gpg: public key of ultimately trusted key 831FE43EDDD16F3D not found
  gpg: marginals needed: 3  completes needed: 1  trust model: pgp
  gpg: depth: 0  valid: 6468  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 6468u
  gpg: next trustdb check due at 2021-01-18

There are two public keys that are not found in public keyring (nor secret
keyring actually) but there is a record for them in the trustdb. I have a
vague idea how this could have happened, however what I would like to get
is a trustdb without the two records.

For that, I

- called gpg2 --export-ownertrust > otrust.txt
- manually removed the two records for which there is no public key
- moved current trustdb.gpg to trustdb.gpg.bak
- and finally called gpg2 --import-ownertrust < otrust.gpg

The output of --check-trustdb with the new db is now okay:

gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid: 6466  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 6466u
gpg: next trustdb check due at 2021-01-18

However what bugs me slightly is that trustdb.gpg is now of much smaller
size. Before it was: 908K, now it is 554K.

There is pretty much the same size decrease if I do not remove the records
for missing public keys and just do:

- called gpg2 --export-ownertrust > otrust.txt
- move current trustdb.gpg to trustdb.gpg.bak
- and finally call gpg2 --import-ownertrust < otrust.gpg.

The output of --check-trustdb is now:

gpg: public key of ultimately trusted key 3ADE2987ABBFDB66 not found
gpg: public key of ultimately trusted key 831FE43EDDD16F3D not found
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid: 6468  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 6468u
gpg: next trustdb check due at 2021-01-18

Again, the new trustdb.gpg has 554K, while the original had 908K. And also
what is curious is that the new file had 301K before calling
--check-trustdb and 554K after.

Anyway, it seems the original trustdb is not fully restored after
--export-ownertrust and --import-ownertrust even though the output of
--check-trustdb gives the same output for the original and new file (6468
valid ultimately trusted keys).

I know this is a bit complicated description but could anyone explain
what's going on with the changes in the trustdb.gpg file size?

Thank you
Michal Novotny
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: file size change after trustdb recovery

[Michal Novotny]

Where I mentioned "otrust.gpg" in the description, that should have been
otrust.txt. I am very sorry for that.

Michal Novotny

On Sat, Feb 25, 2017 at 1:14 PM, Michal Novotny  wrote:

> Hello,
>
> I have got a trustdb that gives the following output on --check-trustdb:
>
>   gpg: public key of ultimately trusted key 3ADE2987ABBFDB66 not found
>   gpg: public key of ultimately trusted key 831FE43EDDD16F3D not found
>   gpg: marginals needed: 3  completes needed: 1  trust model: pgp
>   gpg: depth: 0  valid: 6468  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 6468u
>   gpg: next trustdb check due at 2021-01-18
>
> There are two public keys that are not found in public keyring (nor secret
> keyring actually) but there is a record for them in the trustdb. I have a
> vague idea how this could have happened, however what I would like to get
> is a trustdb without the two records.
>
> For that, I
>
> - called gpg2 --export-ownertrust > otrust.txt
> - manually removed the two records for which there is no public key
> - moved current trustdb.gpg to trustdb.gpg.bak
> - and finally called gpg2 --import-ownertrust < otrust.gpg
>
> The output of --check-trustdb with the new db is now okay:
>
> gpg: marginals needed: 3  completes needed: 1  trust model: pgp
> gpg: depth: 0  valid: 6466  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 6466u
> gpg: next trustdb check due at 2021-01-18
>
> However what bugs me slightly is that trustdb.gpg is now of much smaller
> size. Before it was: 908K, now it is 554K.
>
> There is pretty much the same size decrease if I do not remove the records
> for missing public keys and just do:
>
> - called gpg2 --export-ownertrust > otrust.txt
> - move current trustdb.gpg to trustdb.gpg.bak
> - and finally call gpg2 --import-ownertrust < otrust.gpg.
>
> The output of --check-trustdb is now:
>
> gpg: public key of ultimately trusted key 3ADE2987ABBFDB66 not found
> gpg: public key of ultimately trusted key 831FE43EDDD16F3D not found
> gpg: marginals needed: 3  completes needed: 1  trust model: pgp
> gpg: depth: 0  valid: 6468  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 6468u
> gpg: next trustdb check due at 2021-01-18
>
> Again, the new trustdb.gpg has 554K, while the original had 908K. And also
> what is curious is that the new file had 301K before calling
> --check-trustdb and 554K after.
>
> Anyway, it seems the original trustdb is not fully restored after
> --export-ownertrust and --import-ownertrust even though the output of
> --check-trustdb gives the same output for the original and new file (6468
> valid ultimately trusted keys).
>
> I know this is a bit complicated description but could anyone explain
> what's going on with the changes in the trustdb.gpg file size?
>
> Thank you
> Michal Novotny
>
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

file size change in trustdb.gpg after recovery

[Michal Novotny]

Hello,

I have got a trustdb that gives the following output on --check-trustdb:

  gpg: public key of ultimately trusted key 3ADE2987ABBFDB66 not found
  gpg: public key of ultimately trusted key 831FE43EDDD16F3D not found
  gpg: marginals needed: 3  completes needed: 1  trust model: pgp
  gpg: depth: 0  valid: 6468  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 6468u
  gpg: next trustdb check due at 2021-01-18

There are two public keys that are not found in public keyring (nor secret
keyring actually) but there is a record for them in the trustdb. I have a
vague idea how this could have happened, however what I would like to get
is a trustdb without the two records.

For that, I

- called gpg2 --export-ownertrust > otrust.txt
- manually removed the two records in otrust.txt for which there is no
public key
- moved current trustdb.gpg to trustdb.gpg.bak
- and finally called gpg2 --import-ownertrust < otrust.txt

The output of --check-trustdb with the new db is now okay:

gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid: 6466  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 6466u
gpg: next trustdb check due at 2021-01-18

However what bugs me slightly is that trustdb.gpg is now of much smaller
size. Before it was: 908K, now it is 554K.

There is pretty much the same size decrease if I do not remove the records
for missing public keys and just do:

- called gpg2 --export-ownertrust > otrust.txt
- move current trustdb.gpg to trustdb.gpg.bak
- and finally call gpg2 --import-ownertrust < otrust.txt

The output of --check-trustdb is now:

gpg: public key of ultimately trusted key 3ADE2987ABBFDB66 not found
gpg: public key of ultimately trusted key 831FE43EDDD16F3D not found
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid: 6468  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 6468u
gpg: next trustdb check due at 2021-01-18

Again, the new trustdb.gpg has 554K, while the original had 908K. And also
what is curious is that the new file had 301K before calling
--check-trustdb and 554K after.

Anyway, it seems the original trustdb is not fully restored after
--export-ownertrust and --import-ownertrust even though the output of
--check-trustdb gives the same output for the original and new file (6468
valid ultimately trusted keys).

I know this is a bit complicated description but could anyone explain
what's going on with the changes in the trustdb.gpg file size?

Thank you
Michal Novotny
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users