A basic question

[Kprawn]

When SHA256 gets too easy, they just incorporate SHA512 etc... etc.. The protocol could evolve with time and computational power.. It's not set in stone.  

If you ever fear this possibility... watch this video -->  https://www.youtube.com/watch?v=ZloHVKk7DHk

"Quindecillion" is HUGE numbers! .... The metaphor he used with drawers was excellent to explain it.... The time and resources to solve this, will be HUGE and it will kill most of your profit from doing this.  

[1715080373]

1715080373

[Soros Shorts]

Note that to convert from private key to bitcoin address you need to go through 2 transforms that are each "one-way", at least for now.

private key -> public key -> address

Someone already mentioned what these transforms are (EC PK cryptography and SHA256). Cryptographers spend their careers designing as well as trying to break these transforms, because they protect other stuff much more valuable than bitcoins.

Now you come out of the blue, claim you know nothing about cryptography, but assert that is should be easy to go directly from address -> private key because there must be some pattern that should be easy to find?

[Kazimir]

If you could look at two bitcoin addresses and say "there is at least a 50.000001% chance that it is higher than another specific address" then, because of the astronomical number of addresses, all addresses would be vulnerable.

It's exactly 50%.

For any given random address, there is an equal probability for it (that's 2^-256) belonging to ANY random private key.

[DannyHamilton]

You clearly don't understand much about what you are talking about and you are taking a very simplistic understanding of arithmetic and attempting to apply it to a very complex area of mathematics (specifically cryptography).

Lets try and get you straightened out on the very basics that you're lost on before we waste time trying to help you see the more complex areas of digital signature algorithms and hashes.

As I understand it, sha256 uses 32 bit characters,

You are mistaken.  SHA256 uses two hundred fifty-six single bit characters. Each and every one of those characters is either a 1 or a 0.  The results are converted to base58 for display to humans, but the math is all done in binary.  You are welcome to convert the 256 bit primary key and the 512 bit public key into any format you like, it won't change the security of the underlying binary numbers.

Certainly it would take a long time to find many using a pen and paper. With a calculator someone who knew math could find a bunch of these patterns for any particular number base quickly. With a regular computer you could find quite a few patterns in a short time.

You are talking about patterns as if they are guaranteed to exist.  It is quite likely that there are no discoverable patterns linking an ECDSA private key to an associated bitcoin publick key hash.  Clearly if they do exist, then they can't be found with a regular computer "in a short time", because people have been trying to crack these cryptographic functions for many years and nobody has been successful yet.
 

You might be able to say for example " looking at that bitcoin address it is possible to say that the associated private key does not contain the string '234' ".

That is almost certainly not something that is going to happen.

That is a very rough example but again it shows that using more complex numbers, like having a large number of possible addresses, gives a false impression of security.

Fortunately bitcoin doesn't rely on complex numbers and a false impression of security.

Note that even if weaknesses are discovered in any of the cryptographic functions, there will almost certainly be plenty of time to adapt the protocol to user newer signature and hashing algorithms before those weaknesses are expanded enough to be a problem.  For example, weaknesses were discovered in the SHA-1 hashing algorithm a decade ago in 2005 and yet it would still work perfectly fine as a hashing function for bitcoin mining today if Sathoshi had chosen it instead of SHA-2

[Klestin]

Okay, that is clear, but a hash is not a random number.

The relationship between a private and public key is not based on a hash.  Bitcoin uses an elliptic curve algorithm.  Here's a good primer: https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm

This particular type of public/private key algorithm is used all over the place.  If it were cracked, huge portions of our electronic security systems would collapse.  So if you do crack it, you should probably choose a more lucrative target than bitcoin.

[jonald_fyookball]

Okay, that is clear, but a hash is not a random number.

The relationship between a private and public key is not based on a hash.  Bitcoin uses an elliptic curve algorithm.  Here's a good primer: https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm

This particular type of public/private key algorithm is used all over the place.  If it were cracked, huge portions of our electronic security systems would collapse.  So if you do crack it, you should probably choose a more lucrative target than bitcoin.

Although hashing is used, both in the ECDSA calculations, as well as in additional steps to calculate the address from the public key.

[Klestin]

Although hashing is used, both in the ECDSA calculations, as well as in additional steps to calculate the address from the public key.

True, but to get from a public key to a private key, reversing the hashing algorithm will get you exactly nowhere.

[Kazimir]

As I understand it, sha256 uses 32 bit characters,

You understood wrong.

In fact the more complex the characters, or 'numbers' the more patterns like that which can be found.

For some reason you seem to insist that there must be some pattern hidden underneath, waiting to be discovered. Don't you realize that it's very well possible (or even extremely likely, statistically speaking) that there simply IS no such pattern?

Going from address back to private key, that is reversing the ECC + Sha256 + Ripemd160 steps, is not by any stretch of the imagination comparable to divisibility by 3. Not just a "way more complex version" of it, but just a totally, fundamentally different kind of process.

Try and understand my random mapping example I posted in the previous page.

That is a very rough example but again it shows that using more complex numbers, like having a large number of possible addresses, gives a false impression of security.

You really have a false conception of the underlying math.

It's not "more complex" numbers. It's longer numbers, as in, more bits. With no correlation. More entropy. And more entropy does not mean more detectable patterns, it means harder to guess.

[R2D221]

and each of the people on this thread who defend sha256 probably would have defended md5.

You're just jumping to conclusions.

Anyway, hypothetically, if a credible flaw were found in sha then the effect would be to help scrypt coins.

And if a credible flaw were found in scrypt, we would need to find other hashing algorithms. What's your point?

[DannyHamilton]

There is a difference between the appearance of entropy and the reality of it. Something encrypted is most definitely not random. It is made to appear random. But that is not the same as being random.

Fortunately, nothing in bitcoin is encrypted.  Furthermore, hashes are not "random"  they are entirely deterministic.  Every time I perform SHA-256 against the words "no-ice-please is spouting off words without taking the time to understand the processes that he is attempting to discuss", I will ALWAYS get the result: bf403c0c12e1f27f5bd372b4724a2a41bbc2360a02c52ead40b4c7b4b66e6d11.  There is nothing random about it.  However, you aren't going to find a pattern in the SHA-256 inputs and outputs that will allow you to look at the hash: 1e39dffd07a1690be370193a7c03ae6e494f2adb98a8391c83c4920a5951f857 and figure out exactly what text I started with.  It is deterministic, but it isn't reversible.

Someone mentioned that md5 has weaknesses.

Certainly.

Is that an ancient cryptographic system, untrusted in recent years?

Well that's a ridiculously non-specific question.

Ancient?  Like hundreds of years old?  No.

Untrusted?  That depends on the person doing the trusting and the purpose that it's being used for.

Recent?  Like within the past few hours?  Sure.

So in 2012 Microsoft was using a flawed cryptographic system,

Microsoft does a lot of stupid things.  I don't understand the point you're trying to make.

and each of the people on this thread who defend sha256 probably would have defended md5.

I'd still defend MD5 as being perfectly suitable for some purposes.  MD5 (and SHA-1, and SHA-2, and RIPEMD-160) is just a tool.  When used properly, it can serve a purpose.  When used improperly, it will result in problems.

Note that MD5 didn't go from "very secure" to "completely useless" in a matter of hours (or days, or weeks).  There were incremental advancements on finding weaknesses in the algorithm building on those weaknesses.  There was a significant amount of time between when the first weakness was identified and when it was possible to forge a certificate.  Those aware of advancements in cryptography (the same types of people that contribute to the bitcoin protocol) would have been aware of the early discoveries and would have had plenty of time to adopt newer algorithms as needed.

Anyway, hypothetically, if a credible flaw were found in sha then the effect would be to help scrypt coins.

Perhaps.  Or perhaps the effect would be to increase the mining difficulty in bitcoin and work towards replacing SHA-2 in the generation of bitcoin addresses.

Note that if it was possible today to calculate an ECDSA 256 bit public key from its SHA-256 hash in a fraction of a second, bitcoin would still be perfectly secure.  The public key is broadcast EVERY time you spend your bitcoins.  Knowing it isn't going to help you steal someone's bitcoins.

[johnyj]

Two problems:

1. you can not calculate the public key from the address, since the conversion is not lossless. This is similar to, you can not get the raw picture data from a compressed JPG file, since lots of raw data have been thrown away during the compression. The only way is to guess the missing part using brute force. That is only possible by a 256 bits quantum computer, which only exists in imagination

2. You can get the public key in an transaction if one address has spent its coins. Then it is theoretically possible to calculate the private key using public key, by using a specially designed 256 bits quantum computer, which only exists in imagination

In fact, the difficulty for quantum computer lies in the calculation. You can factor large numbers since the calculation is extremely simple, just multiply, but to do hash function using quantum computer would be a huge challenge

[AtheistAKASaneBrain]

There's no way around SHA-256 unless we invent quantum computers powerful enough to bruteforce the passes period. The rest is paranoia and FUD.

[jonald_fyookball]

There's no way around SHA-256 unless we invent quantum computers powerful enough to bruteforce the passes period. The rest is paranoia and FUD.

and the algorithms to use them.  there is no known quantum algorithm capable of 'brute forcing'.

[no-rice-peas]

Sorry, I don't have my no ice please password so I created a new I'd.

This is what I have understood so far:
1) MD5 was considered utterly secure until it was cracked. The crack involved a flaw inherent to using hashes in asymmetric cryptography and should obviously thus preclude their use for things such as bit coin.
2) The hash cracking process involved two basic steps. Initially a meta flaw in hashing security, then a specific application adapted to a specific algorithm such as md5.
3) There have been not one but several completely distinct meta vulnerabilities found in using hashes for cryptographic purposes. In other words several different ways have been mentioned publicly to crack them. Some are slow others are very fast.
4) Using a longer key length does not realistically increase the cryptographic strength of hashes even with very long keys.

