Bitcoin Forum
December 13, 2017, 11:48:07 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 ... 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 ... 1558 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 2022643 times)
NewLiberty
Legendary
*
Offline Offline

Activity: 1190


Gresham's Lawyer


View Profile WWW
December 23, 2014, 01:53:07 PM
 #18961

If you create a HD wallet that ONLY creates multisig transactions, would that prevent addresses from being reused?
What does multisig have to do with address reuse?
HD wallets reuse addresses when people send multiple payments to them. I think that is a weakness. Isn't there another bitcoin payment for where this is not possible, like multisig?

The RIGHT way to do it would be Stealth Addresses.
This way you can publish a permanent address and it is not tracked to the address in the block chain by anyone except its owner, and the addresses in the block chain is not reused, preventing a Johoe grab.
It solves both problems simultaneously, but the address bigger (so the QR takes smaller squares, etc).

Monero does it automatically from the start, with all transactions, it is not really possible to NOT use a stealth address, all wallets use them. 
In Bitcoin, it is sort of possible to do stealth addresses, but it is not user friendly at all, and so it is considered experimental.

Here is how:
http://sx.dyne.org/stealth.html

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

Posts: 1513208887

View Profile Personal Message (Offline)

Ignore
1513208887
Reply with quote  #2

1513208887
Report to moderator
1513208887
Hero Member
*
Offline Offline

Posts: 1513208887

View Profile Personal Message (Offline)

Ignore
1513208887
Reply with quote  #2

1513208887
Report to moderator
1513208887
Hero Member
*
Offline Offline

Posts: 1513208887

View Profile Personal Message (Offline)

Ignore
1513208887
Reply with quote  #2

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

Activity: 1624



View Profile
December 23, 2014, 02:09:59 PM
 #18962

In Bitcoin, it is sort of possible to do stealth addresses, but it is not user friendly at all, and so it is considered experimental.

Here is how:
http://sx.dyne.org/stealth.html

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

HeliKopterBen
Hero Member
*****
Offline Offline

Activity: 622



View Profile
December 23, 2014, 04:29:07 PM
 #18963

The problem is that human thoughts and actions are invariably patterned, not random.  Even when someone attempts to be random, they often revert back to patterned thoughts and actions.  RNGs are unfortunately programmed by humans and therefore subject to possibly being patterned in some way.  For large sums of money, it is still advisable to use multiple sources of objective external entropy such as die rolls combined with mouse movements.

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

Activity: 1764



View Profile
December 23, 2014, 05:07:03 PM
 #18964


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.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
December 23, 2014, 05:27:52 PM
 #18965

Producing additional ECDSA signatures (additional outbound TXs) from that address has no meaningful effect on security either, provided the k-values used in signature generation remain unknown. As an example, the address 12WRnQR85ZUT7dhmaHBNL5dde2QLYieW6v presently holds $24,000,000 of bitcoins and has made multiple outgoing transactions.  For each outgoing transaction from this address, we can inspect the signatures and determine the R values.  This doesn't help us "hack" the address to any meaningful extent except in the case where the signatures were produced incorrectly (for example, by using a low-entropy k-value).



Peter, this is quite helpful and i learned something here which i'd like to verify.  so, it is not really R that needs to be random, but in fact k that is used to calculate R, correct?  that's b/c (x1, y1)=kG where R=x1 (mod N).   

furthermore, k not only has to be random, but it has to remain "unknown", correct?
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
December 23, 2014, 05:30:02 PM
 #18966

out of curiosity to the security experts here.

which do you consider more secure, Armory or Trezor?
Peter R
Legendary
*
Offline Offline

Activity: 1064



View Profile
December 23, 2014, 05:48:20 PM
 #18967

Producing additional ECDSA signatures (additional outbound TXs) from that address has no meaningful effect on security either, provided the k-values used in signature generation remain unknown. As an example, the address 12WRnQR85ZUT7dhmaHBNL5dde2QLYieW6v presently holds $24,000,000 of bitcoins and has made multiple outgoing transactions.  For each outgoing transaction from this address, we can inspect the signatures and determine the R values.  This doesn't help us "hack" the address to any meaningful extent except in the case where the signatures were produced incorrectly (for example, by using a low-entropy k-value).



Peter, this is quite helpful and i learned something here which i'd like to verify.  so, it is not really R that needs to be random, but in fact k that is used to calculate R, correct?  that's b/c (x1, y1)=kG where R=x1 (mod N).   

