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: Windows password security audit tool. GUI, reports in PDF.

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

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