cypherdoc (OP)
Legendary
Offline
Activity: 1764
Merit: 1002
|
|
December 23, 2014, 06:28:33 PM |
|
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.
|
|
|
|
brg444
|
|
December 23, 2014, 06:35:03 PM Last edit: December 23, 2014, 06:46:42 PM by brg444 |
|
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
|
"I believe this will be the ultimate fate of Bitcoin, to be the "high-powered money" that serves as a reserve currency for banks that issue their own digital cash." Hal Finney, Dec. 2010
|
|
|
cypherdoc (OP)
Legendary
Offline
Activity: 1764
Merit: 1002
|
|
December 23, 2014, 06:47:25 PM |
|
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?
|
|
|
|
cypherdoc (OP)
Legendary
Offline
Activity: 1764
Merit: 1002
|
|
December 23, 2014, 07:10:46 PM |
|
|
|
|
|
brg444
|
|
December 23, 2014, 07:17:42 PM |
|
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
|
"I believe this will be the ultimate fate of Bitcoin, to be the "high-powered money" that serves as a reserve currency for banks that issue their own digital cash." Hal Finney, Dec. 2010
|
|
|
cypherdoc (OP)
Legendary
Offline
Activity: 1764
Merit: 1002
|
|
December 23, 2014, 07:32:37 PM |
|
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.
|
|
|
|
cypherdoc (OP)
Legendary
Offline
Activity: 1764
Merit: 1002
|
|
December 23, 2014, 07:59:00 PM |
|
Gold collapsing. Bitcoin UP.
|
|
|
|
smoothie
Legendary
Offline
Activity: 2492
Merit: 1473
LEALANA Bitcoin Grim Reaper
|
|
December 23, 2014, 08:38:45 PM |
|
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.
|
███████████████████████████████████████
,╓p@@███████@╗╖, ,p████████████████████N, d█████████████████████████b d██████████████████████████████æ ,████²█████████████████████████████, ,█████ ╙████████████████████╨ █████y ██████ `████████████████` ██████ ║██████ Ñ███████████` ███████ ███████ ╩██████Ñ ███████ ███████ ▐▄ ²██╩ a▌ ███████ ╢██████ ▐▓█▄ ▄█▓▌ ███████ ██████ ▐▓▓▓▓▌, ▄█▓▓▓▌ ██████─ ▐▓▓▓▓▓▓█,,▄▓▓▓▓▓▓▌ ▐▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▌ ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓─ ²▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓╩ ▀▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▀ ²▀▀▓▓▓▓▓▓▓▓▓▓▓▓▀▀` ²²² ███████████████████████████████████████
| . ★☆ WWW.LEALANA.COM My PGP fingerprint is A764D833. History of Monero development Visualization ★☆ . LEALANA BITCOIN GRIM REAPER SILVER COINS. |
|
|
|
cypherdoc (OP)
Legendary
Offline
Activity: 1764
Merit: 1002
|
|
December 23, 2014, 08:40:37 PM |
|
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?
|
|
|
|
brg444
|
|
December 23, 2014, 08:51:03 PM |
|
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.
|
"I believe this will be the ultimate fate of Bitcoin, to be the "high-powered money" that serves as a reserve currency for banks that issue their own digital cash." Hal Finney, Dec. 2010
|
|
|
rocks
Legendary
Offline
Activity: 1153
Merit: 1000
|
|
December 23, 2014, 09:46:38 PM |
|
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.
|
|
|
|
brg444
|
|
December 23, 2014, 09:56:26 PM |
|
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.
|
"I believe this will be the ultimate fate of Bitcoin, to be the "high-powered money" that serves as a reserve currency for banks that issue their own digital cash." Hal Finney, Dec. 2010
|
|
|
justusranvier
Legendary
Offline
Activity: 1400
Merit: 1013
|
|
December 23, 2014, 10:12:49 PM |
|
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.
|
|
|
|
sickpig
Legendary
Offline
Activity: 1260
Merit: 1008
|
|
December 23, 2014, 10:27:00 PM |
|
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.pdfA countermeasure against http://en.m.wikipedia.org/wiki/Timing_attack?
|
Bitcoin is a participatory system which ought to respect the right of self determinism of all of its users - Gregory Maxwell.
|
|
|
Peter R
Legendary
Offline
Activity: 1162
Merit: 1007
|
|
December 23, 2014, 11:29:24 PM |
|
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.pdfA countermeasure against http://en.m.wikipedia.org/wiki/Timing_attack? Although I can't think of a practical scenario where a typical user would ever be exposed to this, yes, the concern is side-channel attacks (e.g., a timing attack): ABSTRACT. We apply the Flush+Reload side-channel attack based on cache hits/misses to extract a small amount of data from OpenSSL ECDSA signature requests. We then apply a “standard” lattice technique to extract the private key, but unlike previous attacks we are able to make use of the side-channel information from almost all of the observed executions. This means we obtain private key recovery by observing a relatively small number of executions, and by expending a relatively small amount of post-processing via lattice reduction. We demonstrate our analysis via experiments using the curve secp256k1 used in the Bitcoin protocol. In particular we show that with as little as 200 signatures we are able to achieve a reasonable level of success in recovering the secret key for a 256-bit curve. This is significantly better than prior methods of applying lattice reduction techniques to similar side channel information. From: N. Benger, J van de Pol, N.P. Smart, Y. Yar, “‘Ooh Aah... Just a Little Bit’: A small amount of side channel can go a long way,” from International Association for Cryptologic Research, 2014.Basically, there's a bunch of number crunching done by your CPU each time your wallet signs a bitcoin transaction. If a "constant time" algorithm is used, it takes the same amount of time to produce an ECDSA signature regardless of the message being signed (or the k value or private key used). If the signing time is always the same, then an attacker cannot learn anything about your private keys by inspecting the timing variations (since there are none) when you sign various messages. Where does "timing variation" come from? As one example, your wallet needs to perform the following elliptic curve point multiplication as part of the ECDSA signing process: (x 1, y 1) = k x G There's several different algorithms that can be used to carry out this multiplication. The simplest is probably the "double and add" method. However, the amount of time it takes this algorithm to execute depends on the specific value of k (G is always constant for bitcoin). On the other hand, the "Montgomery Ladder" approach computes the point multiplication in a fixed amount of time (regardless of the specific value of k). So a wallet would use a constant-time approach like the Montgomery Ladder technique rather than the double-and-add method as part of ensuring "constant time" ECDSA signatures. Why does "constant time" matter? In most cases I don't think it really does. But let's imagine a contrived scenario where an attacker can get my wallet to produce several bitcoin-signed message with one of its funded private keys. The attacker can pass it any piece of text, and my wallet will sign that text and relay the signature back to the attacker. Normally this shouldn't be a problem because bitcoin-signed messages are safe. But if the attacker can somehow accurately time how long my CPU takes to produce each signature, and then fiddle with the messages that it's requesting my wallet to sign, perhaps it can leach out enough information to determine my private key… I think deterministic signatures are much more important than constant-time signatures (there's been a non-trivial amount of funds lost due to the repeat k-value problem but I doubt a single satoshi has ever been lost due to a genuine side-channel attack). Someone like gmaxwell could comment better on the practical risks here…
|
|
|
|
molecular
Donator
Legendary
Offline
Activity: 2772
Merit: 1019
|
|
December 24, 2014, 10:40:17 AM |
|
out of curiosity to the security experts here.
which do you consider more secure, Armory or Trezor?
I'm not a security expert, but I would say trezor (with passphrase). It's also easier to use securely.
|
PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0 3F39 FC49 2362 F9B7 0769
|
|
|
molecular
Donator
Legendary
Offline
Activity: 2772
Merit: 1019
|
|
December 24, 2014, 10:43:04 AM |
|
I wonder if you could use the current CPU temperature to the first or second decimal place as a source of entropy.
The least significant bit of a 16 bit audio sample always seemed a good idea to me. The nice thing about randomness: you can mix many sources (using xor or whatever) and you'll not lose anything even if one source is bad.
|
PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0 3F39 FC49 2362 F9B7 0769
|
|
|
smooth
Legendary
Offline
Activity: 2968
Merit: 1198
|
|
December 24, 2014, 10:47:59 AM |
|
I wonder if you could use the current CPU temperature to the first or second decimal place as a source of entropy.
The least significant bit of a 16 bit audio sample always seemed a good idea to me. The nice thing about randomness: you can mix many sources (using xor or whatever) and you'll not lose anything even if one source is bad. Unfortunately what you may get wrong if you are too careless about this is how much useful randomness you have. If I recall correctly some sources in the Linux kernel rng are added to the pool but counted as zero entropy.
|
|
|
|
|
picolo
|
|
December 24, 2014, 01:16:03 PM |
|
out of curiosity to the security experts here.
which do you consider more secure, Armory or Trezor?
I'm not a security expert, but I would say trezor (with passphrase). It's also easier to use securely. Trezor seems safe. A simple paper wallet generated offline on a new computer running linux is safe too
|
|
|
|
|