Claim is all broken all 64 rounds.
https://www.treadwell-stanton.com/services/latest-news
Topic: Dealing with SHA-256 Collisions (Read 50984 times)
Looks like we will find out what happens.
Claim is all broken all 64 rounds.
https://www.treadwell-stanton.com/services/latest-news
Claim is all broken all 64 rounds.
https://www.treadwell-stanton.com/services/latest-news
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.
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.
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.
http://en.wikipedia.org/wiki/Shor's_algorithm
Just when you thought it was safe to go back into the water.
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.
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
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
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.
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.
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.
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.
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... 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.
It might be nice to add OP_WHIRLPOOL etc. to Script to ease a switch if one is ever needed.
I like Grøstl it seems to be the best hash of the lot.
If not for anything else, then for its name — yummy!
Cheers,
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.
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.
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...
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.
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.
The SHA-3 candidates are more likely to be completely broken than SHA-256, since they are new.
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...
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...
Jump to: