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


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

Re: SHA1 collision found

[Glenn Rempe]

If you read the announcement Google never uses the words "completely broken" 
that you attribute to them. I believe that was someone else's characterization.

Mis-attribution and name calling can also be unhelpful.

Google's security team has been the driving force behind two major security 
issues this week alone (SHA1 and Cloudflare) and with SHA1 they made concrete 
something that was only theoretical before. Let's give credit where credit is 
due.

On Feb 24, 2017, 09:27 -0800, Melvin Carvalho , wrote:
>
>
> On 23 February 2017 at 19:24,  wrote:
> > Today was announced that SHA1 is now completely broken
> > https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html
>
> This is nonsense.
>
> Google security team calling sha1 "completely broken" simply means google's 
> security team is completely broken.
>
> Fearmongering like this unhelpful to the open source community.___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SHA1 collision found

[Melvin Carvalho]

On 23 February 2017 at 19:24,  wrote:

> Today was announced that SHA1 is now completely broken
> https://security.googleblog.com/2017/02/announcing-first-
> sha1-collision.html


This is nonsense.

Google security team calling sha1 "completely broken" simply means google's
security team is completely broken.

Fearmongering like this unhelpful to the open source community.

GPG is sound because you can only find a collision which is no big deal and
we knew already, but you cannot compromise a hash.

This simply wastes everyone's time.


>
>
> A few weeks back it was mentioned that there is a new proposal for a
> openpgp standart including a new algorithm for pgp fingerprints.
> As this is currently not applicable in practice, I would like to know what
> this new development means for pgp-gnupg and the use of SHA1 for key
> identification.
>
> After researching how the fingerprint is generated, I think it would be
> easy to include a new option in gnupg to print a fingerprint using sha256.
> Would that be something that will/can be included in future versions of
> gnupg?
>
> That way users could publish both the sha1 and sha256 finderprint in the
> future.
>
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Announcing paperbackup.py to backup keys as QR codes on paper

[Peter Lebbing]

On 23/02/17 13:36, Gerd v. Egidy wrote:
> So I think that this would move the bar for a possible user of paperbackup.py 
> higher than I want to.

Yes, it should be easy to use. In fact, I've sometimes heard the 
complaint that "paperkey is not easy to install and/or use". That's 
really too bad that those people feel that way.

> Ideally it is a tool or combination of tools already deployed widely, like 
> sed 
> and sort I used in paperrestore. This would make the checksums still usable 
> even when the source to paperbackup.py isn't available anymore.

It took me some fiddling... but using CRC RevEng[1] I got a checksum in 
Python that is compatible to POSIX cksum.

The following Python:

>>> from posixcksum import PosixCkSum
>>> from base64 import b64encode
>>> crc, _ = PosixCkSum.sum_whole(bytearray(b'123456789'))
>>> b64encode(crc.to_bytes(4,byteorder='big'))[:4]
b'N3pg'

generates the same checksums as the following Bash code:

$ printf $(printf '%08x' $(echo -n 123456789 | cksum | cut -d' ' -f1) | sed 
's/../\\x\0/g')|base64|cut -b-4
N3pg

This is done with the attached Python code. It is written for 
compactness rather than speed. Just re-implementing the crc function 
would probably be quicker.

HTH,

Peter.

[1] 
-- 
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 
#!/usr/bin/python3

# Copyright (c) 2017 Peter Lebbing 
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions are met:
#
# 1. Redistributions of source code must retain the above copyright notice,
# this list of conditions and the following disclaimer.
#
# 2. Redistributions in binary form must reproduce the above copyright notice,
# this list of conditions and the following disclaimer in the documentation
# and/or other materials provided with the distribution.
#
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
# POSSIBILITY OF SUCH DAMAGE.

import binascii

class PosixCkSum(object):


"""Create a POSIX cksum-compliant checksum."""


def __init__(self):
"""Create new checksumming instance."""
self.n = 0
self.crc = 0x

def sum(self, bs):
"""Checksum another part of data.

IMPORTANT: the data in bs is DESTROYED.

"""
self.bit_reverse(bs)
self.crc = binascii.crc32(bs, self.crc)
self.n += len(bs)

def finish(self):
"""Finish checksum computation and return result.

After this, the object should no longer be used.

"""
if not self.n:
return self.crc, self.n
bs = bytearray(self.n.to_bytes((self.n.bit_length() + 7) // 8,
   byteorder='little'))
self.bit_reverse(bs)
self.crc = binascii.crc32(bs, self.crc)
crcb = bytearray(self.crc.to_bytes(4, byteorder='little'))
self.bit_reverse(crcb)
crc = int.from_bytes(crcb, byteorder='big')
return crc, self.n

@classmethod
def sum_whole(cls, bs):
"""Checksum a single piece of data.

IMPORTANT: the data in bs is DESTROYED.

"""
c = cls()
c.sum(bs)
return c.finish()

@staticmethod
def bit_reverse(bs):
"""Reverse the bits in every byte of the argument in-place"""
for i,b in enumerate(bs):
r = 0
t = 0x80
s = 0x01
while t:
if (b & t):
r |= s
t >>= 1;
s <<= 1;
bs[i] = r

