Re: SHA1 collision found

[Matthias Apitz]

On Saturday, 25 November 2017 14:24:29 CET, Jerry  
wrote:

On Fri, 24 Nov 2017 00:10:44 -0800, Brent Small stated:

What’s up 


up

ADVERB

...


Maybe the OP wanted to sent this to What's Ape.

matthias




--
Sent from my Ubuntu phone
http://www.unixarea.de/

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

Re: SHA1 collision found

[Jerry]

On Fri, 24 Nov 2017 00:10:44 -0800, Brent Small stated:

>What’s up 

up

ADVERB

toward the sky or a higher position:
"he jumped up" · [more]

synonyms: up · higher · uphill · upslope · to the top · skyward ·
heavenward to the place where someone is:
"Dot didn't hear Mrs. Parvis come creeping up behind her"

at or to a higher level of intensity, volume, or activity:
"she turned the volume up" · [more]

into the desired or a proper condition:
"the mayor agreed to set up a committee"

PREPOSITION

from a lower to a higher point on (something); upward along:
"she climbed up a flight of steps"

ADJECTIVE

directed or moving toward a higher place or position:
"the up escalator"

in a cheerful mood; ebullient:
"the mood here is resolutely up"

(of a computer system or industrial process) functioning properly:
"the system is now up"

at an end:
"his contract was up in three weeks" · [more]

NOUN

a period of good fortune:
"you can't have ups all the time in football"

VERB

do something abruptly or boldly:
"she upped and left him"

cause (a level or amount) to be increased:
"capacity will be upped by 70 percent next year"

lift (something) up:
"everybody was cheering and upping their glasses"

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

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

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: 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: SHA1 collision found

[Christoph Anton Mitterer]

On Thu, 2017-02-23 at 13:58 -0500, Robert J. Hansen wrote:
> > "Migrating to SHA256"
> section in
> the FAQ?

What I always kinda wonder is, why crypto or security experts, at least
in some sense never seem to learn.
When MD5 got it's first scratches, some people started to demanded for
it's ASAP retirement (which didn't happen... partially also with
arguments that it's not yet broken for these and that purposes in
practise)... in the end people waited so long until it was in a way
already too late.
Remember the forged MD5 based X509 cert? And this was made by some
"good guys" god know how many actual attacks may have been driven by
much stronger organisations where people actually were harmed in the
end.

SHA1 may have been phased out (more or less) in the X.509 world, but
it's still pretty present in many other places.
It's known to having issues for some years and for the same number of
years many experts still defended it as not being broken for these and
that use cases...
And now were again in the situation that it's still used in production
(probably for years to come), and we have at least a collision.
That may not be the one big fire alert where everything burns down...
but it should be really a ringing bell...


Now every time when new algos come up or e.g. when ideas for the next
OpenPGP version is started,.. a big bunch of experts seem to go for the
most conservative way possible. And I'm not talking about the good
conservatism (i.e. using algos based on long standing and well
understood math)... but rather things like let's better not use SHA512
or SHA3 when we could also just use SHA256... let's better not specify
large curves when we can go by a much smaller one.

And every time the same argument is brought up, that these would be
still way enough to take hundreds of years to be cracked... but so far
(as with SHA1) it was always broken much earlier.


The last time when I followed discussion about the next OpenPGP it
seemed people rather wanted to hard-wire only a few algos for
everything, which would be just the same problem as with SHA1,...
instead all algos should be pretty easily exchangeable.
So when the same happens for the next OpenPGP version just with SHA256
I'll bet that we face the same problems with SHA256 far earlier than
everyone wishes.


Not to talk about the more and more realistic threat posed by quantum
computers.


IMO we should rather go for the stronger algos, or even combine algos
when this makes sense because their underlying math is different that
breaking one would still not directly affect the other.
And we should rather make any crypto algo as easily exchangeable as
possible.


Cheers,
Chris.

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

Re: SHA1 collision found

[sivmu]

Am 23.02.2017 um 20:09 schrieb ved...@nym.hush.com:
> The Openpgp standards group is working on this.

Yes but who know how many years it will take until a new standard is accepted...

>
> The link you give for the collision used 2 PDF's.
> Using a PDF is sort-of 'cheating', and does not extrapolate to being
> 'completely broken'.
>
> Assuming that it is possible to find a pre-image collision, i.e:
>
> [1] m1.txt 1 has an SHA1 hash of H1
> [2] m2.txt will now have the same SHA1 hash H1
>
> What will happen to in order to generate m2.txt  is that there will be
> many trials of a gibberrish string added to the plaintext of m2.txt
> until one is found that has the same SHA1 hash as m1.txt
> BUT
> This will be quite visible in the plaintext of m2.txt, and won't fool
> anyone.
>
> With a PDF, the 'extra gibberish string' is 'hidden'. It is not in the
> actual PDF the receiver reads, only in the meta-data, the appended PDF
> 'Suffix'.