So I with my small years old computer and meager interest in the subject will not break sha2, but someone has. There are literally dozens or more of people working full time to crack it, using powerful computers, it is safe to say they can do to sha2 what relatively poorly equipped researchers did years ago with md5.

So my question now is which coin has a more reliable algorithm, preferably without the seal of approval from any govt?

[R2D221]

So my question now is which coin has a more reliable algorithm, preferably without the seal of approval from any govt?

No matter what hashing algorithm you use, it will be eventually cracked (according to your own post). So, why bother with them, anyway?

[Bitware]

This is a basic question about bitcoin security that I don't see answered adequately.

I'm not an expert in anything, so it is possible I am missing the obvious, but would still like an answer.

The bitcoin private key is a 256 bit number that contains a numerical address and a key to decrypt numerical messages sent to that address.

The number of key is quite high. The security of the bitcoin system seems to be based on the difficulty of using a public address to work backwords and find the private key. But there seems to be an obvious proof that shows that to be flawed.

In order to show that the current bitcoin key system is flawed, all that a person would need to do is show that there was a correlation between the relative position of a private key and the relative position of its corresponding public address.

In other words, if you took the lowest possible private key, a 256 bit number starting with 00000... etc, and the highest possible private key, a 256 bit number starting with 11111... etc, and you were able to show that the two public addresses for those keys formed hard boundaries, i.e., that all bitcoin public addresses fell between those two numbers in some mathematical formula or progression, then you would be showing that an accessible formula existed to work backwords from the public adrress to the private key.

