Bitcoin Forum
March 28, 2024, 08:22:44 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 [2]  All
  Print  
Author Topic: Dealing with SHA-256 Collisions  (Read 51145 times)
ShadowOfHarbringer
Legendary
*
Offline Offline

Activity: 1470
Merit: 1005


Bringing Legendary Har® to you since 1952


View Profile
March 07, 2011, 04:06:15 PM
 #21

I suppose I could try to double-spend with two transactions that hash to the same value... and hope that the merchant's bitcoin accepts Transaction Version 1 while the majority of the rest of the network accepts Transaction Version 2 (where I pay myself).   But if SHA-256 ever gets close to being broken I'm sure bitcoin will be upgraded so new clients only accept upgraded hashes for new blocks/transactions.

Wouldn't changing the hash to SHA-512 or 512-Bit Whirlpool let's say.... from block 250.000, before anything is broken yet a wise move ?
Also, we could double private/public key lengths... just in case.

I mean that would give us extra reaction time in the event of quantum computers are invented or something else got broken...

1711614164
Hero Member
*
Offline Offline

Posts: 1711614164

View Profile Personal Message (Offline)

Ignore
1711614164
Reply with quote  #2

1711614164
Report to moderator
1711614164
Hero Member
*
Offline Offline

Posts: 1711614164

View Profile Personal Message (Offline)

Ignore
1711614164
Reply with quote  #2

1711614164
Report to moderator
1711614164
Hero Member
*
Offline Offline

Posts: 1711614164

View Profile Personal Message (Offline)

Ignore
1711614164
Reply with quote  #2

1711614164
Report to moderator
"Governments are good at cutting off the heads of a centrally controlled networks like Napster, but pure P2P networks like Gnutella and Tor seem to be holding their own." -- Satoshi
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1711614164
Hero Member
*
Offline Offline

Posts: 1711614164

View Profile Personal Message (Offline)

Ignore
1711614164
Reply with quote  #2

1711614164
Report to moderator
1711614164
Hero Member
*
Offline Offline

Posts: 1711614164

View Profile Personal Message (Offline)

Ignore
1711614164
Reply with quote  #2

1711614164
Report to moderator
1711614164
Hero Member
*
Offline Offline

Posts: 1711614164

View Profile Personal Message (Offline)

Ignore
1711614164
Reply with quote  #2

1711614164
Report to moderator
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652
Merit: 2164


Chief Scientist


View Profile WWW
March 07, 2011, 04:15:54 PM
 #22

RE: changing things now "just in case" :

No, I think it would be dumb to switch hashing algorithms or public/private keylengths now, for at least two reasons:

1. You'd just be switching from older technology that has the advantage of being well-tested and "battle-hardened" to something newer that you THINK will be more secure.

2. There are much more important things to work on.  If you know enough about crypto to evaluate whether Whirpool really is fundamentally more secure than SHA-256, please apply your knowledge to the problems we have right now, like making users' wallets more secure against trojans and malware...

How often do you get the chance to work on a potentially world-changing project?
theymos
Administrator
Legendary
*
Offline Offline

Activity: 5152
Merit: 12580


View Profile
March 07, 2011, 04:17:58 PM
 #23

SHA-256 will not be broken suddenly. Even SHA-1 has not yet been completely broken, but has gradually become considered less secure. We'll have plenty of time to switch to a newer hash. Maybe we'll do it at the same time we lift the 32-bit timestamp limit...

The SHA-3 candidates are more likely to be completely broken than SHA-256, since they are new.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
ShadowOfHarbringer
Legendary
*
Offline Offline

Activity: 1470
Merit: 1005


Bringing Legendary Har® to you since 1952


View Profile
March 07, 2011, 04:54:22 PM
 #24

RE: changing things now "just in case" :

No, I think it would be dumb to switch hashing algorithms or public/private keylengths now, for at least two reasons:

1. You'd just be switching from older technology that has the advantage of being well-tested and "battle-hardened" to something newer that you THINK will be more secure.

2. There are much more important things to work on.  If you know enough about crypto to evaluate whether Whirpool really is fundamentally more secure than SHA-256, please apply your knowledge to the problems we have right now, like making users' wallets more secure against trojans and malware...


OK, agreed. That answers first part of my question.

So about the second part:
What about making public/private keys longer without changing hashing algorithms ?

PS.
Truecrypt uses Whirlpool almost from the beginning, i don't know if that makes the algorithm more trustworthy or not however.

PS2.
I just thought that by changing Hashing algo from SHA-256 to SHA-512 we are essentially increasing security, because that is simply the same algorithm, just with longer output.

