Author

Topic: Combinatorial Hash Functions (Read 1015 times)

hero member
Activity: 718
Merit: 545
December 08, 2013, 08:25:58 AM
#3
hmm.. That's not really what i meant..

The RIPEMD160(SHA256(PUB_KEY)) to get the actual bitcoin address is a nested hash. This means that if a colission is found on the SHA256 part, the RIPEMD160 will follow suit.

It is not a combined hash that has strongest link collision resistance. (It does against first pre-image resistance)

The TXN hashes are very important to security ? Since if you could change the TXN but keep the same hash you could do some funky stuff.

Also, when you rely on ONE hash function, if a weakness is found, then the system instantly becomes insecure, whereas if you rely on more than one hash function, say 4 different hash functions, and combine them in the CORRECT WAY given their usage in the protocol, if a weakness is found in one function, it doesn't matter as you would need to break them all.

I'm just wondering if you could rely on more than one hash function, then you'd be better prepared when these function ARE EVENTUALLY broken in the future.

And if you were to use multiple hash functions, how to combine them, so as to keep the desired security features(Collision resistance, first pre image resistance, second pre image resistance, pseudo-randomness.. etc). You don't need to keep ALL of them for every task the hash is used for in the BTC protocol.

..Or do you ?
legendary
Activity: 1512
Merit: 1036
December 07, 2013, 03:22:39 PM
#2
There are already two different hashes between the public key and the bitcoin address, SHA256 and RIPEMD160. To spend Bitcoins, you must not just overcome the two hashes, but also must have the private key for the corresponding ECDSA public key. If the Bitcoin address has already spent once, then you have the public key and a signed message to work with, and don't have to worry about hashes.

If there was a reduction possible in SHA256(SHA256()) known outside the NSA, Bitcoiners would probably be the first to know about it. There's (still) $2M worth of Bitcoins a day at stake.

Hashes don't encrypt messages, so there is less reason to suspect them of being surreptitiously weakened.
hero member
Activity: 718
Merit: 545
December 07, 2013, 01:28:35 PM
#1
A few ideas..

Combining hash functions, so that that the resulting hash retains the strengths of the strongest link is not straight forward.

When concatenating hashes, the collision resistance is the strongest link, but first pre-image resistance is lost, or equal to the weakest link. The hash is also LONGER than the original.

When nesting hash functions, using the output from one hash as the input for another, gives strongest link for first pre-image resistance, but you loose the collision resistance, as in it's the weakest link. The hash is the same length.

This seems an issue, but i was wondering.

The MINING part of bitcoin, requires first pre-image resistance. Collisions don't actually matter. An attacker has a hash, which satisfies the difficulty target you are aiming for, and he wishes to find a message that hashes to that, given the block header he has.

The TXN hashing, block hashing, which proves no tampering of the messages has gone on requires target collision resistance/ collision resistance. You have a TXN and the hash of that TXN and an attacker would like to find another TXN that hashes to that same hash. Then he could change the TXN in some nefarious way, and keep the hashes the same.

Therefore, would I be write in thinking, that if you wanted a more secure hash strategy for bitcoin/crypto-currency you could :-

a) Use a nested hash of multiple hashes, say the SHA-3 finalists and SHA2, for the mining algorithm. First pre-image resistance would be strongest link.
b) Use a concatenated hash, with the same hash functions as in a), for the TXN and block hashes. Collision resistance would be strongest link

You would then need to break ALL the hashes before you could break bitcoin.. And if one or 2 of the hash functions were broken you could then think about switching to new hash functions all together..

Is this a correct line of thought ?
Jump to: