user10377: 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.

user10377: 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
04**6cb84859e85b1d9a27e060fdede38bb818c93850fb6e42d9c7e4bd879f8b9153fd94ed48e1f63312dce58f4d778ff45a2e5abb08a39c1bc0241139f5e54de7df**

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.

user26719: 
Start with the public key bytes (a bytestring of length 64)
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.
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.
Update 2: In the comment thread, I speculated about where Ethereum's hash function diverged from the SHA3 standard. My speculation was mistaken, the version I thought was the incompatible change is the version Ethereum in fact uses. Thanks to work by Eric McCarthy, who chased this down in great detail. Please see this comment below for more details.

10377: <p>For a given private key generated by <a href="https://www.myetherwallet.com/" rel="noreferrer">MyEtherWallet</a>, I would like to see I have the tools to independently arrive at similar results. </p>

<p>Wrote a wrapper around <a href="https://github.com/gvanas/KeccakCodePackage/blob/master/Standalone/CompactFIPS202/Keccak-readable-and-compact.c" rel="noreferrer">Keccak</a> 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 <a href="http://www.di-mgt.com.au/sha_testvectors.html" rel="noreferrer">Test Vectors</a>. Would like to apply it with bitcoin-explorer (<strong>bx</strong>) <strong>version3</strong> 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 <strong>bx version3</strong>, and update this <a href="https://github.com/libbitcoin/libbitcoin/wiki/Altcoin-Version-Mappings" rel="noreferrer">Wiki</a> concerning the application of <strong>bx</strong> to altcoins.</p>
 10377: <p>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 <a href="https://github.com/gvanas/KeccakCodePackage/blob/master/Standalone/CompactFIPS202/Keccak-readable-and-compact.c" rel="nofollow">KeccakCodePackage</a>. </p>

<p>However, a hack to main.c and genKATShortMsg.cpp from <a href="https://github.com/gvanas/KeccakTools" rel="nofollow">KeccakTools</a> will yield proper ETH addresses, detailed in a comment above. </p>

<p>For the following ETH private key: <code>b205a1e03ddf50247d8483435cd91f9c732bad281ad420061ab4310c33166276</code>. The associated public key results from using bx. </p>

<pre><code>% echo b205a1e03ddf50247d8483435cd91f9c732bad281ad420061ab4310c33166276 | bx ec-to-public -u
04**6cb84859e85b1d9a27e060fdede38bb818c93850fb6e42d9c7e4bd879f8b9153fd94ed48e1f63312dce58f4d778ff45a2e5abb08a39c1bc0241139f5e54de7df**
</code></pre>

<p>The following <code>KeccakTools/Example\ trails</code> configuration file is needed to to execute<br>
<code>../bin/KeccakTools</code> from the <code>Example\ trails</code> directory.</p>

<pre><code>% cat ShortMsgKAT.txt

\# Algorithm Name: NOT_FIPS202_SHA3_256
\# Principal Submitter: SKAHT
Len = 512
Msg = 6cb84859e85b1d9a27e060fdede38bb818c93850fb6e42d9c7e4bd879f8b9153fd94ed48e1f63312dce58f4d778ff45a2e5abb08a39c1bc0241139f5e54de7df
</code></pre>

<p>A file called <code>ShortMsgKAT_keccak-256.txt</code> is created from executing the <code>KeccakTools</code> that will contain:</p>

<pre><code>MD = 787EC5A5313A976F7BDF9EED**AFDEFC1937AE294C3BD55386A8B9775539D81653** 
</code></pre>

<p>when the hack documented above is performed to build <strong>KeccakTools</strong>.</p>
 26719: <ol>
<li>Start with the public key bytes (a bytestring of length 64)</li>
<li>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.</li>
<li>Drop the first 12 bytes. You should now have a bytestring of length 20, the Ethereum address associated with your public key.</li>
</ol>

<p><strong>Update:</strong> 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. <a href="https://github.com/swaldman/consuela/blob/c373dd6c194ba8671de1d37245b5a34a575a583d/src/main/scala/com/mchange/sc/v1/consuela/crypto/package.scala#L294-L298" rel="nofollow noreferrer">here</a>. <code>Curve</code> represents the named eliptic curve <code>secp256k1</code>. 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.</p>

<p><strong>Update 2:</strong> In the comment thread, I speculated about where Ethereum's hash function diverged from the SHA3 standard. My speculation was mistaken, the version I thought was the incompatible change is the version Ethereum in fact uses. Thanks to work by <a href="https://www.kestrel.edu/home/people/mccarthy/" rel="nofollow noreferrer">Eric McCarthy</a>, who chased this down in great detail. Please see <a href="https://bitcoin.stackexchange.com/questions/42055/what-is-the-approach-to-calculate-an-ethereum-address-from-a-256-bit-private-key/42057#comment102225_42057">this comment below</a> for more details.</p>