The obvious question then, does some formula or progression exist that could put bitcoin addresses in sequence? Any set of numbers that are derived from another set of numbers ultimately can be ordered in the same sequence as the original set. Therefore it seems that the "security" of the cryptography used in bitcoin would come not from the size of the number set but rather from the computational difficulty of converting private key to public address or vice versa. Since in bitcoin the conversion in one direction, i.e., private key to public address, requires little effort, there is really no security once a formula or progression rule for addresses is discovered. And such a fomula or progression is easily findable by anyone with a little skill in that kind of thing.

... Is that accurate?

This should put things in perspective for you...

[R2D221]

This is a basic question about bitcoin security that I don't see answered adequately.

I'm not an expert in anything, so it is possible I am missing the obvious, but would still like an answer.

The bitcoin private key is a 256 bit number that contains a numerical address and a key to decrypt numerical messages sent to that address.

The number of key is quite high. The security of the bitcoin system seems to be based on the difficulty of using a public address to work backwords and find the private key. But there seems to be an obvious proof that shows that to be flawed.

In order to show that the current bitcoin key system is flawed, all that a person would need to do is show that there was a correlation between the relative position of a private key and the relative position of its corresponding public address.

In other words, if you took the lowest possible private key, a 256 bit number starting with 00000... etc, and the highest possible private key, a 256 bit number starting with 11111... etc, and you were able to show that the two public addresses for those keys formed hard boundaries, i.e., that all bitcoin public addresses fell between those two numbers in some mathematical formula or progression, then you would be showing that an accessible formula existed to work backwords from the public adrress to the private key.

The obvious question then, does some formula or progression exist that could put bitcoin addresses in sequence? Any set of numbers that are derived from another set of numbers ultimately can be ordered in the same sequence as the original set. Therefore it seems that the "security" of the cryptography used in bitcoin would come not from the size of the number set but rather from the computational difficulty of converting private key to public address or vice versa. Since in bitcoin the conversion in one direction, i.e., private key to public address, requires little effort, there is really no security once a formula or progression rule for addresses is discovered. And such a fomula or progression is easily findable by anyone with a little skill in that kind of thing.

... Is that accurate?

This should put things in perspective for you...

It's no use. no-ice-please thinks that a flaw can be found that bypasses counting and harnessing the energy of a million suns. That idea is baseless, though.

[Sithara007]

So my question now is which coin has a more reliable algorithm, preferably without the seal of approval from any govt?

No matter what hashing algorithm you use, it will be eventually cracked (according to your own post). So, why bother with them, anyway?

It's right. You can not stop it happening. Someone, somewhere will eventually crack it and you will be doomed then.
Better you go with flow.

[jonald_fyookball]

MD5 only had 64 bits of security, SHA-256 has 128.

Anyway, don't forget...information wants to be free.
If something is cracked, it won't be a secret for long.

[Bitware]

Keccak subset SHA-3 also contains SHA384 (192 bit) and SHA512 (256 bit), so the Bitcoin Core can be upgraded if the need ever arises. Plus, I am sure more secure algorithms will be developed in the future that Bitcoin can be upgraded to if needed.

That said, I've yet to hear of a single collision with SHA256, and we know that cryptographers and hackers are trying to do it. But if you can produce any SHA256 collisions, please show us all, but I don't think you can.

This all is really a non-issue.