Questions on public addresses

In the whitepaper it says that addresses are the last 20 bytes of a SHA-3 hash of the public key. Could anybody explain how this relates to the private key. In Bitcoin if you're creating a brain wallet, you can do something like -

Private Key Seed : donteverusethisseed123
Private Key : 5JAyXYqnR6N123LWq64JHC74CeXrHPtNMq6xRuHvk7Aip2BrYQ3
Public Key : 1BZgEQ6sogmehQVFRJsLYmU8ZqaaQX5WKh

How does it work in Ethereum? It would be nice if there was a bitaddress.org type site for Ethereum, it would at least be a step towards people understanding how addresses were calculated.

Also, is the algorithm finalised yet? If I was to spend time making a vanity address right now, what's the chance that something changes in the future and my address is useless. Thanks!

Comments

  • chris613chris613 Member Posts: 93 ✭✭
    Let me attempt to explain the address creation step by step, reading from common.cpp's KeyPair::create(). This is what is run when you click Tools->New Address in althezero.

    1. A 256-bit Private Key is initialized with random data

    2. The secret is tested for being an acceptable key, which just means non-zero and less than "the order of the curve" which I think is an upper range after which keys are weak (corrections welcome).

    3. A 512-bit Public Key is generated from that secret and tested by secp256k1_ecdsa_pubkey_verify. I don't fully understand this check without more research (key types), but my understanding is that any number can be a valid secret key, and generating a public key from it should always be reliable (corrections welcome).

    4. The Public Key is hashed with SHA-3 to produce a 256-bit output. The upper 96 bits are discarded, and the lower 160 bits become the Address.

    If you #define ETH_ADDRESS_DEBUG 1 at the top of Common.cpp you can get output like this:
    ---- ADDRESS -------------------------------
    SEC: cd244b3015703ddf545595da06ada5516628c5feadbf49dc66049c4b370cc5d8
    PUB: bb48ae3726c5737344a54b3463fec499cb108a7d11ba137ba3c7d043bd6d7e14994f60462a3f91550749bb2ae5411f22b7f9bee79956a463c308ad508f3557df
    ADR: 89b44e4d3c81ede05d0f5de8d1a68f754d73d997


    If you wanted to generate from a seed, brain wallet style, then it would make sense to SHA-3 your seed string to initialize the Private Key in step 1. Generally that's not recommended, though, let it be random or let it be cracked.

    For vanity addresses one thing to note is that AFAICT ethereum has not adopted the base58check encoding convention that turns the hex numbers into something more readable (and typo resistant), so unless that convention is adopted your vanity space is hex only. I haven't looked at vanity generators but I assume they simply choose a random secret key and start incrementing it until they find what they're looking for in the output. Corrections welcome.

    No idea if the algorithm is "finalised", but it seems so simple that I don't see why it would change.


  • salhadaarsalhadaar Member Posts: 26
    Ok, thanks a lot for this explanation. I guess I need to see whether the Ethereum team decide to introduce an extra base58-type step.

    Yes, it is quite simple. Bitcoin seems to add a few extra steps that aren't really needed.
  • chris613chris613 Member Posts: 93 ✭✭
    I've never understood exactly why bitcoin addresses use the extra RIPEMD-160 + double SHA-256 steps. Is it just for more security headroom in case of hash weaknesses?
  • StephanTualStephanTual London, EnglandMember, Moderator Posts: 1,282 mod
    edited March 2014
  • KenKen Member Posts: 10
    edited March 2014
    I'm not a cryptographer - so if there is one here who feels the need to thrash me publicly for being ignorant, I only ask that by the end of the beating I know more than I do now. ;)

    When I read in the white paper that the public key was then hashed with SHA-3, and the lower 160 bits were used as the address, I immediately thought, "Doesn't using less than the entire SHA-3 output increase our chances of an address collision?"

    So - I think this might be a good place to ask that question. :) Since it was mentioned above.

    Thanks for taking the time to help bring me up to speed. I suspect the answer may be that the numbers are so large that it won't matter - but my gut is telling me to ask anyway.

    Ken
  • salhadaarsalhadaar Member Posts: 26
    Ken I had the same thought. I am not a cryptographer either, nor do I play one on TV.
  • chris613chris613 Member Posts: 93 ✭✭
    I would also like to better understand the answer to Ken's question. It seems like some marginal convenience being added at direct cost to long term security, but maybe there is something subtle about these public keys that I don't know about. I think that even if it is reducing the collision space to 160 bits that's still far too many operations to brute force. The numbers are so large it doesn't matter, but 160-bit too large to matter isn't nearly as good as 256-bit too large to matter IMO.

    The only theory I can offer is that likely attacks on the ECC curve algorithm are expected to reduce the effective bit strength on the original 256-bit secret, but not in ways that would make 160-bit suffix addresses any easier to collide. AFAIK the attacks against public key crypto generally allow you to find a secret from a pubkey in fewer bits of search space. In this case using a partial pubkey is safer from those sorts of attacks. This also explains why you don't need the "headroom" against future attacks that is usually baked into key lengths when you are choosing an address length, making a 160-bit address resistant to future attacks even when a 160-bit key might not be. I don't know if this is really the case, or if this even makes sense given the way pubkey hashes are used in ethereum, but it makes some intuitive (if uncertain feeling) sense to me.
  • VitalikButerinVitalikButerin Administrator Posts: 84 admin
    ECC provides 128 bits of security. Hashes provide 160 bits. So theoretically we would be fine lopping off 32 more bits off the address, but we don't want to do that because then the risk of a birthday collision (64 bits) would be too high (vs 80 bits now).
  • chris613chris613 Member Posts: 93 ✭✭
    Well there's a simple answer, then! If the starting strength is only 128 bits, there is no reduction going on at all.

    I had momentarily forgotten that private key size != key strength like it does in a symmetric system; ECC is so efficient in this regard that it's easy to miss. By contrast, a 3072 bit RSA key is required to get 128 bits of strength.

    Thanks!
  • romanmromanm Member Posts: 37
    @vitalik? Why no Base58 in last step ?
  • jjjjjj Member Posts: 9
    OP: https://github.com/ethereum/tryethereum is a local playground including creating keys and addresses.
  • SulkairSulkair United StatesMember Posts: 6
    edited March 2016
    Removed
    Post edited by Sulkair on
Sign In or Register to comment.