Neereus
Newbie
*
Offline Offline

Activity: 28
Merit: 0


View Profile
March 07, 2011, 05:43:45 PM
 #25

This is why I left it open ended on time, and said after it saw real world use.
My idea was more of a long term idea.
Just wanted to know if the system would allow for a new hashing algorithm in the future.
kseistrup
Hero Member
*****
Offline Offline

Activity: 566
Merit: 500


Unselfish actions pay back better


View Profile WWW
March 07, 2011, 05:50:55 PM
 #26

I like Grøstl it seems to be the best hash of the lot.

If not for anything else, then for its name — yummy!  Smiley

Cheers,

Klaus Alexander Seistrup
theymos
Administrator
Legendary
*
Offline Offline

Activity: 5152
Merit: 12580


View Profile
March 07, 2011, 08:58:47 PM
 #27

It might be nice to add OP_WHIRLPOOL etc. to Script to ease a switch if one is ever needed.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
ShadowOfHarbringer
Legendary
*
Offline Offline

Activity: 1470
Merit: 1005


Bringing Legendary Har® to you since 1952


View Profile
March 07, 2011, 10:58:58 PM
 #28

It might be nice to add OP_WHIRLPOOL etc. to Script to ease a switch if one is ever needed.

Well, it sounds like a flag would be nice in this situation.

Value 0 = "classic" hash
Value 1 = sha512
Value 2 = whirlpool

What if the network could theoretically accept different hashes  (and perhaps different pub/priv keylengths ?)

I don't know If I'm thinking right here, because I'm not actually a C/C++ programmer.

Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2576
Merit: 1186



View Profile
March 08, 2011, 01:05:41 AM
 #29

It might be nice to add OP_WHIRLPOOL etc. to Script to ease a switch if one is ever needed.
That was my initial thought, but it won't help the fact that the tx and block itself are hashed with SHA-256...

theymos
Administrator
Legendary
*
Offline Offline

Activity: 5152
Merit: 12580


View Profile
March 08, 2011, 01:43:51 AM
 #30

That was my initial thought, but it won't help the fact that the tx and block itself are hashed with SHA-256...

Yeah, I suppose. I was thinking some transactions wouldn't need to be re-signed, but transactions use SHA-256 in inputs.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
comboy
Sr. Member
****
Offline Offline

Activity: 247
Merit: 252



View Profile
March 08, 2011, 02:37:01 AM
 #31

It might be nice to add OP_WHIRLPOOL etc. to Script to ease a switch if one is ever needed.

Well, it sounds like a flag would be nice in this situation.

Value 0 = "classic" hash
Value 1 = sha512
Value 2 = whirlpool

What if the network could theoretically accept different hashes  (and perhaps different pub/priv keylengths ?)

Sounds like a bad idea to me.  Instead if 1 security problem, you have 3. Security will be always as strong as the weakest hashing method you can choose.

Variance is a bitch!
sandos
Sr. Member
****
Offline Offline

Activity: 440
Merit: 250


#SWGT CERTIK Audited


View Profile
March 08, 2011, 06:58:15 AM
 #32

It might be nice to add OP_WHIRLPOOL etc. to Script to ease a switch if one is ever needed.

Well, it sounds like a flag would be nice in this situation.

Value 0 = "classic" hash
Value 1 = sha512
Value 2 = whirlpool

What if the network could theoretically accept different hashes  (and perhaps different pub/priv keylengths ?)

Sounds like a bad idea to me.  Instead if 1 security problem, you have 3. Security will be always as strong as the weakest hashing method you can choose.

Correct, the right way is to force inclusion of more than one hash.

ShadowOfHarbringer
Legendary
*
Offline Offline

Activity: 1470
Merit: 1005


Bringing Legendary Har® to you since 1952


View Profile
March 08, 2011, 07:19:02 AM
 #33

It might be nice to add OP_WHIRLPOOL etc. to Script to ease a switch if one is ever needed.

Well, it sounds like a flag would be nice in this situation.

Value 0 = "classic" hash
Value 1 = sha512
Value 2 = whirlpool

What if the network could theoretically accept different hashes  (and perhaps different pub/priv keylengths ?)

Sounds like a bad idea to me.  Instead if 1 security problem, you have 3. Security will be always as strong as the weakest hashing method you can choose.

Correct, the right way is to force inclusion of more than one hash.

+ 1
Well, didn't think of that.

EDIT:
Gentoo Linux (which I am a proud user of) uses this approach to decrease possibility of collision even further.
Gentoo's package management ford SHA-256 + SHA-1 + RMD 160 + size checking for every file.

