Bitcoin Forum
March 19, 2024, 10:09:01 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Poll
Question: Will you support Gavin's new block size limit hard fork of 8MB by January 1, 2016 then doubling every 2 years?
1.  yes
2.  no

Pages: « 1 ... 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 [949] 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 ... 1557 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 2032123 times)
cypherdoc (OP)
Legendary
*
Offline Offline

Activity: 1764
Merit: 1002



View Profile
December 23, 2014, 06:28:33 PM
 #18961


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.
1710842941
Hero Member
*
Offline Offline

Posts: 1710842941

View Profile Personal Message (Offline)

Ignore
1710842941
Reply with quote  #2

1710842941
Report to moderator
There are several different types of Bitcoin clients. The most secure are full nodes like Bitcoin Core, which will follow the rules of the network no matter what miners do. Even if every miner decided to create 1000 bitcoins per block, full nodes would stick to the rules and reject those blocks.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
brg444
Hero Member
*****
Offline Offline

Activity: 644
Merit: 504

Bitcoin replaces central, not commercial, banks


View Profile
December 23, 2014, 06:35:03 PM
Last edit: December 23, 2014, 06:46:42 PM by brg444
 #18962


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 Offline

Activity: 1764
Merit: 1002



View Profile
December 23, 2014, 06:47:25 PM
 #18963


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 Offline

Activity: 1764
Merit: 1002



View Profile
December 23, 2014, 07:10:46 PM
 #18964

really good explanation from Ben Horowitz:

https://www.youtube.com/watch?v=F2e3RqL4VWs&feature=youtu.be&t=42m34s
brg444
Hero Member
*****
Offline Offline

Activity: 644
Merit: 504

Bitcoin replaces central, not commercial, banks


View Profile
December 23, 2014, 07:17:42 PM
 #18965


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  Huh

"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 Offline

Activity: 1764
Merit: 1002



View Profile
December 23, 2014, 07:32:37 PM
 #18966


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  Huh

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 Offline

Activity: 1764
Merit: 1002



View Profile
December 23, 2014, 07:59:00 PM
 #18967

Gold collapsing.  Bitcoin UP.
smoothie
Legendary
*
Offline Offline

Activity: 2492
Merit: 1473


LEALANA Bitcoin Grim Reaper


View Profile
December 23, 2014, 08:38:45 PM
 #18968


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 Offline

Activity: 1764
Merit: 1002



View Profile
December 23, 2014, 08:40:37 PM
 #18969


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
Hero Member
*****
Offline Offline

Activity: 644
Merit: 504

Bitcoin replaces central, not commercial, banks


View Profile
December 23, 2014, 08:51:03 PM
 #18970


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 Offline

Activity: 1153
Merit: 1000


View Profile
December 23, 2014, 09:46:38 PM
 #18971


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
Hero Member
*****
Offline Offline

Activity: 644
Merit: 504

Bitcoin replaces central, not commercial, banks


View Profile
December 23, 2014, 09:56:26 PM
 #18972


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 Offline

Activity: 1400
Merit: 1006



View Profile
December 23, 2014, 10:12:49 PM
 #18973

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 Offline

Activity: 1260
Merit: 1008


View Profile
December 23, 2014, 10:27:00 PM
 #18974

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


A 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 Offline

Activity: 1162
Merit: 1007



View Profile
December 23, 2014, 11:29:24 PM
 #18975

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


A 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):

Quote from: N Benger et al
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:

  (x1, y1) = 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…



Run Bitcoin Unlimited (www.bitcoinunlimited.info)
molecular
Donator
Legendary
*
Offline Offline

Activity: 2772
Merit: 1019



View Profile
December 24, 2014, 10:40:17 AM
 #18976

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 Offline

Activity: 2772
Merit: 1019



View Profile
December 24, 2014, 10:43:04 AM
 #18977

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 Offline

Activity: 2968
Merit: 1197



View Profile
December 24, 2014, 10:47:59 AM
 #18978

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.

randomguy7
Hero Member
*****
Offline Offline

Activity: 527
Merit: 500


View Profile
December 24, 2014, 12:59:20 PM
 #18979

I use http://www.issihosts.com/haveged/ to get more entropy (based on "processor flutter").
picolo
Hero Member
*****
Offline Offline

Activity: 1022
Merit: 500



View Profile
December 24, 2014, 01:16:03 PM
 #18980

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  Wink
Pages: « 1 ... 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 [949] 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 ... 1557 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!