furthermore, k not only has to be random, but it has to remain "unknown", correct?

75% correct: k is indeed used to calculate R and it's the variable the software has control over. 

But k doesn't have to be random; it just has to be secret (remain unknown) and unique per message1.  This is why RFC6979 works: k is deterministic but remains secret so long as the private key remains secret.  And it's guaranteed to be unique per message because it's the hash of some mix of the private key and the message (assuming SHA2 collisions are infeasible). 

1The "unique-per-message" requirement is in fact so that k remains secret, since it's possible to algebraically solve for k (and also the private key) if two unique messages are signed with the same k value. 

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

Activity: 1149


View Profile
December 23, 2014, 05:54:09 PM
 #18968

Producing additional ECDSA signatures (additional outbound TXs) from that address has no meaningful effect on security either, provided the k-values used in signature generation remain unknown. As an example, the address 12WRnQR85ZUT7dhmaHBNL5dde2QLYieW6v presently holds $24,000,000 of bitcoins and has made multiple outgoing transactions.  For each outgoing transaction from this address, we can inspect the signatures and determine the R values.  This doesn't help us "hack" the address to any meaningful extent except in the case where the signatures were produced incorrectly (for example, by using a low-entropy k-value).



Peter, this is quite helpful and i learned something here which i'd like to verify.  so, it is not really R that needs to be random, but in fact k that is used to calculate R, correct?  that's b/c (x1, y1)=kG where R=x1 (mod N).  

furthermore, k not only has to be random, but it has to remain "unknown", correct?

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

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

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

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

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

Activity: 1764



View Profile
December 23, 2014, 06:08:15 PM
 #18969

Producing additional ECDSA signatures (additional outbound TXs) from that address has no meaningful effect on security either, provided the k-values used in signature generation remain unknown. As an example, the address 12WRnQR85ZUT7dhmaHBNL5dde2QLYieW6v presently holds $24,000,000 of bitcoins and has made multiple outgoing transactions.  For each outgoing transaction from this address, we can inspect the signatures and determine the R values.  This doesn't help us "hack" the address to any meaningful extent except in the case where the signatures were produced incorrectly (for example, by using a low-entropy k-value).



Peter, this is quite helpful and i learned something here which i'd like to verify.  so, it is not really R that needs to be random, but in fact k that is used to calculate R, correct?  that's b/c (x1, y1)=kG where R=x1 (mod N).  

furthermore, k not only has to be random, but it has to remain "unknown", correct?

75% correct: k is indeed used to calculate R and it's the variable the software has control over.  

But k doesn't have to be random; it just has to be secret (remain unknown) and unique per message1.  This is why RFC6979 works: k is deterministic but remains secret so long as the private key remains secret.  And it's guaranteed to be unique per message because it's the hash of some mix of the private key and the message (assuming SHA2 collisions are infeasible).  

1The "unique-per-message" requirement is in fact so that k remains secret, since it's possible to algebraically solve for k (and also the private key) if two unique messages are signed with the same k value.  

is it fair to say that when generating repeated deterministic k's when reusing the same address for tx's, that in fact the k is NOT random since both of the HMAC components are the same (privkey) or similarly structured (tx) ?   i may be using HMAC incorrectly but i mean --> k=hash (tx+privkey).
rocks
Legendary
*
Offline Offline

Activity: 1149


View Profile
December 23, 2014, 06:22:15 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.

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.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
December 23, 2014, 06:24:34 PM
 #18971

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
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
December 23, 2014, 06:28:33 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.

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

Activity: 644

Bitcoin replaces central, not commercial, banks


View Profile
December 23, 2014, 06:35:03 PM
 #18973


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
Legendary
*
Offline Offline

Activity: 1764



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


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
Legendary
*
Offline Offline

Activity: 1764



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

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

Bitcoin replaces central, not commercial, banks


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


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
Legendary
*
Offline Offline

Activity: 1764



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


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
Legendary
*
Offline Offline

Activity: 1764



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

Gold collapsing.  Bitcoin UP.
smoothie
Legendary
*
Offline Offline

Activity: 2072


LEALANA Monero Physical Silver Coins


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


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.        SMOOTHIE'S HEALTH AND FITNESS JOURNAL          History of Monero development Visualization ★☆ .
LEALANA  PHYSICAL MONERO COINS 999 FINE SILVER.
 
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



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


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?
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 ... 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!