Bitcoin Forum
December 18, 2017, 09:06:06 PM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
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 ... 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 1000 ... 1558 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 2022644 times)
brg444
Hero Member
*****
Offline Offline

Activity: 644

Bitcoin replaces central, not commercial, banks


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


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

Posts: 1513631166

View Profile Personal Message (Offline)

Ignore
1513631166
Reply with quote  #2

1513631166
Report to moderator
1513631166
Hero Member
*
Offline Offline

Posts: 1513631166

View Profile Personal Message (Offline)

Ignore
1513631166
Reply with quote  #2

1513631166
Report to moderator
1513631166
Hero Member
*
Offline Offline

Posts: 1513631166

View Profile Personal Message (Offline)

Ignore
1513631166
Reply with quote  #2

1513631166
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
rocks
Legendary
*
Offline Offline

Activity: 1149


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


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

Bitcoin replaces central, not commercial, banks


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


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



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

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: 1232


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

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: 1064



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

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: 2436



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

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: 2436



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

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: 1624



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

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: 528


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

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

Activity: 756


🌟ATLANT ICO 24hr LEFT🌟


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

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

NewLiberty
Legendary
*
Offline Offline

Activity: 1190


Gresham's Lawyer


View Profile WWW
December 24, 2014, 02:29:48 PM
 #18992

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

Did you miss Rocks post above discussing the vulnerability of using new computers, or just saying it is safe enough for you because you disagree with the risk?

FREE MONEY1 Bitcoin for Silver and Gold NewLibertyDollar.com and now BITCOIN SPECIE (silver 1 ozt) shows value by QR
Bulk premiums as low as .0012 BTC "BETTER, MORE COLLECTIBLE, AND CHEAPER THAN SILVER EAGLES" 1Free of Government
thezerg
Legendary
*
Offline Offline

Activity: 1246


View Profile
December 24, 2014, 03:33:47 PM
 #18993

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

One idea is that a small custom device like the trezor could have put an accelerometer in for just a few bucks

Haveged might be really bad on an isolated device.  No interrupts coming in...
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
December 24, 2014, 05:58:44 PM
 #18994

Mycelium Entropy:

https://www.indiegogo.com/projects/mycelium-entropy
rocks
Legendary
*
Offline Offline

Activity: 1149


View Profile
December 24, 2014, 07:54:08 PM
 #18995

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


Those are both really cool projects, thanks for sharing. If anything their existence shows that generating true randomness on deterministic computers is hard and it is necessary to resort to the variability that is found in the real physical world.
lebing
Legendary
*
Offline Offline

Activity: 1288

Enabling the maximal migration


View Profile
December 24, 2014, 08:19:01 PM
 #18996


Cool, but I won't bite until they offer bip32

Bro, do you even blockchain?
-E Voorhees
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
December 24, 2014, 11:14:45 PM
 #18997


they already do
HeliKopterBen
Hero Member
*****
Offline Offline

Activity: 622



View Profile
December 25, 2014, 05:45:24 AM
 #18998


"This way the paper wallet has never touched a computer or a network, and as soon as you eject the device the private key is wiped from memory"

This is not true.  Anyone printing paper wallet should be careful of what printer they are using.  Larger industrial printers have hard drives that record all spooled print data in some cases, especially older models.  Most of them are also connected to the internet.  Some of the newer models have data security or drive encryption installed by default but not all.  Smaller personal and desktop printers that don't have hard drives may be ok.  IMO dedicated hardware wallets are the better option.

http://www.cbsnews.com/news/digital-photocopiers-loaded-with-secrets/


Counterfeit:  made in imitation of something else with intent to deceive:  merriam-webster
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
December 25, 2014, 06:14:07 AM
 #18999


"This way the paper wallet has never touched a computer or a network, and as soon as you eject the device the private key is wiped from memory"

This is not true.  Anyone printing paper wallet should be careful of what printer they are using.  Larger industrial printers have hard drives that record all spooled print data in some cases, especially older models.  Most of them are also connected to the internet.  Some of the newer models have data security or drive encryption installed by default but not all.  Smaller personal and desktop printers that don't have hard drives may be ok.  IMO dedicated hardware wallets are the better option.

http://www.cbsnews.com/news/digital-photocopiers-loaded-with-secrets/



Is Trezor a single address that is reused?
brg444
Hero Member
*****
Offline Offline

Activity: 644

Bitcoin replaces central, not commercial, banks


View Profile
December 25, 2014, 06:39:30 AM
 #19000


"This way the paper wallet has never touched a computer or a network, and as soon as you eject the device the private key is wiped from memory"

This is not true.  Anyone printing paper wallet should be careful of what printer they are using.  Larger industrial printers have hard drives that record all spooled print data in some cases, especially older models.  Most of them are also connected to the internet.  Some of the newer models have data security or drive encryption installed by default but not all.  Smaller personal and desktop printers that don't have hard drives may be ok.  IMO dedicated hardware wallets are the better option.

http://www.cbsnews.com/news/digital-photocopiers-loaded-with-secrets/



Is Trezor a single address that is reused?

no trezor has bip32 HD wallet

"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
Pages: « 1 ... 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 1000 ... 1558 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!