0
$\begingroup$

Why is that different wallet generating sites give different public and private keys when you enter the same passphrase even though they both use the same Algorithm (Sha 256)? Thank you P.S. Ok...one site is bitaddress.org and the other site is walletgenerator.net. i tried getting a brainwallet and used the exact passphrase but got different keys. The passphrase was: robertarmenkery. Obliged

$\endgroup$
6
  • $\begingroup$ Ok editing done $\endgroup$ Commented May 26, 2021 at 4:56
  • $\begingroup$ No mouse was used, you can skip this step and there is an option for that, then you press the brainwallet option and it will prompt you to enter a passphrase and confirm it by entering it again, after which your private and public keys are generated, there is no mouse involved in the creation of a brainwallet.so this passphrase no matter where you enter it should always give you the same private and public keys since both sites use the same Algorithm. $\endgroup$ Commented May 26, 2021 at 9:32
  • $\begingroup$ I am doing it to see if i come up with the same result....stupid or not is not the question $\endgroup$ Commented May 26, 2021 at 9:34
  • $\begingroup$ Just try to answer the question if you know...otherwise step aside no need for your opinion on whether it is stuipd or not $\endgroup$ Commented May 26, 2021 at 9:37
  • $\begingroup$ @fgrieu it turns about why the same inputs generate two different outputs for the SHA256 then private and public key generation. It turns out one site always uses ECC point compression the other one provides an option for that. $\endgroup$
    – kelalaka
    Commented May 26, 2021 at 10:50

1 Answer 1

1
$\begingroup$

!!!Caveat, Warning!!!

walletgenerator.net is scam!

Anyways be CAREFUL. It is possible to send BTC to a wallet address which is not belong to you and probably is someones else's wallet (probably coder's wallet!!!)

This is called SCAM or THIEF or STEALING BTC which WalletGenerator.net is doing...


They are the same, bitaddress.org uses an option that you missed; compressed and uncompressed addresses. Turn the compressed address on, then you will get the same values.

They both use base58 while displaying the content when converted to hex

uncompressed

pub  00515da4ade2ea43379043341d158ba1637e695c7b9d942422
priv 8012e29482949d92ef7c159f27065ef7bda744cc0dde8551cc324b312ce6736e24 7af43428

and compressed

pub  00b3f704fd7f30d5868f0e070b7adf75703313775717588aa4
priv 8012e29482949d92ef7c159f27065ef7bda744cc0dde8551cc324b312ce6736e24 01 3445217c

0x08 is always prepended, 0x01 is the indicator for the compression, and the last 4 bytes are trimmed double SHA256 checksum.


Note that generating your private key online is really really a bad idea.


Details

Private key part

In the BrainWallet the password has processed as bytes and a SHA256 hash is produces in hex, then 0x80 prepended as the version number. Both values are double hashed with SHA256 and only the first 8 hex values are used for the checksum. The result is displayed in Base58. The below python code can emulate this;

import hashlib
import base58
import base58
from secp256k1 import PrivateKey, PublicKey
from Crypto.Hash import RIPEMD160

password = 'barinwallet online testing'

hashvalue = hashlib.sha256(bytes(password,'utf-8') ).digest()

#Now Wallet format

##prepend the version

privatekeyAndVersion = '80' +  hashvalue.hex() 

print(privatekeyAndVersion)

## Now double SHA256 hashing for the checksum

firsHash = hashlib.sha256(bytes.fromhex(privatekeyAndVersion)).digest()
secondHash = hashlib.sha256(firsHash).digest()

thePrivateKey =  privatekeyAndVersion+(secondHash.hex())[:8]

privatekeyWif = base58.b58encode(bytes.fromhex(thePrivateKey))

print(privatekeyWif)

outputs in Base58,

5KPELN8uHrsjijjmLd2KfkMjVD6SZ1tEbP3GRUgbrdT3SF8ouJs

in hex

80 ce7fe0c608b64e1ca3a16a6292ba12c100104e100650e7f07ef767e4a9fdf60a 36b463fc

Public key part

Both the compressed and uncompressed can be used for the generation of the public key this means that each private key has at least two public keys.

#Same import as above and continue to the file...

def getPublicKey(publicKeyBytes):
    
    publicSHA256 = hashlib.sha256(publicKeyBytes).digest()
    
    h = RIPEMD160.new()
    h.update(publicSHA256)
    hash160 = h.hexdigest()

    hash160app = "00"+ hash160
    
    firsHash = hashlib.sha256(bytes.fromhex(hash160app)).digest()
    secondHash = hashlib.sha256(firsHash).digest()   
    
    checksum = (secondHash.hex())[:8]         
    encoded = "00"+ hash160 + checksum
  
    print("encode BASE58 = ",  base58.b58encode( bytes.fromhex(encoded)) )

privkey = PrivateKey(hashvalue, raw=True)

pubkey_ser = privkey.pubkey.serialize()
pubkey_ser_uncompressed = privkey.pubkey.serialize(compressed=False)
pubkey_ser_compressed = privkey.pubkey.serialize(compressed=True)

getPublicKey(pubkey_ser_uncompressed)
getPublicKey(pubkey_ser_compressed)

This outputs

encode BASE58 =  b'1CCf9cZLuKZRcCacKLScjpLqFN765BFkif'
encode BASE58 =  b'183qCdJNtbzuGcPLrrRZiCo2fn8nJV1Ao4'

So, this matches with bitaddress.org compressed and uncompressed versions.

Important note:

I'm able to get the same values in the walletgenerator, too. This site, however, has a problem that every click to view button produces different values. After many clicks, I'm able to get the same values. Needs to be investigated, since we expect only two public key values, yet the private key values are different.

  • First observation: to see the same result, the number of clicks differs on every instantiation, one had 39 one had 59.

The full code on GitHub.

$\endgroup$
15
  • $\begingroup$ I've looked the code that, it seems the compression is not working correctly, The uncompressed must start with byte 0x04 and must have x and y points, too. But they are almost the same size. $\endgroup$
    – kelalaka
    Commented May 26, 2021 at 12:11
  • $\begingroup$ I reopened the question, on your advice that the crux of the question somewhat is cryptographic. But I hate it when, without explanation, we call public key (I presume for secp256k1) something that's 200 bit in your example. If such things are on-topic, at least there should be a link to some doc stating such blatant deviations of standard vocabulary. I heard that in some cryptocurrency "public key" designates the hash of a public key, and can imagine that in others conventionally some bits are forced to something, or omitted and left as an exercise for the verifier to guess. $\endgroup$
    – fgrieu
    Commented May 26, 2021 at 19:20
  • $\begingroup$ I've posted a bug on the github. They definitely show less, though the internal calculations seem correct. $\endgroup$
    – kelalaka
    Commented May 26, 2021 at 19:23
  • $\begingroup$ My question was, if you go bitaddrss.org. and enter a passphrase you get a publickey and privatekey. Now if you go to walletgenerator.net and enter the same passphrase you entered in bitaddress you will get a completly different public and private keys than what you got at bitaddtess. This is my question. Why the difference between the two sites eventhoigh they both use the same Algorithm $\endgroup$ Commented May 26, 2021 at 22:34
  • 1
    $\begingroup$ Bitcoin originally used base58 to encode addresses for display and manual entry, but since SegWit in 2017 (and TapRoot in 2021) most usage has switched to bech32. (The actual address remains ripemd160(sha256(pubkey)) independent of the encoding.) $\endgroup$ Commented Jun 22 at 0:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.