Finnish Firm Claims Fake P2P Hash Technology

An anonymous reader writes "As reported by The Inquirer, a Finnish company known as Viralg Oy claim to have developed software that can create a junk file with the same hash as a genuine p2p download. This, according to the company, can altogether stop the sharing of copywritten files by flooding p2p networks with corrupt/junk data, which then spreads through the network, causing less and less of the original file to be available. However, with the resolve of the p2p userbase, is this software really going to 'beat all Peer 2 Peer pirates at their own game,' or simply prove a minor annoyance?"

Comments

They have cracked strong hashes, huh?

[Flywheels of Fire]

This is not true. It might work on Kazaa but most other P2P networks use MD5 or better. Okay, they have found collisions but no one has found a way to generate file for a given key. So the claim by the finnish company is bogus.

Or they have cracked even the strong hashes. In which case they are really cool. I know Mr. Torvalds is Finnish, but I doubt even he could come up with algorithms to do that.

In their conceited press release, they have compared Spoofing vs DRP/a

Re:They have cracked strong hashes, huh?

[mboverload]

Bittorrent clients ban IP's that send them a certain number of bad pieces.

Re:They have cracked strong hashes, huh?

[redhog]

Nah, you are both wrong. Two 160bit hashes are prolly somewhere in between as strong as a 320bit hash and a 160bit hash, depending on exactly how the hash-values distribute over the input space. If the hash where perfect, the distance between any two hash-values with one bit of difference would be the same. However, in reality, that would hardly be the case except for some hashes with a given data-to-hashsize-ratio. But taking two random hashfunctions would probably combine into one where many bits are redundant (not the same bits for all hash-values of course). Hm, hope that goes for enought of an explanation. Otherwize, go read up on coding theory at mathworld.wolfram.com or wikipedia. A search for "Hamming distance" might also be a good start :)

"Copyrighted"

[As Seen On TV]

It's "copyrighted," not "copywritten." We're talking about rights, not writings.

Coral Cache

[Anonymous Coward]

I took the liberty of pre-caching the site on Coral before it went live - http://www.viralg.com.nyud.net:8090/index.html. I think Slashdot should really consider doing this as part of the proceedure...this site won't last a minute under the weight of our collective, nerdy asses.

Re:Already done

[B3ryllium]

By the time this is submitted, it will probably already be redundant (even though it's informative :)) - but the hashes are used for parallel download streams of the same file. So, if you saturate the network with the same hash, you can corrupt the data when the client automatically assumes it's the same file and tries to merge it with the other incoming data.

Link to the patent application

[Zarhan]

in pdf form

Note the claims section and references - they keep talking about Napster and Kazaa - nothing about anything that use hashes.

Re:Already done

[rkcallaghan]

how will this be different from the flodding of fake files already on P2P networks like Kazaa. Sure, the hash will be the same, but what "JHoe Sixpack" looks at hashes?!

Joe Sixpack may not look at hashes, but his P2P software probably does. I know aMule uses the hash to match files that have had their names changed.

~Rebecca

Seems bogus to me

[gtoomey]

It takes 2^69 operations to find collisions with SHA1

Unless they have lots of supercomputer time, seeding the occasional p2p file with bad data will be very expensive.

Re:Seems bogus to me

[pjrc]

Remember that those 2^69 "operations" (each many CPU cycles) are for a SHA1 "collision" attack. A "preimage" attack that would be necessary to inject corrupt data into a p2p network using SHA1 (such as Bittorrent) is much harder and has not been discovered and published.

Quoting from the linked page:

Q: What is a collision attack and a preimage attack?
A: A preimage attack would enable someone to find an input message that causes a hash function to produce a particular output. In contrast, a collision attack finds two messages with the same hash, but the attacker can't pick what the hash will be. The attacks announced at CRYPTO 2004 are collision attacks, not preimage attacks.

Blaaaaaah

[mindriot]

Not only the company's, but also the submitter's claim seems to be bogus. Neither the Inquirer article nor the viralg.com website anywhere seem to be talking about hashes. Moreover, I'm kind of wondering where the Inqurer got their stuff from, since the viralg website contains... nothing. Nothing but blaah. No word at all on how they protect anything from anyone. A random link to the Finnish Top 40 allegedly showing how BMG became the market leader for domestic music. Umm, except that nothing whatsoever proves that Viralg had anything to do with it. (If you have evidence to the contrary, please post it!) Then there's some blurb about being insiders with mathematical knowledge up in the lonely north where there's nothing else to do is what got them where they are. So, where are they? Not like they actually tell us. No contact information besides the email address either (and nothing in the whois info). Apparently, being up in the lonely north with nothing else to do doesn't get you much further than producing a nonsensical website claiming you know how to save the world, find the question to the answer to life, the Universe and everything, with "stunning results."

And, breaking hashes, nonsense. If anything, maybe they are managing to manipulate P2P protocols to send you data you weren't supposed to be getting, but which is not actually going into the checksum?

Nothing for you to see here, methinks... and here I am wasting my time actually writing a reply to a trollish article. :)

On another random note, I kind of liked how their website looked in links.

Empty. :)

incomplete downloads

[TamMan2000]

I wonder why people who use P2P don't help each other out a little more. For example, you have someone with 200 files shared. They are downloading and sharing at the same time. Sometimes they download a bad file, and share it. It would make more sense to have a "unchecked" folder for downloads, then more it to the "checked" folder to share.

That would break a feature which enables greater sharing... Uploading of parts of files that you do not have all of. Think BitTorrent, but less organized...

Re:That sig is from diskworld, isn't it?

[CharonX]

Hehe, yup, its one of the great lines HEX produced.
I can really reccommend Terry Pratchett's books to everyone.

As someone who actually _does_ have a P2P attack..

[Effugas]

It's a couple pages in my paper here. Basically, the first 300Kb of Kazaa's files are hashed normally, then every 32Kb chunk of the file is hashed independently. This allows independent chunks to be downloaded out of order. These out of order chunks are recursively hashed against one another to create one final value, called a "kzhash", which is verified after the file is downloaded.

The attack is to use the recently released collision -- which creates two blocks that, when mixed against the default initial state of MD5, emit the same system state. Every 32K, you can embed one or the other in the file you're transmitting, and kzhash can't tell. What can you do with this? Morph a file as it traverses the network; have an installation executable describe the systems its being installed on as it propogates through a network. With a fairly large installer, you'd get quite a few bits in there.

You still don't get to do random noise, and while it's no Tiger Tree, kzhashing doesn't appear so exploitable that this group is likely to have anything. I could be wrong, but then, virtual algorithm? Right.

Re:Interesting idea, how can we apply it to spam?

[rbarreira]

Your post advocates a

(X) technical ( ) legislative ( ) market-based ( ) vigilante

approach to fighting spam. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state before a bad federal law was passed.)

( ) Spammers can easily use it to harvest email addresses
( ) Mailing lists and other legitimate email uses would be affected
( ) No one will be able to find the guy or collect the money
( ) It is defenseless against brute force attacks
( ) It will stop spam for two weeks and then we'll be stuck with it
( ) Users of email will not put up with it
( ) Microsoft will not put up with it
( ) The police will not put up with it
( ) Requires too much cooperation from spammers
( ) Requires immediate total cooperation from everybody at once
( ) Many email users cannot afford to lose business or alienate potential employers
(X) Spammers don't care about invalid addresses in their lists
( ) Anyone could anonymously destroy anyone else's career or business

Specifically, your plan fails to account for

( ) Laws expressly prohibiting it
( ) Lack of centrally controlling authority for email
( ) Open relays in foreign countries
( ) Ease of searching tiny alphanumeric address space of all email addresses
( ) Asshats
( ) Jurisdictional problems
( ) Unpopularity of weird new taxes
( ) Public reluctance to accept weird new forms of money
( ) Huge existing software investment in SMTP
( ) Susceptibility of protocols other than SMTP to attack
( ) Willingness of users to install OS patches received by email
( ) Armies of worm riddled broadband-connected Windows boxes
( ) Eternal arms race involved in all filtering approaches
(X) Extreme profitability of spam
( ) Joe jobs and/or identity theft
( ) Technically illiterate politicians
( ) Extreme stupidity on the part of people who do business with spammers
( ) Dishonesty on the part of spammers themselves
( ) Bandwidth costs that are unaffected by client filtering
( ) Outlook

and the following philosophical objections may also apply:

(X) Ideas similar to yours are easy to come up with, yet none have ever
been shown practical
( ) Any scheme based on opt-out is unacceptable
( ) SMTP headers should not be the subject of legislation
( ) Blacklists suck
( ) Whitelists suck
( ) We should be able to talk about Viagra without being censored
( ) Countermeasures should not involve wire fraud or credit card fraud
(X) Countermeasures should not involve sabotage of public networks
( ) Countermeasures must work if phased in gradually
( ) Sending email should be free
( ) Why should we have to trust you and your servers?
( ) Incompatiblity with open source or open source licenses [hey, it's Microsoft... they've probably already submitted the patent...]
( ) Feel-good measures do nothing to solve the problem
( ) Temporary/one-time email addresses are cumbersome
( ) I don't want the government reading my email
( ) Killing them that way is not slow and painful enough

Furthermore, this is what I think about you:

(X) Sorry dude, but I don't think it would work.
( ) This is a stupid idea, and you're a stupid person for suggesting it.
( ) Nice try, assh0le! I'm going to find out where you live and burn your house down!

Re:Just an annoyance

[merlin_jim]

Actually we were both wrong; it is (2^keylength)^2 number of keys. However this number is equivalent to 2^(keylength*2), not 2^(keylength^2)

Why would this not be "just double work"?

First you find all files matching the first hash, then filter out one matching the second.

And where exactly do you think the work is occuring? Computing the second hash. If you have one hash algorithm, you only have to match once. If you have two hash algorithms and you did it this way, you have to match enough with the first algorithm to find a match for the second algorithm. This isn't twice as much work, this is twice as much keyspace (with each bit increase in keyspace representing twice the work)

Re:Just an annoyance

[mancontr]

I meant: The file isn't verified only when complete, every chunk is verified when received. (BT:1/2mb,ED2k:10mb) Sorry, me fail english... (that's not umpossible...)