3 ms·

Coming from the perspective of a startup that is building a product, future risk/estimated damage from DOS attacks is not worth any of today's efforts to preven

Coming from the perspective of a startup that is building a product, future risk/estimated damage from DOS attacks is not worth any of today's efforts to prevent. I mean, weren't they all able to fix it after the fact and not suffer much in the end? These are problems you only run into if you've got a successful product (which happens very rarely) - and solving these problems before you have users might not be a good allocation of engineering resources for startups. I liken it to making a system that scales in advance to millions of concurrent users when you haven't even got one.

jameshart 13y ago
The thing is that anywhere in your code where you are doing something which involves hashing data to create a digest for some purpose you are almost certainly attempting to do something a bit clever (I'm going to map the problem from the domain of entities to a domain of proxies for entities that are smaller and easier to deal with. I'll just deal with the special cases...). And if you're making a decision to use Murmur2 in that role, you're probably trying to be very clever. Whenever a programmer tries to do something clever, in my experience, there is something they haven't thought about. Often the something they haven't thought about leads to a security vulnerability. The fact is it's often difficult to tell the difference between a place where the security properties of the digest algorithm you use are irrelevant, and a place where it might be critical. For example, a zip file uses a CRC32 checksum to validate each file; git uses SHA1 to uniquely identify objects; CouchDB shard mapping uses a strategy based on CRC32... if git had used murmur, would that cause problems for it? Is CouchDB being clever by using a fast hash for sharding at the expense of being secure? Now, quick, make a decision which algorithm to use to generate Etag headers for your web API HTTP response entities: are you going to go with SHA256 or Murmur2? Murmur2 is much faster, and it's certainly a clever solution... but are you sure you didn't create a security hole? I'm not saying "nobody ever got fired for choosing SHA256," but I am kind of saying that you have to be very sure you know the security model you're operating in before you build on a hash algorithm that doesn't provide strong extension and preimage resistance.

jameshart 13y ago

The thing is that anywhere in your code where you are doing something which involves hashing data to create a digest for some purpose you are almost certainly attempting to do something a bit clever (I'm going to map the problem from the domain of entities to a domain of proxies for entities that are smaller and easier to deal with. I'll just deal with the special cases...). And if you're making a decision to use Murmur2 in that role, you're probably trying to be very clever. Whenever a programmer tries to do something clever, in my experience, there is something they haven't thought about. Often the something they haven't thought about leads to a security vulnerability. The fact is it's often difficult to tell the difference between a place where the security properties of the digest algorithm you use are irrelevant, and a place where it might be critical. For example, a zip file uses a CRC32 checksum to validate each file; git uses SHA1 to uniquely identify objects; CouchDB shard mapping uses a strategy based on CRC32... if git had used murmur, would that cause problems for it? Is CouchDB being clever by using a fast hash for sharding at the expense of being secure? Now, quick, make a decision which algorithm to use to generate Etag headers for your web API HTTP response entities: are you going to go with SHA256 or Murmur2? Murmur2 is much faster, and it's certainly a clever solution... but are you sure you didn't create a security hole? I'm not saying "nobody ever got fired for choosing SHA256," but I am kind of saying that you have to be very sure you know the security model you're operating in before you build on a hash algorithm that doesn't provide strong extension and preimage resistance.