Not necessarily. Generation of private keys is a rare event, especially with HD wallets. You need a k value for each tranasction.


Nothing, although that's sort like of a brain wallet, and subject to the same flaws. If someone searches through the list of clever but simple methods of picking a key, they will find yours.

Exactly, to make this method secure you'd have to randomly select 75.29379857239479209348238048023740720340% of the way to 2^256, which is the same as just banging out 256 bits of entropy on your keyboard (which may not even be that random depending on how you type, dice would be much better)


The issue with HD wallet seed key generation is even though it happens once, EVERYTHING rests on having true entropy during it's generation, especially for a wallet that may live for decades (which many HD wallets will). However at the same time generating HD seeds or private keys can be done when a machine and wallet software first start when there is the LEAST amount of entropy in a given machine.

For example lets assume someone decides to use a Ubuntu 14.4 VM image pre-configured to run bitcoind automatically. That person starts the VM, logs into a ssh shell, and then issues a bitcoind command to create a new wallet. This a logical user flow, but it also means the system has very little entropy. In this case everything about the system configuration is known ahead of time (it is a pre-configured VM image with known virtual hardware) and the user inputted a minimal amount of new information to capture (even the bitcoind command is known and can be easily guessed). About the only random information the user adds is their personal id/pw, but those might be quite weak because the user figures they are running on a secure home network. In this situation that machine has very little true entropy to use in private key or HD wallet generation. At the same time that key might have a lifetime of decades, during which an attacker can try combinations.

That is why it is important that the random number generator captures as much entropy from as many sources as possible. However most rnd functions do not do so by default and the cryptographically secure methods can vary from OS, i.e. a developer has to find the right function calls for linux, windows, etc.

This is why some people roll dice to generate the seed key for their core wallets, since it is the only way to be absolutely sure. I am positive that right now there probably are several individuals trying combinations on known (to them) weak setups trying to guess HD seeds or private keys.

If you create a HD wallet that ONLY creates multisig transactions, would that prevent addresses from being reused?

HD wallets reuse addresses when people send multiple payments to them. I think that is a weakness. Isn't there another bitcoin payment for where this is not possible, like multisig?

Or you can just use dark wallet (also somewhat experimental though).

i find this fascinating.  so you're saying that even with a perfect RNG, which is software based afaik, unless it has an excellent source of randomness (such as mouse movement, static off embedded chips, etc) it won't generate truly random privkeys?

how does Armory then create secure deterministic wallets then?  how would one generate the required entropy from the old offline pc's used to install such a program?  the usual method is to just install Armory and go right to wallet creation.

out of curiosity to the security experts here.

which do you consider more secure, Armory or Trezor?

Yes you have that correct. It is k that needs to be protected because once you know the k value used in a signature you can calculate the private key from the signature and public key.

The issue with using the same R value (which is derived from the same k value) in two different signatures is that it then becomes possible to calculate the k value used using both signatures, and once you have the k value you can calculate the private key.

Do read this link if you are interested in the topic. It explains all of the math required to understand ECDSA and DSA, but in an understandable manner and also covers the question above well.

http://kakaroto.homelinux.net/2012/01/how-the-ecdsa-algorithm-works/

Edit: looks like Peter beat me in replying by ~1min. The reason why the RFC6979 approach works is because you are guaranteed to use a different k value for each different message (due to hashing the key & message). The only time RFC6979 would repeat a k value is if the message was exactly the same, in which case you are not producing two separate signature but just repeating the same one done before.

I am by no means an expert on this topic, most of what I learned came from a discussion in the Armory section which resulting in Armory changing/improving it's sources of entropy. (It's original method was probably good enough, but they were trying to further strengthen it) So the following is mostly from what I took away from following that discussion.

Even if a VM configuration is fully known and static, there can be enough entropy generated during boot time but it needs to be carefully captured and a programmer needs to know the right calls to do this. These sources can include: the current time/date, the MAC address generated by VMWare or kvm (which is not fully random), the I/O performance of the underlying storage system which can effect various orderings to the boot sequence, the times of service start initiations and completions, etc.

In a limited environment where bitcoind automatically starts as a service on boot in a known VM configuration and creates a new wallet.dat file before a user even tries to login, it is necessary to capture every possible source of entropy.

The only reason I brought this up is even though RFC6979 looks to be a great solution for safe generation of k values, wallet software still needs to correctly generate crytographically random numbers for wallet generation, which is arguably even more important.