Bitcoin address SHA-2(string+n)

[jennamarble]

SHA256 is secure you are declaring that sha256 is insecure? besides that length-extension attack wouldn't work on anything which is considered secure such as 132 bits of entropy...

If by secure you mean "cannot be reverse-engineered" then that is correct. However, it is suspectable to brute-force. On a 1080 Ti card a hacker can try SHA256 combos at around 4400 megahash/s. For comparison, the same card can only try scrypt at around 0.9 megahash/s and PBKDF2 with HMAC-SHA256 iterations at 1.6 megahash/s.

I guess the fact that you are using 132 bits of entropy in your string nullifies the cracking speed increase, but you must make sure your entropy source is not dirty or else you could actually be using less entropy unknowingly. A good example of this is using /dev/urandom.

correct /dev/urandom would be a good source of entropy no known weaknesses plus there are good amount of tools available out there that allows you to choose how many bits of entropy you want before hand many even use 256 bit of entropy which is what I consider way over the top.

[1715229468]

1715229468

[NotATether]

I guess the fact that you are using 132 bits of entropy in your string nullifies the cracking speed increase, but you must make sure your entropy source is not dirty or else you could actually be using less entropy unknowingly. A good example of this is using /dev/urandom.

correct /dev/urandom would be a good source of entropy no known weaknesses plus there are good amount of tools available out there that allows you to choose how many bits of entropy you want before hand many even use 256 bit of entropy which is what I consider way over the top.

No you misunderstood what I was saying, do not use /dev/urandom for cryptographic random number generation because when it runs out of hardware entropy it will use a PNRG to give you the rest of the bits. I recommend using /dev/random instead which will stall when hardware entropy runs out until more is made available.

[ranochigo]

No you misunderstood what I was saying, do not use /dev/urandom for cryptographic random number generation because when it runs out of hardware entropy it will use a PNRG to give you the rest of the bits. I recommend using /dev/random instead which will stall when hardware entropy runs out until more is made available.

FWIW: https://www.2uo.de/myths-about-urandom/.

There seems to be quite a bit of a misconception about /dev/urandom and /dev/random. Bitcoin Core and many other wallets all uses /dev/urandom. There is absolutely nothing wrong with using SHA256, btw. The only important part is for the input to have sufficient randomness.