[193885] in North American Network Operators' Group
Re: SHA1 collisions proven possisble
daemon@ATHENA.MIT.EDU (James DeVincentis via NANOG)
Wed Mar 1 23:57:13 2017
X-Original-To: nanog@nanog.org
Date: Wed, 1 Mar 2017 22:57:06 -0600
In-Reply-To: <20170302034912.GN7463@hezmatt.org>
To: Matt Palmer <mpalmer@hezmatt.org>
From: James DeVincentis via NANOG <nanog@nanog.org>
Reply-To: James DeVincentis <james.d@hexhost.net>
Cc: nanog@nanog.org
Errors-To: nanog-bounces@nanog.org
Let me add some context to the discussion.
I run threat and vulnerability management for a large financial =
institution. This attack falls under our realm. We=E2=80=99ve had a plan =
in progress for several years to migrate away from SHA-1. We=E2=80=99ve =
been carefully watching the progression of the weakening of SHA-1 as =
computing power has increased and access to large-scale computing has =
become standard over the last 5 years. This does nothing to change our =
timeline.=20
The attack does nothing to prove anything we already didn=E2=80=99t =
know. As computing power increases we must change hashing mechanisms =
every few years. This is why this is no surprise to us in the security =
sphere. However the presentation of this particular information has been =
following a very troublesome trend we=E2=80=99ve been seeing in the =
security sphere. Naming a vulnerability something silly but easily =
rememberable by management types. =E2=80=98HeartBleed=E2=80=99, =
=E2=80=98Shattered=E2=80=99, =E2=80=98CloudBleed=E2=80=99, =
=E2=80=98SomethingBleed=E2=80=99=E2=80=A6 This is a publicity stunt by =
Google to whip up a hype and it worked. Case in point, are some of the =
posts in this thread that completely dismiss fact for assumption and =
embellishment.=20
With specific regard to SSL certificates: "Are TLS/SSL certificates at =
risk? Any Certification Authority abiding by the CA/Browser Forum =
regulations is not allowed to issue SHA-1 certificates anymore. =
Furthermore, it is required that certificate authorities insert at least =
64 bits of randomness inside the serial number field. If properly =
implemented this helps preventing a practical exploitation.=E2=80=9D =
(https://shattered.it/ <https://shattered.it/>). It seems not all of the =
news outlets read the entire page before typing up a sensationalist post =
claiming all your data is at risk suddenly.
Here=E2=80=99s why this is sensationalist. If anyone with *actual* =
hands-on work in the *security* sphere in *recent* years disagrees, =
I=E2=80=99ll be happy to discuss.=20
- Hardened SHA1 exists to prevent this exact type of attack.=20
- Every hash function will eventually have collisions. It=E2=80=99s =
literally impossible to create a hashing function that will never have a =
collision. There are an infinite number of inputs that can go into a =
hash function. There are a finite number of outputs of a hash function. =
Hash functions create an implausibility of a collision. That=E2=80=99s =
it. There is no 100% certainty that any hash function will not have =
collisions.
- Google created a weak example. The difference in the document they =
generated was a background color. They didn=E2=80=99t even go a full =
RGBA difference. They went from Red to Blue. That=E2=80=99s a difference =
of 4 bytes (R and B values). It took them nine quintillion computations =
to generate the correct spurious data to create a collision when they =
controlled both the documents with a 4 byte difference. That spurious =
data inflated the PDF by at least a few hundred KB. Imagine the =
computations it would take for the examples they give? Anyone know? No. =
They didn=E2=80=99t dare attempt it because they knew it=E2=80=99s not =
possible. =20
- This wasn=E2=80=99t even an attack on a cryptographic method that =
utilizes SHA1. This was a unique identifier / integrity attack. =
Comparing an SHA1 hash is not the correct way to verify authenticity of =
a document. Comparing an SHA1 how you verify integrity of a document, =
looking for corruption. Authenticity is derived from having the data =
signed from a trusted source or encrypted using say PGP from a trusted =
source.
- And last but not least.. which takes all of the bite out of the =
attack. Google also showed it was easily detectable. Is a weakness or =
attack on a hash function really viable of it=E2=80=99s easily and =
readily detectable? No. It=E2=80=99s not. (See: IDS, WAFs: They filter =
and detect attacks against systems that may be vulnerable and prevent =
them by checking for the attacks). So If I see a hash collision? I=E2=80=99=
ll modify the algorithm=E2=80=A6 Wait.. This sounds awfully familiar.. =
Oh yea=E2=80=A6 Hardened SHA1.
With all of these reasons all wrapped up. It clearly shows the level of =
hype around this attack is the result of sensationalist articles and =
clickbait titles.
It also appears the majority of those who embrace fact also abandoned =
this thread fairly early once it began to devolve into embracing =
sensationalism. I=E2=80=99m going to join them.=20
*micdrop* *unsubscribe*
> On Mar 1, 2017, at 9:49 PM, Matt Palmer <mpalmer@hezmatt.org> wrote:
>=20
> On Thu, Mar 02, 2017 at 03:42:12AM +0000, Nick Hilliard wrote:
>> James DeVincentis via NANOG wrote:
>>> On top of that, the calculations they did were for a stupidly simple
>>> document modification in a type of document where hiding extraneous
>>> data is easy. This will get exponentially computationally more
>>> expensive the more data you want to mask. It took nine quintillion
>>> computations in order to mask a background color change in a PDF.
>>>=20
>>> And again, the main counter-point is being missed. Both the good and
>>> bad documents have to be brute forced which largely defeats the
>>> purpose. Tthose numbers of computing hours are a brute force. It may
>>> be a simplified brute force, but still a brute force.
>>>=20
>>> The hype being generated is causing management at many places to cry
>>> exactly what Google wanted, =E2=80=9CWolf! Wolf!=E2=80=9D.
>>=20
>> The Reaction state table described in
>> https://valerieaurora.org/hash.html appears to be entertainingly =
accurate.
>=20
> With particular reference to the "slashdotter" column.
>=20
> - Matt
>=20