bitcool
Legendary
*
Offline Offline

Activity: 1441
Merit: 1000

Live and enjoy experiments


View Profile
May 31, 2011, 04:15:31 AM
 #34

Interesting discussion, hate to see it stopped there. Having 2 levels of hashing with different algorithms will be much safer.

In the New to BitCoin thread (http://forum.bitcoin.org/?topic=7269.0) it says

The cryptography used in BitCoin is so strong that all the world's online banking would be compromised before BitCoin would be, and it can even be upgraded if that were to start to happen.  It's like if each banknote in your pocket had a 100-digit combination lock on it that couldn't be removed without destroying the bill itself.  BitCoin is that secure.

I sensed a lot of complacency here. What it didn't mention is bitcoin network is much more accessible than online banking systems, which usually are monitored by security staff. 

If SHA256 is suddenly broken -- however a remote possibility it is -- very likely the fully automated Bitcoin network will suffer the most, as SHA256 is THE cornerstone bitcoin is built on, and all the eggs are in one basket. The banking industry on the other hand has many ways to make human intervention under similar circumstance. If all online banking service is  shut down, they still can run computers on their private network and physically secure the communication lines.

Please excuse my paranoia but unfortunately with the appreciation of btc, a single private/public key pair can now hold millions dollar of value, the incentive for finding and hacking any weakness has increased exponentially too
error
Hero Member
*****
Offline Offline

Activity: 588
Merit: 500



View Profile
May 31, 2011, 06:04:39 AM
 #35

If SHA256 is "broken" there will be lots of research papers warning of it in plenty of time to update the algorithm. Or maybe the NSA will break it and keep it secret. Or maybe a giant asteroid will crash into the earth and wipe everyone out.

3KzNGwzRZ6SimWuFAgh4TnXzHpruHMZmV8
seanp2k
Newbie
*
Offline Offline

Activity: 3
Merit: 0


View Profile
May 31, 2011, 06:23:54 AM
 #36

Re: quantum computing...
http://venturebeat.com/2011/05/27/first-quantum-computer-sold/

Cheesy
matt.collier
Member
**
Offline Offline

Activity: 105
Merit: 10



View Profile
May 31, 2011, 03:38:59 PM
 #37

Shor's Algorithm.  A quantum algorithm which can evidently be used to break RSA encryption.  $10M for a quantum computer is not a lot of money to many corporations or even individuals.

http://en.wikipedia.org/wiki/Shor's_algorithm

Just when you thought it was safe to go back into the water.
Sukrim
Legendary
*
Offline Offline

Activity: 2618
Merit: 1006


View Profile
May 31, 2011, 08:22:25 PM
 #38

Correct, the right way is to force inclusion of more than one hash.

Would this actually a possibility?

For example make the "Hash" field of blocks 1024 bit long and include a SHA256, a 512 bit Grøstl hash, and 2 128bit whatever hashes.
To forge a block, you would then need to find something that has the same SHA256, Grøstl and 2 other hash values. This should be tough even with already "broken" hashes like a MD5 + CRC32 simultaneous collision.

Also it might make mining a bit more difficult, which is actually a good thing, as this makes it more accessible --> CPUs could for sure easily handle it and it makes mining less likely to be overrun by just a shipload of ASICs.

https://www.coinlend.org <-- automated lending at various exchanges.
https://www.bitfinex.com <-- Trade BTC for other currencies and vice versa.
bitcool
Legendary
*
Offline Offline

Activity: 1441
Merit: 1000

Live and enjoy experiments


View Profile
May 31, 2011, 08:47:05 PM
 #39

This past discussion is related to this topic:  http://forum.bitcoin.org/index.php?topic=360.0

unk
Member
**
Offline Offline

Activity: 84
Merit: 10


View Profile
June 01, 2011, 02:05:55 PM
 #40

The cryptography used in BitCoin is so strong that all the world's online banking would be compromised before BitCoin would be, and it can even be upgraded if that were to start to happen.  It's like if each banknote in your pocket had a 100-digit combination lock on it that couldn't be removed without destroying the bill itself.  BitCoin is that secure.

this is just false, and it's unfortunate that people often claim this. it applies to the public-key encryption that bitcoin uses but to no other feature of the system. 'all the world's online banking' does not depend fully on sha-2 for its security, for example.

sha-2 is likely secure for the foreseeable future (although there's too much complacency around certain features of its use in bitcoin), so it may not make much difference in practice. i just hate to see the repetition of the false comparison between bitcoin and the security of unnamed 'banks' when it's patently false.
Pages: « 1 [2]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!