That does not help at all: if you download two Trojan versions, with or without noise, you get a Trojan version with your method. Also, it would not work with an even vaguely non-braindamaged watermarking scheme (the noise might be a key with which the rest of the info is encrypted... your method yields a random number).
besides, if it's an outlook mail worm, then every address it goes to is targeted correctly, and Billy Goat will go on munching it's grass and not have a clue while the network slows to a crawl.
Errrr.... so you don't want an immune system because it doesn't stop bullets?
Interesting comment; I suppose in some sense it is a matter of scale. Given a sufficiently large system, it is always at least a little bit sick. The Billy Goat is fairly western in the sense that the whole point is targeted to address a particular and well defined problem well (network worms). At the same time, it fits into the category of once sick, get well fast.
Such schemes can work even if nobody collects the costs of the stamp. For example, it can be the computational cost of finding a collision in a cryptographic hash function (where one of the inputs is the message+sender+recipient).
There are several reasons. TCPA is a general purpose security mechanism; it could be used for DRM but it could also be used to secure applications on the device that are in the users best interest (e.g. digital signatures, privacy enforcement, e-checks and e-cash). Without a mechanism similar to TCPA, the secrets used by these applications can be stolen by other applications on the device.
E-stamps, in a way, that cost time rather than money.
Nicely put. Regarding enforceability, it does not solve the bandwidth aspect but I can bounce mail (with explanation) that does not either come from a known party or have an e-stamp. Thus I don't see any spam but the system remains open to new contacts.
You can still keep the system open by forcing the sender to spend a little bit of CPU time to send a message (e.g. finding a collision of a short hash function). The idea is explained at:
That doesn't address the problem. The problem is that in order to compute the hash function, you have to have already downloaded the entire file. What
one needs is a mechanism that allows you to detect cheaters in the protocol nearly continuously.
The appropriate reference to look for in the cryptographic literature is signing digital streams. For the compartively simple problem of P2P (where you don't have to worry about lossy channels), the tree based mechanism is pretty easy to implement.
The problem faked hashes can be addressed using trees of checksums
rather than just a simple checksum although a workable implementation
would require embedding into the P2P protocol.
The idea is you break the file up into smallish sized blocks (100k or
so) and generate a hash for each one of these. For each 8 first level
hashes, you feed them into a crypto hash function to generate a second
level hash. For each 8 second level hashes... you generate a third
level hash. This allows a continuous (per 100k blocks) proof that the
content is valid... The size of the proof grows with the log of the
content so it is not much of a problem.
Slashdot Mirror
That does not help at all: if you download two Trojan versions, with or without noise, you get a Trojan version with your method. Also, it would not work with an even vaguely non-braindamaged watermarking scheme (the noise might be a key with which the rest of the info is encrypted... your method yields a random number).
besides, if it's an outlook mail worm, then every address it goes to is targeted correctly, and Billy Goat will go on munching it's grass and not have a clue while the network slows to a crawl.
Errrr.... so you don't want an immune system because it doesn't stop bullets?
Interesting comment; I suppose in some sense it is a matter of scale. Given a sufficiently large system, it is always at least a little bit sick. The Billy Goat is fairly western in the sense that the whole point is targeted to address a particular and well defined problem well (network worms). At the same time, it fits into the category of once sick, get well fast.
Such schemes can work even if nobody collects the costs of the stamp. For example, it can be the computational cost of finding a collision in a cryptographic hash function (where one of the inputs is the message+sender+recipient).
There are several reasons. TCPA is a general purpose security mechanism; it could be used for DRM but it could also be used to secure applications on the device that are in the users best interest (e.g. digital signatures, privacy enforcement, e-checks and e-cash). Without a mechanism similar to TCPA, the secrets used by these applications can be stolen by other applications on the device.
Is it just me, or does Mr. Mullen's email address:
- Tim Mullen <Thor@HammerofGod.com>
make you think "insightful security professional" or 1/2(swaggering red neck cop + 31334 haxor dooood)?E-stamps, in a way, that cost time rather than money.
Nicely put. Regarding enforceability, it does not solve the bandwidth aspect but I can bounce mail (with explanation) that does not either come from a known party or have an e-stamp. Thus I don't see any spam but the system remains open to new contacts.
You can still keep the system open by forcing the sender to spend a little bit of CPU time to send a message (e.g. finding a collision of a short hash function). The idea is explained at:
That doesn't address the problem. The problem is that in order to compute the hash function, you have to have already downloaded the entire file. What one needs is a mechanism that allows you to detect cheaters in the protocol nearly continuously.
The appropriate reference to look for in the cryptographic literature is signing digital streams. For the compartively simple problem of P2P (where you don't have to worry about lossy channels), the tree based mechanism is pretty easy to implement.
The problem faked hashes can be addressed using trees of checksums rather than just a simple checksum although a workable implementation would require embedding into the P2P protocol.
The idea is you break the file up into smallish sized blocks (100k or so) and generate a hash for each one of these. For each 8 first level hashes, you feed them into a crypto hash function to generate a second level hash. For each 8 second level hashes... you generate a third level hash. This allows a continuous (per 100k blocks) proof that the content is valid... The size of the proof grows with the log of the content so it is not much of a problem.