For a given private key generated by MyEtherWallet, I would like to see I have the tools to independently arrive at similar results.

Wrote a wrapper around Keccak to accept both hexadecimal and ASCII inputs to be sha3-224 or sha3-256 or sha3-384 or sha3-512 hashed. Hashes are consistent with Test Vectors. Would like to apply it with bitcoin-explorer (bx) version3 commands to see if I can synthesize ETH addresses. If successful at synthesizing addresses for ETH, XMR, and MAX altcoins, I go through the effort of submitting a pull request to add sha3 hashing capabilities to bx version3, and update this Wiki concerning the application of bx to altcoins.

  • To calculate a public address using bx's secp256k1 capabilities is simply: % echo fc8fba997174132184998ab82b28e441e80c73236ccaf8b6a1efadc33febecfc | bx ec-to-public -u 04cf90dc2b34937fff7cf1eb4b260f1e5610231134b864761e508505938bbef8fc00aeb265797336b74146e018da7b78070f1f1072540a2c3fe83637ca5d605b3c – skaht Dec 30 '15 at 3:38
  • Issue I'm having is with Keccak sha3-256. Dropping the 04 from the address above into a sha3-256 and taking the lower 20 bytes to the right isn't working. – skaht Dec 30 '15 at 3:48
  • % ./keccak -x -256 cf90dc2b34937fff7cf1eb4b260f1e5610231134b864761e508505938bbef8fc00aeb265797336b74146e018da7b78070f1f1072540a2c3fe83637ca5d605b3c b992c6ced76bf40cfe875feb99d0dfbbb6eb831dc0605a82d084e5d930bc6631 – skaht Dec 30 '15 at 3:52
  • How is it guaranteed that addresses are unique within the network then? What if I happen to have generated the same private key as someone else, then I will have the same address? Or, a more likely scenario, what if my private key is different to someone else, but it maps to the same address? – Graeme Pyle May 26 '16 at 7:14
  • Q1) There is no guarantee that two different private keys can't have the same public ETH public address, just very improbable. Q2) If there is a collision between the private keys, s/he that spends first gets to reap booty at the loss of another. More likely to loose your funds at a bank for whatever reason... – skaht Jun 24 '16 at 0:27
  1. Start with the public key bytes (a bytestring of length 64)
  2. Of that public key, take the Keccak-256 hash used ubiquitously by Ethereum (make sure you get that right, as the ultimately standardized SHA3-256 hash differs). You should now have a bytestring of length 32.
  3. Drop the first 12 bytes. You should now have a bytestring of length 20, the Ethereum address associated with your public key.

Update: Oops! I see you want it from the private key, not the public key. That's harder. You have to first derive the public key from the private key, which is best with the help of an EC crypto library. I can show you some example code in Scala, but the EC math is mostly a black box to me. First, interpret the 256 bit private key as an unsigned big integer. Then, see e.g. here. Curve represents the named eliptic curve secp256k1. The details of the math are, alas, beyond me, but hopefully in whatever environment you are coding you have access to a high quality crypto library.

  • (sorry! my initial response misread the post as starting from the public key. i've added an update with imperfect hints on deriving the public from the private key.) – Steve Waldman Dec 29 '15 at 5:47
  • I'm very confused, per ETHEREUM: A SECURE DECENTRALISED GENERALISED TRANSACTION LEDGER I may format as typewriter text, e.g. the Keccak-256 hash function (as per the winning entry to the SHA-3 contest) is denoted KEC (and generally referred to as plain Keccak). FIPS202_SHA3_256 amounts to being Keccak(1088, 512, input, inputByteLen, 0x06, output, 32). What are the Keccak parameters for Keccak-256? – skaht Dec 29 '15 at 22:52
  • Request for comment / opinions barely mentions sha3. – skaht Dec 29 '15 at 23:02
  • Per Instead of addresses being the RIPEMD160 hash of the SHA256 hash of the public key prefixed with 04, addresses are simply the last 20 bytes of the SHA3 hash of the public key. – skaht Dec 29 '15 at 23:37
  • So, it's ugly. But the padding strategy of Keccak changed as the function was stewarded through the SHA3 standardization process. The relevant change I think happens at version 3.0 here, see especially padding.h and padding.cpp. – Steve Waldman Dec 30 '15 at 9:25

For computing ETH addresses, the last 20 bytes of a Keccak-256 hash are used. Must Not use the NIST FIPS 202 flavors of Keccak such as KeccakCodePackage.

However, a hack to main.c and genKATShortMsg.cpp from KeccakTools will yield proper ETH addresses, detailed in a comment above.

For the following ETH private key: b205a1e03ddf50247d8483435cd91f9c732bad281ad420061ab4310c33166276. The associated public key results from using bx.

% echo b205a1e03ddf50247d8483435cd91f9c732bad281ad420061ab4310c33166276 | bx ec-to-public -u

The following KeccakTools/Example\ trails configuration file is needed to to execute
../bin/KeccakTools from the Example\ trails directory.

% cat ShortMsgKAT.txt

\# Algorithm Name: NOT_FIPS202_SHA3_256
\# Principal Submitter: SKAHT
Len = 512
Msg = 6cb84859e85b1d9a27e060fdede38bb818c93850fb6e42d9c7e4bd879f8b9153fd94ed48e1f63312dce58f4d778ff45a2e5abb08a39c1bc0241139f5e54de7df

A file called ShortMsgKAT_keccak-256.txt is created from executing the KeccakTools that will contain:

MD = 787EC5A5313A976F7BDF9EED**AFDEFC1937AE294C3BD55386A8B9775539D81653** 

when the hack documented above is performed to build KeccakTools.

  • The skinny for calculating Ethereum addresses is also found at this location. Deduced that Ethereum does not natively support compressed private keys. – skaht Jun 24 '16 at 0:31

Your Answer


By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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