What are the formats for the pub key/priv key/signatures?

Question

How are the public key, private key and the signature decoded to the actual ecc keys? How many bytes are these decoded keys?

Answer 1

Private Keys are typically encoded using WIF (Wallet Import Format). The Public Keys are likewise encoded in WIF format, but with the EOS prefix added to them.

To obtain the actual ECC keys, the keys are decoded, verified against their embedded checksums, then converted into their binary formats.

Answer 2

The encryption is sha256 hash with a 32 byte buffer or string with encoding defaulting to UTF-8.

Here's a link to the official repository for the elliptic curve functions which should be able to give you some more insight into how it works: https://github.com/EOSIO/eosjs-ecc

Further if your question is relating the the registration of the tokens, I highly recommend this offline guide by EOSNY.

Answer 3

Although the answers here are technically correct they lack any real details, so since I've recently had to do this myself, I thought I'd share the real nuts and bolts.

1. An EOS private key is WIF encoded, but with a small caveat. So to get the raw private key from an EOS private key, simply Base58 decode the key. Once decoded, you will find a prefix byte on the front (0x80) which is the same as Bitcoin. The last 4 bytes of this decoded data is a checksum which is made up of a SHA256(SHA256(decoded data minus the last 4 bytes)). So to get the raw private key, Base58 decode, trim the first byte and the last 4 bytes and you should be left with a 32 byte raw private key.

One thing to note here is that EOS have decided in their "wisdom" to diverge from the WIF Standard and not include a compression byte. Usually if a public key is to be derived from this private one, the WIF format will indicate whether this public key should be a compressed one or not by adding an extra 0x01 to the end of the private key. EOS are obviously working on the assumption that because ALL of their public keys are compressed, there's no need to include this 0x01 byte at the end of the private key. (Personally, I think this is insane as WIF is a standard and you should adhere to it or there's no point in having one)

The best and most uniform way of dealing with this is, after removing the prefix byte and checksum, you should check the last byte of the private key being 0x01 or not. If the last byte is 0x01 AND the remaining length is 33 bytes, remove the 0x01 as it's a compression indication byte. Oh yes, make sure you DO also check the length, because a 32 byte private key can also legimately end in 0x01.

2. An EOS public key on the other hand is "sort of" WIF encoded, but not completely so. The main difference with an EOS public key is that there is no prefix byte and the checksum isn't a SHA256(SHA256), it's a RipeMD160. So to get the raw public key, start by chopping off the initial "EOS" string and then simply Base58 decode the public key, trim off the last 4 checksum bytes and you should be left with a 33 byte compressed public key.

If you want to encode a public key to an EOS public key, as I did, then simply RipeMD160 your public key, take the first 4 bytes of the RipeMD160 hash and append it to the end of the public key. Finally, Base58 encode the public key and checksum and add "EOS" to the front of the output.