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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a53adc460504082018108b4fe5@mail.gmail.com>
Date: Sat Apr  9 04:18:46 2005
From: supadupa at gmail.com (Scott Edwards)
Subject: Re: Case ID 51560370 - Notice of
	ClaimedInfringement

On Apr 8, 2005 10:50 AM, Jason <security@...enik.com> wrote:
[snip]

> I think that entirely depends on the format the file is distributed in.
> You could take a zipfile and pad it in non critical areas to change the
> MD5 without creating a substantial difference in the deliverable
> content. You could do the same with gzip or bzip formatted files. You
> could also pad any embedded jpeg images to engineer a collision. There
> are quite a few opportunities where this method could be used to twiddle
> the new MD5 without materially changing the content.
> 
> Here is the case I am thinking about.
> 
[snip]

You can always use steganography
[http://en.wikipedia.org/wiki/Steganography]* for purposes of causing
the MD5 to change.  There doesn't even have to be valid data to hide
in what I'll just reference as the "steganography metadata stream". 
The key is to allow both copies to appear to operate the same, but are
clearly different when compared byte for byte.  bitmaps, lossless or
lossy, just modify a few pixels.  Find something that's not being
utilized, and modify it so the data type is still ok, but the data is
ever-so slightly different.  Just think about crafty viruses like CIH
that relocated itself in unused areas in the executable.

After this, you'll have a hard time discerning between the origionals
and the fakes.  You'll have more ground that'll need to be researched
to see if every varying signature is liable as a claimed infringment. 
Even if it's distorted, it's still plausible as a protected work - but
to what degree I can't say ** (how much milk does plain water need to
be to become milk? at what point isn't it water anymore?).  Granted,
exclusive use of tainting the signature weakens P2P, as this is a
relative dependency.

Aside from all this, it's best to avoid the appearance of evil.  I
won't vouch for anyone else's actions, but *do* exercise caution.
(caveat emptor, no two ways about it).

* Edit+Improve this article if you can.
** That's right, it's a security/disclosure mailing list - not an open
legislative discussion one.

I hope you've enjoyed my comments - and if not, no loss for me.

Thanks,


Scott Edwards

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