[ art / civ / cult / cyb / diy / drg / feels / layer / lit / λ / q / r / sci / sec / tech / w / zzz ] archive provided by lainchan.jp

lainchan archive - /sec/ - 4370



File: 1487864511683.png (180.17 KB, 300x163, Collision-illustrated.png)

No.4370

  No.4371

>>4370
sha1 has been known to be unsuitable for cryptographic practices for a long time

  No.4372

>>4371
In theory. Now it seems practical. And this affects GPG signing and Git.

I checked several signed messages I have, and they use SHA1. It also looks complicated to switch Git to sha256 and keep backward compatibility.

From the other hand article says what some preconditions are needed and then you can calculate collision in one year with 110 GPU. Looks unfeasible for me (especially if you want to push backdoor to vichan git repo).

  No.4373

>>4372
Just add:
personal-cipher-preferences AES256 TWOFISH AES192 AES
personal-digest-preferences SHA256
personal-compress-preferences ZLIB BZIP2 ZIP
cert-digest-algo SHA256
to the end of ~/.gnupg/gpg.conf if you're using GnuPG.

  No.4374

File: 1487871622010.png (71.05 KB, 200x97, 2017-02-23-183457_844x408_scrot.png)

>>4370
>Is this really that bad?

Hard to say. As >>4372 mentioned, the technique only works on specially crafted files. Specifically, they found a collision for two files that can be written as

P || M11 || M12 || S
P || M21 || M22 || S

For a given prefix P (see pic for the one they used) and arbitrary S. The work spent is on finding the M's.

That said, this approach is basically the same that was used to create two certificates whose MD5 hashes collide back in 2007 (I think).

And finally, it is worth remembering that this is a collision attack, which means the attacker is the one crafting both messages (ruling out the possibility that someone can e.g., replace a signed message you wrote).

  No.4375

>>4373
Mine was configured to use sha512 a long time ago. I'm talking about others who just install gpg and use defaults. Like this >>>/r/28747

>>4374
> ruling out the possibility that someone can e.g., replace a signed message you wrote
So this is just a loud signal what we really need to drop SHA1 in near future and not what we must drop it today.

  No.4376

File: 1487875706442.png (153.34 KB, 200x101, pdf_format.png)

>>4374
>That said, this approach is basically the same that was used to create two certificates whose MD5 hashes collide back in 2007 (I think).

The 2007 Attack (RogueCA, Alexander Sotirov, Marc Stevens, et. all) used H(P || M_1 || S) = H(P' || M_1 || S), but before in 2005 Arjen Lenstra, Benne de Weger and Xiaoyun Wang showed that they were able to use H(P || M_1 || S) = H(P || M_1 || S) hiding the collision blocks in such a way that two public keys for the same identity would have the identical CA Signature. The former allows to assume different Identities the later does not.


They claim in their FAQ that an image says more than thousand words so pic related is given. I'm looking at the pdfs, but I'm not really knowledgeable with the format. I extracted the image part (or what I think that is), but it seems to be malformed standing on its own. There is by the way a second set of pdfs at the end of the paper.

They say in the paper they employed several improved techniques that do crazy stuff with JPEG Parsing, so I guess we have to wait for that release of information, probably the reference [1] can tell more about this already. I haven't had the time yet to read it.

>>4375
>So this is just a loud signal what we really need to drop SHA1 in near future and not what we must drop it today.
I think yet another (but still impressive signal) yes, and we have been deprecating it already. But its nothing to Hype up to "OMG EVERYTHING IS BROKEN" not primarily because of the computation power required (Who can't blow ~$110k just for fun?) but because its an identical prefix collision attack.

They specifically mention git on their page playing the scenario of servicing a clean and a backdoored version. My understanding is that the backdoor, since its an identical prefix, must be encoded with the collision blocks, so this
is not just dropping some binary looking blob somewhere it must also encode meaningful code which tends to have low-entropy and a rigid structure. They seem to have come up with some nifty tricks with the JPG, certainly to lower the
constraints as much as possible.

[1] Malicious Hashing: Eve’s Variant of SHA-1, Ange Albertini, Jean-Philippe Aumasson, Maria Eichlseder, Florian Mendel, Martin Schläffer 10.1007/978-3-319-13051-4_1

  No.4378

>>4376
>but it seems to be malformed standing on its own
I extracted jpegs from pdfs they included in the paper. This is really strange files, but bytestream is correct.

Good image is structured like this
COMMENT BLOCK 
COMMENT BLOCK
COMMENT BLOCK
COMMENT BLOCK
IMAGE DATA
LARGE COMMENT BLOCK

And bad one is like
COMMENT BLOCK 
COMMENT BLOCK
COMMENT BLOCK
LARGE COMMENT BLOCK
IMAGE DATA

Changing length value of first comment block they chose what image will be displayed. This is done by changing only one byte. If we want to do this in code, then it will be like this:

//garbagegarbagegarbagegarbage
goto A/**/

print "destroy world"
goto B

A:
print "hello world"
B:
exit

Now if you change // at first line to /* (one byte change), then this program will say "destroy world" instead of "hello world".

And then they placed this images inside pdfs at desired offset and found two colliding blocks what differs in first comment block length value (and some garbage inside that first comment). It will be hard to hide such trick in git repo, but it looks like a good thing to do in executable binary - with changing one JMP offset you can convert some program to a backdoor installer while keeping its original sha1 sum.

  No.4379

>>4378
>Code Example
Didn't think of it like that, thanks.

  No.4387

>>4370
in the crypto world, an actually broken primitive means it should have been phased out 5 years ago.

this is *bad*