if __name__ == '__main__':
# Checksum all files passed as arguments, or stdin if none
from sys import argv,stdin
if len(argv) == 1:
bs = bytearray(stdin.buffer.read())
crc, n = PosixCkSum.sum_whole(bs)
print(crc, n)
else:
for fn in argv[1:]:
if fn == '-':
bs = bytearray(stdin.buffer.read())
else:
with open(fn, 'rb') as f:
bs = bytearray(f.read())
crc, n = 

Re: SHA1 collision found

[vedaal]

On 2/23/2017 at 4:52 PM, si...@web.de wrote:...
Not sure about you but I am not able to see the difference between a
valid pgp key and "gibberish" ;)
...

=

In the example of the 2 pdf's,  they started with one pdf, made
another pdf, then multiple (more than billions) trials of adding a
string to the second pdf so that it hashes to the first.

With regard to generating a new key that hashes to a known specific
key, the forger must do 2 things simultaneously;

[1] generating new key material
[2] seeing that the hashed fingerprint of the new key matches that of
the first key

The forger does not start with a newly generated key and add material
so that the hash would match the first key (the case of the pdf's).
If that were the case, then the key system would be broken now for the
SHA1 hash.

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

Now, for a V4 key with an SHA1 hash, and a further restriction that
the forged key size be the same as the first key, this is not known to
be doable day, even with the google cloud computer sharing efforts,
and the breakthrough of finding pdf's with the same hash.

Again, I fully support moving to a secure hash, but I do think that
users have more than enough time until the open-pgp group issues the
official standard.
vedaal
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SHA1 collision found

[Ingo Klöcker]

On Thursday 23 February 2017 23:38:36 Leo Gaspard wrote:
> On 02/23/2017 09:00 PM, Robert J. Hansen wrote:
> > [...]
> > 
> > To which I said, "Create two keys with the same fingerprint.  Sign a
> > contract with one, then renege on the deal.  When you get called
> > into court, say "I never signed that, Your Honor!" and present the
> > second key.  This collision pretty much shatters the
> > nonrepudiability of SHA-1 signatures."
> > 
> > To which Peter quite reasonably answered that the other person has a
> > copy of the public key which was used to sign the document
> > originally.  Why should the fraudster's denial be believed?
> > 
> > The answer is that to enforce a contract (at least here in the
> > United States) you must be able to prove, based on a preponderance
> > of the evidence, that the other person entered into a contract with
> > you.  So imagine this conversation:
> > 
> > PLAINTIFF: "Your Honor, the defendant reneged on a $10,000 contract.
> >  Make him pay up." DEFENDANT: "I never signed anything, Your
> > Honor."
> > PLAINTIFF: "I have his key, it's right here."
> > DEFENDANT: "That's not my key.  This is my key."
> > PLAINTIFF: "Of course that's what he claims!  They have the same
> > SHA-1 fingerprint!  He did that in order to deny his signature!"
> > JUDGE: "So these keys are uniquely identified by the fingerprint?"
> > (both parties agree)
> > JUDGE: "And you have two keys that are identified by the same
> > fingerprint?" (both parties agree)
> > JUDGE: "And there's no way to tell which key is real?"
> > (both parties agree)
> > JUDGE: "Then we're stuck.  There's no reason to prefer one key over
> > another.  Plaintiff, you have failed your burden of proof in
> > establishing the defendant signed the contract."
> I'd like to respectfully disagree on this point. SHA1 is currently
> vulnerable only to collision attacks, which means that in order to
> have two keys with the same fingerprint they both have to be created
> by the same person (up to a random collision). Thus the defendant.
> And this is enough to prove that he did sign the contract with the
> key he claims he doesn't own.
> 
> Is there any flaw in this logic?

The second key the defendant created won't have his name as user id. 
Moreover, after creating this second key he will have disposed of the 
private key (and after uploading the public key to a keyserver probably 
also of the public key), so that there's no proof that he was ever in 
possession of this key.


Regards,
Ingo


signature.asc
Description: This is a digitally signed message part.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Announcing paperbackup.py to backup keys as QR codes on paper

[Peter Lebbing]

On 23/02/17 11:00, Gerd v. Egidy wrote:
> Seems you are trusted by much more people than me ;)

More people trust that that key is mine, they don't trust me as a
person, my actions or my certifications. dkg already answered that bit
:-). These are mostly people I've met at a keysigning party. They have
seen my passport and asserted that "Peter Lebbing" is as far as they can
tell indeed the person in possession of that key. They don't trust me
more than the next guy, because they don't know me personally.

> If we are talking centuries, I'd worry about the availability of gnupg as 
> much 
> as qrcodes.

If there is still software that can work with OpenPGP v4 keys, then you
can restore your private key from your paperkey-style backup. If there
is no more software that can work with OpenPGP v4 keys, what are you
going to do with your restored private key? Frame it and put it on the
wall? ;-)

> Not all decoders are capable of it, and if one qrcode is missing, the linking 
> is broken and you have to patch the decoder to still get some data.

Understood. Good to see you've thought it through.

> I used the largest error correction ratio possible.

Given the size of those QR codes on paper, you could use a camera that
is so elderly it has developed presbyopia and cataract and still scan
them succesfully! :-D

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