Not sure about you but I am not able to see the difference between a valid pgp 
key and "gibberish" ;)


>
> While this is *do-able* and a good reason to move on to a future
> SHA256 hash, it would not be transferable (at this time, based on the
> PDF collision data), to find a fingerprint collision for any v4 key.
> vedaal
The question is how many tries it takes until a colliding key is found that is 
accepted by common pgp implementations when imported, is it not?


As said, if it is as easy as i think it is, providing an option for different 
hash algos to generate fingerprints would be a nice solution until a new 
standard is established.

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

Re: SHA1 collision found

[vedaal]

On 2/23/2017 at 1:27 PM, si...@web.de wrote:Today was announced that
SHA1 is now completely broken
https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html

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

=

The Openpgp standards group is working on this.

The link you give for the collision used 2 PDF's.
Using a PDF is sort-of 'cheating', and does not extrapolate to being
'completely broken'.

Assuming that it is possible to find a pre-image collision, i.e:

[1] m1.txt 1 has an SHA1 hash of H1
[2] m2.txt will now have the same SHA1 hash H1

What will happen to in order to generate m2.txt  is that there will be
many trials of a gibberrish string added to the plaintext of m2.txt
until one is found that has the same SHA1 hash as m1.txt
BUT
This will be quite visible in the plaintext of m2.txt, and won't fool
anyone.

With a PDF, the 'extra gibberish string' is 'hidden'. It is not in the
actual PDF the receiver reads, only in the meta-data, the appended PDF
'Suffix'.

While this is *do-able* and a good reason to move on to a future
SHA256 hash, it would not be transferable (at this time, based on the
PDF collision data), to find a fingerprint collision for any v4 key.
vedaal
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

RE: SHA1 collision found

[Robert J. Hansen]

(I originally sent this off-list by mistake.  Peter was kind enough to respond 
off-list and to suggest we take it back on-list.  This email is a distillation 
of three different emails: my original, Peter's response, and a response to 
Peter.)

=

> I already answered that here[1]. The use of SHA-1 in fingerprints is 
> not susceptible to a collision attack, so it's still safe. SHA-1 in 
> fingerprints is only susceptible to a second-preimage attack which is 
> much harder than a collision attack and unheard of for SHA-1.

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

Now, you could establish proof some other way: let's say you made a videotape 
of the defendant signing the document.  If you could introduce other supporting 
evidence (which might include other signatures on keys) you might be able to 
convince the judge the signature is enforceable.  But there's nothing intrinsic 
to the signature itself which could convince the judge.

So Peter is completely right to say "but there's no reason to believe one 
person over the other."  Completely, absolutely right.  But the person asking 
the court to enforce a contract must present a reason to believe them over the 
defendant.

I hope this clarifies my answer!

(Peter also rightly remarked that he thought nonrepudiability in OpenPGP was 
kind of iffy anyway.  He and I are in complete agreement on this.  OpenPGP has 
always had very iffy nonrepudiability.  With this SHA-1 attack, I feel the 
threshold has been crossed and we need to consider it repudiable.)



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

RE: SHA1 collision found

[Robert J. Hansen]

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

SHA-1 is broken *for some purposes*.  That's scary enough, trust me.  Let's
not overstate things.

For the last ten years I've been saying, "The smoke alarm has gone off and
we think there's a fire.  There's no danger to anyone right now, but we need
to move to the exits in an orderly fashion.  Start migrating away from SHA-1
right now, so that when the collisions happen you've already been using
SHA256 for years."

Today we've seen the fire.  It's not surprising.  We knew this was coming,
we just didn't know when.  If you're still using SHA-1, you probably need to
begin migrating *right now* before the fire gets worse.  If you don't know
how, ask on this list and we'll help you.  But don't panic: we can help.

A question for the list: should we put a "Migrating to SHA256" section in
the FAQ?



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

Re: SHA1 collision found

[Peter Lebbing]

On 23/02/17 19:24, si...@web.de wrote:
> 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.

I already answered that here[1]. The use of SHA-1 in fingerprints is not
susceptible to a collision attack, so it's still safe. SHA-1 in
fingerprints is only susceptible to a second-preimage attack which is
much harder than a collision attack and unheard of for SHA-1.

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

It wouldn't help because of all the places SHA-1 is used internally if
you just change how it is displayed to the user. Disclaimer: I'm not a
developer, but this is my understanding of it. I can't say for sure.

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 



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

SHA1 collision found

[sivmu]

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

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