Is there a way to provide your own self generated seed to Trezor, or do you have to use their code when plugged in? At least the code itself is auditable, but it's not clear to me if the code generates the HD seed itself, of if the code merely provides some amount of randomness which the hardware then uses to create a seed in an unknown and thus not auditable manner.
If it's possible to restore a seed from a backup, then in principle it should be possible to create your own from scratch. 
Topic: Gold collapsing. Bitcoin UP. - page 609. (Read 2032266 times)
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.
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.
even those methods are not absent of troubles
http://www.contravex.com/2014/03/14/on-making-high-entropy-bitcoin-paper-wallets/
http://www.contravex.com/2014/07/17/proof-that-mycelium-knows-how-to-make-a-better-rng-for-its-entropy-dongle-and-isnt/
Second link has a great discussion log about the potential problems of hardware generated entropy
I use trezor but from my impression from a lot of reading is dice are the way to go for fool-proof generation of entropy
yeah, dice is clearly the safest way (as long as they aren't loaded!)
how does Trezor generate entropy?
I would think Trezor would use some sort of method to grab the current dateTime in ticks/seconds to use as one source of entropy. Multiple sources of entropy (that are likely unpredictable) the better.
Keyboard strokes, mouse movements like you mentioned.
I wonder if you could use the current CPU temperature to the first or second decimal place as a source of entropy.
when you generate the Trezor master seed, are you plugged into the pc from which to grab entropy?
Yes, you are plugged in.
Is there a way to provide your own self generated seed to Trezor, or do you have to use their code when plugged in? At least the code itself is auditable, but it's not clear to me if the code generates the HD seed itself, of if the code merely provides some amount of randomness which the hardware then uses to create a seed in an unknown and thus not auditable manner.
Yes, it appears you can input your own dice generated seed although it is seemingly not available from the myTrezor interface.
I am in no way an expert on the matter but from what I understand the code generates the HD seed using randomness provided by a combination of the hardware RNG & the computer's own entropy. The code itself can not generate entropy.
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.
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.
even those methods are not absent of troubles
http://www.contravex.com/2014/03/14/on-making-high-entropy-bitcoin-paper-wallets/
http://www.contravex.com/2014/07/17/proof-that-mycelium-knows-how-to-make-a-better-rng-for-its-entropy-dongle-and-isnt/
Second link has a great discussion log about the potential problems of hardware generated entropy
I use trezor but from my impression from a lot of reading is dice are the way to go for fool-proof generation of entropy
yeah, dice is clearly the safest way (as long as they aren't loaded!)
how does Trezor generate entropy?
I would think Trezor would use some sort of method to grab the current dateTime in ticks/seconds to use as one source of entropy. Multiple sources of entropy (that are likely unpredictable) the better.
Keyboard strokes, mouse movements like you mentioned.
I wonder if you could use the current CPU temperature to the first or second decimal place as a source of entropy.
when you generate the Trezor master seed, are you plugged into the pc from which to grab entropy?
Yes, you are plugged in.
Is there a way to provide your own self generated seed to Trezor, or do you have to use their code when plugged in? At least the code itself is auditable, but it's not clear to me if the code generates the HD seed itself, of if the code merely provides some amount of randomness which the hardware then uses to create a seed in an unknown and thus not auditable manner.
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.
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.
even those methods are not absent of troubles
http://www.contravex.com/2014/03/14/on-making-high-entropy-bitcoin-paper-wallets/
http://www.contravex.com/2014/07/17/proof-that-mycelium-knows-how-to-make-a-better-rng-for-its-entropy-dongle-and-isnt/
Second link has a great discussion log about the potential problems of hardware generated entropy
I use trezor but from my impression from a lot of reading is dice are the way to go for fool-proof generation of entropy
yeah, dice is clearly the safest way (as long as they aren't loaded!)
how does Trezor generate entropy?
I would think Trezor would use some sort of method to grab the current dateTime in ticks/seconds to use as one source of entropy. Multiple sources of entropy (that are likely unpredictable) the better.
Keyboard strokes, mouse movements like you mentioned.
I wonder if you could use the current CPU temperature to the first or second decimal place as a source of entropy.
when you generate the Trezor master seed, are you plugged into the pc from which to grab entropy?
Yes, you are plugged in.
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.
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.
even those methods are not absent of troubles
http://www.contravex.com/2014/03/14/on-making-high-entropy-bitcoin-paper-wallets/
http://www.contravex.com/2014/07/17/proof-that-mycelium-knows-how-to-make-a-better-rng-for-its-entropy-dongle-and-isnt/
Second link has a great discussion log about the potential problems of hardware generated entropy
I use trezor but from my impression from a lot of reading is dice are the way to go for fool-proof generation of entropy
yeah, dice is clearly the safest way (as long as they aren't loaded!)
how does Trezor generate entropy?
I would think Trezor would use some sort of method to grab the current dateTime in ticks/seconds to use as one source of entropy. Multiple sources of entropy (that are likely unpredictable) the better.
Keyboard strokes, mouse movements like you mentioned.
I wonder if you could use the current CPU temperature to the first or second decimal place as a source of entropy.
when you generate the Trezor master seed, are you plugged into the pc from which to grab entropy?
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.
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.
even those methods are not absent of troubles
http://www.contravex.com/2014/03/14/on-making-high-entropy-bitcoin-paper-wallets/
http://www.contravex.com/2014/07/17/proof-that-mycelium-knows-how-to-make-a-better-rng-for-its-entropy-dongle-and-isnt/
Second link has a great discussion log about the potential problems of hardware generated entropy
I use trezor but from my impression from a lot of reading is dice are the way to go for fool-proof generation of entropy
yeah, dice is clearly the safest way (as long as they aren't loaded!)
how does Trezor generate entropy?
I would think Trezor would use some sort of method to grab the current dateTime in ticks/seconds to use as one source of entropy. Multiple sources of entropy (that are likely unpredictable) the better.
Keyboard strokes, mouse movements like you mentioned.
I wonder if you could use the current CPU temperature to the first or second decimal place as a source of entropy.
Gold collapsing. Bitcoin UP.
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.
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.
even those methods are not absent of troubles
http://www.contravex.com/2014/03/14/on-making-high-entropy-bitcoin-paper-wallets/
http://www.contravex.com/2014/07/17/proof-that-mycelium-knows-how-to-make-a-better-rng-for-its-entropy-dongle-and-isnt/
Second link has a great discussion log about the potential problems of hardware generated entropy
I use trezor but from my impression from a lot of reading is dice are the way to go for fool-proof generation of entropy
yeah, dice is clearly the safest way (as long as they aren't loaded!)
how does Trezor generate entropy?
From my understanding an ARM hardware RNG and a combination of entropy derived from the device it is plugged in (computer).
Adequate? I believe so, except there is hardly any way to audit this "randomness"
The issue being that the device could've been tampered with and essentially provide a backdoor to your private key.
On that matter I do believe there is a way to provide your own seed.
This thread is making me paranoid
whereas i trust Slush & Co. and the open source, i'm not sure how to trust the manufacturer. in that sense, i guess one could argue that Armory is more secure since it only involves code and as long as you know how to wipe a hard drive and install a fresh Linux distro along with Armory.
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.
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.
even those methods are not absent of troubles
http://www.contravex.com/2014/03/14/on-making-high-entropy-bitcoin-paper-wallets/
http://www.contravex.com/2014/07/17/proof-that-mycelium-knows-how-to-make-a-better-rng-for-its-entropy-dongle-and-isnt/
Second link has a great discussion log about the potential problems of hardware generated entropy
I use trezor but from my impression from a lot of reading is dice are the way to go for fool-proof generation of entropy
yeah, dice is clearly the safest way (as long as they aren't loaded!)
how does Trezor generate entropy?
From my understanding an ARM hardware RNG and a combination of entropy derived from the device it is plugged in (computer).
Adequate? I believe so, except there is hardly any way to audit this "randomness"
The issue being that the device could've been tampered with and essentially provide a backdoor to your private key.
On that matter I do believe there is a way to provide your own seed.
This thread is making me paranoid
really good explanation from Ben Horowitz:
https://www.youtube.com/watch?v=F2e3RqL4VWs&feature=youtu.be&t=42m34s
https://www.youtube.com/watch?v=F2e3RqL4VWs&feature=youtu.be&t=42m34s
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.
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.
even those methods are not absent of troubles
http://www.contravex.com/2014/03/14/on-making-high-entropy-bitcoin-paper-wallets/
http://www.contravex.com/2014/07/17/proof-that-mycelium-knows-how-to-make-a-better-rng-for-its-entropy-dongle-and-isnt/
Second link has a great discussion log about the potential problems of hardware generated entropy
I use trezor but from my impression from a lot of reading is dice are the way to go for fool-proof generation of entropy
yeah, dice is clearly the safest way (as long as they aren't loaded!)
how does Trezor generate entropy?
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.
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.
even those methods are not absent of troubles
http://www.contravex.com/2014/03/14/on-making-high-entropy-bitcoin-paper-wallets/
http://www.contravex.com/2014/07/17/proof-that-mycelium-knows-how-to-make-a-better-rng-for-its-entropy-dongle-and-isnt/
Second link has a great discussion log about the potential problems of hardware generated entropy
I use trezor but my impression from a lot of reading is dice are the way to go for fool-proof generation of entropy
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.
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.
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.
these are all great pts and easy to understand. i wouldn't just focus on VM's however as many Armory ppl install their offline wallets on simple old pc's.
what is "constant time"?
Improved signing security
For 0.10 the security of signing against unusual attacks has been improved by making the signatures constant time and deterministic.
This change is a result of switching signing to use libsecp256k1 instead of OpenSSL. Libsecp256k1 is a cryptographic library optimized for the curve Bitcoin uses which was created by Bitcoin Core developer Pieter Wuille.
There exist attacks[1] against most ECC implementations where an attacker on shared virtual machine hardware could extract a private key if they could cause a target to sign using the same key hundreds of times. While using shared hosts and reusing keys are inadvisable for other reasons, it's a better practice to avoid the exposure.
OpenSSL has code in their source repository for derandomization and reduction in timing leaks, and we've eagerly wanted to use it for a long time but this functionality has still not made its way into a released version of OpenSSL. Libsecp256k1 achieves significantly stronger protection: As far as we're aware this is the only deployed implementation of constant time signing for the curve Bitcoin uses and we have reason to believe that libsecp256k1 is better tested and more thoroughly reviewed than the implementation in OpenSSL.
[1] https://eprint.iacr.org/2014/161.pdf
Improved signing security
For 0.10 the security of signing against unusual attacks has been improved by making the signatures constant time and deterministic.
This change is a result of switching signing to use libsecp256k1 instead of OpenSSL. Libsecp256k1 is a cryptographic library optimized for the curve Bitcoin uses which was created by Bitcoin Core developer Pieter Wuille.
There exist attacks[1] against most ECC implementations where an attacker on shared virtual machine hardware could extract a private key if they could cause a target to sign using the same key hundreds of times. While using shared hosts and reusing keys are inadvisable for other reasons, it's a better practice to avoid the exposure.
OpenSSL has code in their source repository for derandomization and reduction in timing leaks, and we've eagerly wanted to use it for a long time but this functionality has still not made its way into a released version of OpenSSL. Libsecp256k1 achieves significantly stronger protection: As far as we're aware this is the only deployed implementation of constant time signing for the curve Bitcoin uses and we have reason to believe that libsecp256k1 is better tested and more thoroughly reviewed than the implementation in OpenSSL.
[1] https://eprint.iacr.org/2014/161.pdf
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.
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.
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.
Producing additional ECDSA signatures (additional outbound TXs) from that address has no meaningful effect on security either, provided the k-values used in signature generation remain unknown. As an example, the address 12WRnQR85ZUT7dhmaHBNL5dde2QLYieW6v presently holds $24,000,000 of bitcoins and has made multiple outgoing transactions. For each outgoing transaction from this address, we can inspect the signatures and determine the R values. This doesn't help us "hack" the address to any meaningful extent except in the case where the signatures were produced incorrectly (for example, by using a low-entropy k-value).
Peter, this is quite helpful and i learned something here which i'd like to verify. so, it is not really R that needs to be random, but in fact k that is used to calculate R, correct? that's b/c (x1, y1)=kG where R=x1 (mod N).
furthermore, k not only has to be random, but it has to remain "unknown", correct?
75% correct: k is indeed used to calculate R and it's the variable the software has control over.
But k doesn't have to be random; it just has to be secret (remain unknown) and unique per message1. This is why RFC6979 works: k is deterministic but remains secret so long as the private key remains secret. And it's guaranteed to be unique per message because it's the hash of some mix of the private key and the message (assuming SHA2 collisions are infeasible).
1The "unique-per-message" requirement is in fact so that k remains secret, since it's possible to algebraically solve for k (and also the private key) if two unique messages are signed with the same k value.
is it fair to say that when generating repeated deterministic k's when reusing the same address for tx's, that in fact the k is NOT random since both of the HMAC components are the same (privkey) or similarly structured (tx) ? i may be using HMAC incorrectly but i mean --> k=hash (tx+privkey).
Producing additional ECDSA signatures (additional outbound TXs) from that address has no meaningful effect on security either, provided the k-values used in signature generation remain unknown. As an example, the address 12WRnQR85ZUT7dhmaHBNL5dde2QLYieW6v presently holds $24,000,000 of bitcoins and has made multiple outgoing transactions. For each outgoing transaction from this address, we can inspect the signatures and determine the R values. This doesn't help us "hack" the address to any meaningful extent except in the case where the signatures were produced incorrectly (for example, by using a low-entropy k-value).
Peter, this is quite helpful and i learned something here which i'd like to verify. so, it is not really R that needs to be random, but in fact k that is used to calculate R, correct? that's b/c (x1, y1)=kG where R=x1 (mod N).
furthermore, k not only has to be random, but it has to remain "unknown", correct?
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.
Producing additional ECDSA signatures (additional outbound TXs) from that address has no meaningful effect on security either, provided the k-values used in signature generation remain unknown. As an example, the address 12WRnQR85ZUT7dhmaHBNL5dde2QLYieW6v presently holds $24,000,000 of bitcoins and has made multiple outgoing transactions. For each outgoing transaction from this address, we can inspect the signatures and determine the R values. This doesn't help us "hack" the address to any meaningful extent except in the case where the signatures were produced incorrectly (for example, by using a low-entropy k-value).
Peter, this is quite helpful and i learned something here which i'd like to verify. so, it is not really R that needs to be random, but in fact k that is used to calculate R, correct? that's b/c (x1, y1)=kG where R=x1 (mod N).
furthermore, k not only has to be random, but it has to remain "unknown", correct?
75% correct: k is indeed used to calculate R and it's the variable the software has control over.
But k doesn't have to be random; it just has to be secret (remain unknown) and unique per message1. This is why RFC6979 works: k is deterministic but remains secret so long as the private key remains secret. And it's guaranteed to be unique per message because it's the hash of some mix of the private key and the message (assuming SHA2 collisions are infeasible).
1The "unique-per-message" requirement is in fact so that k remains secret, since it's possible to algebraically solve for k (and also the private key) if two unique messages are signed with the same k value.
out of curiosity to the security experts here.
which do you consider more secure, Armory or Trezor?
which do you consider more secure, Armory or Trezor?
Producing additional ECDSA signatures (additional outbound TXs) from that address has no meaningful effect on security either, provided the k-values used in signature generation remain unknown. As an example, the address 12WRnQR85ZUT7dhmaHBNL5dde2QLYieW6v presently holds $24,000,000 of bitcoins and has made multiple outgoing transactions. For each outgoing transaction from this address, we can inspect the signatures and determine the R values. This doesn't help us "hack" the address to any meaningful extent except in the case where the signatures were produced incorrectly (for example, by using a low-entropy k-value).
Peter, this is quite helpful and i learned something here which i'd like to verify. so, it is not really R that needs to be random, but in fact k that is used to calculate R, correct? that's b/c (x1, y1)=kG where R=x1 (mod N).
furthermore, k not only has to be random, but it has to remain "unknown", correct?
Jump to: