As mentioned by Peter, a private key is a random 256 bit blob. It is a common oversight that there're no restrictions.
It has to be valid for the secp256k1 curve, which means two conditions:
- cannot be zero
- must be less than the order of the curve (called
n
and has a value of ffffffff ffffffff ffffffff fffffffe baaedce6 af48a03b bfd25e8c d0364141
)
In Javascript you can use ethereumjs-wallet to do this verification: Wallet.fromPrivateKey(<yourkey>)
will throw an exception on an invalid input.
Alternatively you can also use the privateKeyVerify()
method from the underlying library secp256k1
or do it manually with the big number library of your choice.
Will the wallets created at this moment in time be backwards compatible in the future? (Metropolis, Serenity, ...)
I can confirm that MyEtherWallet will always provide backwards capabilities with older version of our encrypted versions, as well as common methods created by other wallets. We are currently in the process of switching to use the same encryption as geth which will (1) help standardize across wallets and (2) make it easier for people to move from MyEtherWallet -> Mist in the future. We also hope to implement other methods of accessing (ie: Jaxx mnemonics, etc.).
For reference, the only things that might change as Ethereum "grows up" is the json / keystore / encryption / etc. formats of the private key. In the end, it's still decrypting to get to the same version of the private key. The way you store it and decrypt it just might change. Most, if not all, wallet providers are going to stay up to date as encryption methods and standards emerge and provide backwards capabilities and cross-capabilities.
How do I verify if the wallets have been created correctly (private key), without first sending a small amount in and out of the wallet?
Personally, I use the MyEtherWallet offline transaction tab to test in and out of any new deep-cold-storage wallet. I suppose you could import the key using a different client and verify it gives you the same address. So, since you are using MyEtherWallet which using Javascript, you could import the unencrypted private key into geth and verify the address, or into eth, or whatever. You will not want to cross-verify with another Javascript implementation (like EthAddress).
Is there anything else I have to consider and I am correct with my assumptions?
I recommend keeping a copy of EthAddress or MyEtherWallet's zipped repo with your cold-storage keys. That way in the future if something changes or something, you'll still have a local version, one that you know works with your private key, to run.
Why are there only third-party web wallet creation pages on the internet and no official ones (yet)? (Maybe because of: Ethereum: "We are making tools for tool-makers“?)
The Ethereum developers have stated that they are working towards a light client. At this point, I find it impressive that they have so many clients in different languages and the Mist / Ethereum Wallet is already as strong as it is. It's been 7 months since launch. Also, keep in mind that the Ethereum Wallet / Mist is so much more than a wallet. A lot of people seem to forget this because that's all they use it for. But in reality, the things they are doing with contracts and tokens are amazing and is what they are focused on at this point.
For reference, here are the three sites mentioned in this thread:
full disclosure: I am co-founder of MyEtherWallet. I try to be objective.
Best Answer
For a numbers of 64 hexadecimal digits, there are
16 ^ 64
=115792089237316195423570985008687907853269984665640564039457584007913129639936
possibilities.For a numbers of 32 hexadecimal digits, there are
16 ^ 32
=340282366920938463463374607431768211456
possibilities.If someone has half your private key, your security has been reduced by a factor of
340282366920938463463374607431768211456
. That's a large factor, but the amount of possibilities they would need to check to brute-force your wallet is still giant. They probably still wouldn't be able to break in.However, to prevent any loss of security if one piece is compromised I would recommend a different scheme, for example:
Generate another random 64-digit hexadecimal number, different from your private key. XOR this new number together with your private key. Now, store the new random number and the result of the XOR operation in the two different locations.
To retrieve your private key, you would need both of the pieces and XOR them together. This way, your security is not compromised at all if someone has some but not all of the pieces.
You can use this same scheme with any number of pieces.
Just be sure you do it right :-)