full-disclosure - Re: Case ID 51560370 - Notice of ClaimedInfringement

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <42573D07.3050406@brvenik.com>
Date: Sat Apr  9 03:25:16 2005
From: security at brvenik.com (Jason)
Subject: Re: Case ID 51560370 - Notice of
	ClaimedInfringement

Thierry Zoller wrote:
> Dear Jason,
> 
> J> I think that entirely depends on the format the file is distributed in.
> J> You could take a zipfile and pad it in non critical areas to change the
> J> MD5 without creating a substantial difference in the deliverable 
> J> content. You could do the same with gzip or bzip formatted files. You
> J> could also pad any embedded jpeg images to engineer a collision. There
> J> are quite a few opportunities where this method could be used to twiddle
> J> the new MD5 without materially changing the content.
> 
> Clever approach there, haven't thought about that beforehand.

Different approaches are rarely thought about beforehand. If they were 
explored deeply we might have found efficiencies and complications that 
would have been avoided. This security stuff might not even exist. We 
would also never make progress.

> 
> J> Software that is ~150M in size, it gets redistributed as a new file that
> J> is 160M is size but has a collision with your software which is also
> J> 160M in size. I imagine there would be some computational time involved
> J> to find the appropriate collision but a lot less computational time than
> J> finding a perfect match to the original.
> 
> If I understood your point correctly and if my knowledge about hash
> algos is correct then to my believe the computational time to generate
> a collision is exactly the same for the perfect match as it would be
> to use an existing file to create a potenatial collision.
> 

I've not looked into it to be honest. I am thinking aloud.

Are there cases where different bits will have a predictable and 
definable impact on the resulting hash? Does a null byte have a more 
defined impact than a non null byte? Can you use a minimal impact byte 
as padding and more impactful byte sequences to complete the collision?

It was once said that you could not realistically create two difference 
sets of data that would cause a hash collision.

It was once said that you could not exploit heap overflows and that 
stack overflows did not allow for control of the machine.

It was once thought that you could not use a format string to create an 
exploitable condition.

I see enough opportunities for motivated people to do the research and 
create a solution that is not computationally prohibitive. I would not 
be surprised if this happens in relatively short time.

To use the existence of a hash and size as justification for a legal 
assault against a person that appears to be providing content which is 
under protection of some law presents an interesting area of exploration 
in the courts for the right team. It was once thought that being found 
guilty by a jury was sufficient to put someone to death. DNA has changed 
that!

The only difference between theory and reality is implementation.

I think I am done with the thread on FD. Apologies to the myopic 
thinkers among us.