Use a keyed hash for deriving object IDs

[mithrandi]

Currently Entropy simply calculates SHA256(contents) in order to derive the object ID. As Entropy is designed to be run with public read-only unauthenticated access, this means that if you already have a particular object, you can verify whether or not it has been stored in an Entropy existence by calculating the corresponding object ID, and checking to see whether an object with that ID exists or not. In addition, it can be used to perform a sort of "related contents" attack, by enumerating the object IDs corresponding to some variations of an object with mostly-known contents, and testing to see which object IDs actually exist (see this paper for details).

Use of a keyed hash (such as HMAC-SHA256) would limit these attacks to actors in possession of the key; it would not be possible to recover the key from an object ID, and it would not be possible to derive an object ID from a given contents without already having the key. In the future, object IDs would be calculated by the application using Entropy, rather than calculated by Entropy itself, in which case this key would be moved to the individual application — but just holding it in Entropy itself would be good enough for now.

Losing the key would not result in the loss of any objects already stored for which the object ID is known, but if the key were replaced with a new one, object IDs would no longer match for equivalent contents, with potential space wasting (as objects stored with the new key would not be deduplicated against objects stored with the old key). This may actually be a useful feature under some circumstances.