Quote from: vector76 on June 27, 2011, 04:54:48 PM

Whoever is generating the hash has access to the plaintext map of accounts can alter it at will before hashing it. You have to take the word of the person who is doing the hashing, and I don't see a way around that.

If your account map is { (A, 5), (B, 2) } you could add all the accounts, then take the total amount, 7, and append a nonce, so you have 7_snei238nbd, and then just sign that with the private key of whoever is doing the hashing. Third parties can verify the signature but they cannot forge messages.

You could go further and take the SHA-256 hash of the account data, and append it to the total and the nonce before signing. Then if the signer/hasher is challenged or "audited" they can't arbitrarily assign values to keys. They are locked into revealing how the values were assigned to keys at the time of signing.

Quote from: vector76 on June 30, 2011, 11:45:01 PM

No bounty? lol

This doesn't begin to solve the problem I identified, read my original post again and see what I'm trying to accomplish, then read the requirements for what the hash needs to do. It needs to be cryptographically secure against recovering individual inputs. I'm looking for a formal written research here. Prepending the total sum to the hash of the pairs is not cryptographically secure in the context of this problem. Examining the output to determine the sum of the inputs (but no other information may be recoverable, like private keys) must guarantee that it's the same sum of the inputs that used to produce the hash. An output of 7; is not secure because could be anything, something whose inputs do not sum to 7, or even nonsense that's not a hash at all. Using a nonce in a function disqualifies it from being a hash because the input produces an unpredictable output.

And also, I would need your Bitcoin address.

awwright

Posts

Merits