rootkovska
Fails the laziness doctrine
Since the local hash is the same as the vendor hash there is nothing to stop a lazy user from building a database that asserts little but looks like it asserts everything.
Much better to have an algo that requires the code to be local plus integrates the keys and perhaps method statement into it i.e. sign( hmac( {code}, public_key ), private_key) = code.sig sign( code.sig + origin.{id}, private_key ) = method.sig This verifies at least that the private_key owner has a local copy of the code and asserts their method in conjunction with its output.
I'm sure this is not the only way or even the best way of accomplishing this. I leave it here as a discussion point.
I think this leaves out the digital signatures. The usefulness of codehash.db isn't merely having a collection of hash values. It's having those hash values along with the attestations of witnesses who have digitally signed those hash values and provided their own signed origin statements.
This is what prevents a hypothetical lazy person from building a database that looks like it asserts everything. That person might fill a database with numerous hash values, but since there will be few, if any, witness signatures to go along with them, the lazy database will be fairly useless.
Not sure weather read what I wrote or not. The generic function sign() and the outputs *.sig are inherently signatures against the users identity keypair.
The key point here is that IF for a specific build the hash being signed is the same hash for all codehash.db presenters, then there is NO proof that any specific user actually has a local copy of any file. All their signature demonstrates is that they can download a hash and sign it, thus a lazy signer is indistinguishable from a diligent one (trust the process, not the person).
The protocol I put up, generates a unique hash for each presenter's public key and the signature on that hash demonstrates that they have control of the private key.
Now, the hash value could be posted in the folder as well the signatures. But since the method file describes the process then having the hash present is superfluous. Being as it is possible for anyone to follow the same method to validate the signature against their own copy if they also have the signers public key.
IIUC, the idea here is to cryptographically prohibit someone who does not posess the full input data from producing a valid witness signature.
This makes mathematically impossible the case where a user verifies file.iso.sha256.gpg correctly signs file.iso.sha256, but not that file.iso.sha256 is the correct hash of file.iso.
I think this is a nice idea.
