Bitcoin Forum
December 07, 2016, 10:56:27 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 [5]  All
  Print  
Author Topic: Brain Wallet standardization  (Read 14398 times)
casascius
Mike Caldwell
VIP
Legendary
*
Offline Offline

Activity: 1344


The Casascius 1oz 10BTC Silver Round (w/ Gold B)


View Profile WWW
August 04, 2012, 02:42:24 PM
 #81

I like it!
Although, I would rather not have to memorize my emailaddress.. How about birthdate as "salt"?
Yes, it may (or may not) be less secret than a emailaddress, but thats not the point of salt anyway.
There will be people who change their email every other year and who will lose track of what they used back then. Or who only documented their passphrase and pin, and their heirs will have a tough time figuring it out..

Using a birthdate is a bad idea, 90% of the demographic that would use a brainwallet will predictably have one of about 10,000 birthdates, neutralizing the value and making a mass attack feasible.  One should be able on the other hand to try each of their recent emails if there is more than one candidate.

Heirs aren't really relevant since a brainwallet is by definition a memorized thing that will be lost upon death. But if someone writes one down for safekeeping, there is no reason they can't or wouldn't want to write down all of the strings needed to restore it.

I would agree with what you suggested on PIN - the more I think about it, there is actually little reason for it because it could be brute forced so easily. For the stakes involved and given that users are likely to choose piss-poor passphrases, an iteration count that requires a very long time (60+ seconds on today's hardware) is actually quite reasonable.

Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable.  I never believe them.  If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins.  I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion.  Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice.  Don't keep coins online. Use paper wallets instead.
1481108187
Hero Member
*
Offline Offline

Posts: 1481108187

View Profile Personal Message (Offline)

Ignore
1481108187
Reply with quote  #2

1481108187
Report to moderator
1481108187
Hero Member
*
Offline Offline

Posts: 1481108187

View Profile Personal Message (Offline)

Ignore
1481108187
Reply with quote  #2

1481108187
Report to moderator
1481108187
Hero Member
*
Offline Offline

Posts: 1481108187

View Profile Personal Message (Offline)

Ignore
1481108187
Reply with quote  #2

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

Activity: 1834



View Profile
August 04, 2012, 03:43:57 PM
 #82

Salt != Password != Secret :-P

But yes, of course you are right, the passphrase would be written down for heirs anyway. No problem to write down salt/email/pin as well in that occasion.
Nevertheless, I prefer to only have to remember as little as necessary, for a brainwallet.

Ente
Ukigo
Hero Member
*****
Offline Offline

Activity: 924


View Profile
August 05, 2012, 09:45:57 AM
 #83

Below is tuned algorithm :
In "pseudocode" :
Code:

           pass = SHA512(your_long_passphrase)
           salt = SHA512(pass)
           dk_length = 100000
           dk = Scrypt( pass, salt, 524288, 9, 5, dk_length)
           split "dk" into 32-byte long chunks -- every chunk is Bitcoin privkey in hex form
Good luck with brute-forcing of my passphrase !  Smiley
On ordinare PC EACH attempt take this time :
Code:
real 7m28.471s
user 7m14.299s
sys 0m1.169s
Even on cluster of GPUs, sharing work brute-forcing still will be very SLOW.

PS. my next goal is to do something against dictionary attacks.
 I have actual working code for this algo ( in Google Go ):
https://github.com/ukigo/sckey

"...Enemies are everywhere ! Angka is all rage ! Be a good soldiers, blow everything... " <-- Pol Pot (C)
flipperfish
Sr. Member
****
Offline Offline

Activity: 312


Dolphie Selfie


View Profile
August 05, 2012, 11:22:13 AM
 #84

Wouldn't it be the best to nest multiple hash-algorithms to compensate for attacks on a single one, which could be found in future?

Scrypt seems to be very new, and not as well analyzed as Bcrypt or PBKDF2. SHA is very well tested, but too fast (to prevent brute-force) on its own.
So if you nest for example Scrypt, Bcrypt, PBKDF2 and SHA you should be on the safe side. Even if a flaw in Scrypt is discovered, which allows a speedup to levels of SHA, you would still be protected by Bcrypt (and the others). Or do I make a mistake here?
Ukigo
Hero Member
*****
Offline Offline

Activity: 924


View Profile
August 05, 2012, 11:36:25 AM
 #85

If interesting there is a PDF about it :
http://www.tarsnap.com/scrypt/scrypt.pdf

I am not the crypto-expert, but :

1) Scrypt allready uses SHA256 and PBKDF2 internally.
 It is a complex algo.

2) Also sha256 in scrypt, likely, could be replaced by RIPEMD160 or whirlpool or some other   hashing algo, without bad consequencies.

"...Enemies are everywhere ! Angka is all rage ! Be a good soldiers, blow everything... " <-- Pol Pot (C)
cbeast
Donator
Legendary
*
Offline Offline

Activity: 1722

Let's talk governance, lipstick, and pigs.


View Profile
August 05, 2012, 11:44:16 AM
 #86

Wouldn't it be the best to nest multiple hash-algorithms to compensate for attacks on a single one, which could be found in future?

Scrypt seems to be very new, and not as well analyzed as Bcrypt or PBKDF2. SHA is very well tested, but too fast (to prevent brute-force) on its own.
So if you nest for example Scrypt, Bcrypt, PBKDF2 and SHA you should be on the safe side. Even if a flaw in Scrypt is discovered, which allows a speedup to levels of SHA, you would still be protected by Bcrypt (and the others). Or do I make a mistake here?
That makes sense, but whatever Bitcoin itself is based in should suffice. I would plan to update the wallet if Bitcoin changes to a new algorithm. I'm just afraid I would forget which I used unless there is also a standardized one for brain wallets. Scrypt might be a good choice.

I am not the crypto-expert, but :

1) Scrypt allready use SHA256 and PBKDF2 internally.
 It is complex algo.

2) Also sha256 in scrypt, likely, could be replaced by RIPEMD160 or whirlpool or some other   hashing algo, without bad consequencies.

Scrypt looks like a good choice.

Any significantly advanced cryptocurrency is indistinguishable from Ponzi Tulips.
HeavyMetal
Jr. Member
*
Offline Offline

Activity: 42



View Profile
August 09, 2012, 04:13:32 PM
 #87

Standardization is a good idea for many reasons. I have come up with this for myself:

Code:
#!/usr/bin/perl
use strict;
use Digest::SHA qw( sha256 );

my $phrase = $ARGV[0];
my $hash = '';

$hash = sha256( $hash.$phrase ) foreach ( 1 .. 100_000_000 );
  
print unpack( 'H*', $hash )."\n";

I am going to print out a card with the public key in text/qr and on the back of the card I will put the above source code.

Code:
time ./deep_hash.pl sekret
0133e4f42dc48ebcc7d04eb85984724b027347b555e2324d42a5542335962af7

real 3m59.901s
user 3m58.180s
sys 0m0.370s

I think it is slow enough to resist brute force. I put the password back into the hash every iteration so that if you have one private key compromised they cannot get the rest without the password.

This can also be used for deterministic wallets. I think it is better than sha256('<password><number>') because it does not allow an attacker to skip keys along the way.

The output of this script can be directly imported into a blockchain.info wallet

I am not certain, but I think reintroducing the password in every iteration may mitigate(solve?) the issue with entropy being lost from repeated hashing. Can anyone who understands hashing better than me confirm this?

Regarding how many iterations, I was thinking upon generation you could choose from 1, 100, 1000, etc... Then when recovering the user could provide what they entered, or if they forgot the program could just recover all of the predefined checkpoints. This would allow the user to choose between fast or difficult to brute force, but still not require them to remember the number of iterations.

1AuAgBTU8FJ2oHM4iwRRa5SJVTbuKV8htr - Bitcoins to this address go to the purchase of Silver.
anu
Legendary
*
Offline Offline

Activity: 938


P2P Everything


View Profile WWW
August 09, 2012, 04:27:18 PM
 #88


use Digest::SHA qw( sha256 );


As Casascius pointed out, you loose entropy with every round. So you might want to choose a hash with more bits and do the sha256 for the last round only.

I think it presents a more difficult problem to crack it if the number of rounds is not known in advance:

do {
  $hash = sha512( $hash.$phrase );
while( hash % 100_000_000 );  # This will really have to be gmp, I guess.
$hash = sha256( $hash );

Zero Reserve - A distributed Bitcoin Exchange

Install - Getting Started - BitcoinTalk Thread - Github Source
HeavyMetal
Jr. Member
*
Offline Offline

Activity: 42



View Profile
August 09, 2012, 04:35:30 PM
 #89


use Digest::SHA qw( sha256 );


As Casascius pointed out, you loose entropy with every round. So you might want to choose a hash with more bits and do the sha256 for the last round only.

I think it presents a more difficult problem to crack it if the number of rounds is not known in advance:

do {
  $hash = sha512( $hash.$phrase );
while( hash % 100_000_000 );  # This will really have to be gmp, I guess.
$hash = sha256( $hash );

Are you sure about that? I think that Casascius was talking about another algorithm that just hashed the previous hash without introducing any new entropy. By reintroducing the passphrase every round I think the entropy is topped up every iteration to the same amount the passphrase originally introduced. I don't think more bits are needed due to this and it would be nice if this standard made use of existing primitives already in the code base.

I would love to hear what Casascius has to say on this.

Regarding the number of rounds I think that since you cannot skip ahead with this method that just being sufficiently deep is enough. However, nothing about this method prevents the input of a custom number of rounds. The list of preset number of rounds with varying depths can be there for those that do not want to fear forgetting how many rounds.

It all depends on how long the hacker is willing to spend hashing each password in his dictionary. They might spend 1 second on each word(a very long time) but will they spend 10 seconds, 100 seconds? Surely they won't spend 20 minutes per word to create their rainbow table. If you don't plan to take your private key out very often then waiting a day for it to be calculated might be reasonable.

If the attacker knows your passphrase it will be trivial to crack just by creating the address every iteration until it found one in the block chain. The keyspace defined by the number of iterations it is reasonable for someone to actually accomplish at a home PC is far too small to act as an added secret. However long it takes you to decode your key, an attacker can do in just a bit more time(he has to produce the addresses) or faster if they have a better computer than you.

The number of iterations is not meant to be an added secret, if you want to add another secret number just put it in your passphrase and it will add the same amount of challenge to the attacker. The number of iterations is to force work on someone making a rainbow table of addresses based on a dictionary.

A good deep number of iterations would have too many digits to be easily remembered alongside a passphrase. People would choose small ones. The place for secrets is in the passphrase, not proof of work hash iteration.

Interesting idea in looking for a magic hash with 1 in a million properties so as to not know the number of iterations in advance, but wouldn't both the user and the attacker suffer the exact same costs? Seems like a zero sum game, each word still only has one answer. You could also have no control over the depth of your password, it could be very shallow or so deep it takes days to make. You will have no idea if you are almost done making the key or not even close. No progress bar that is for sure.

1AuAgBTU8FJ2oHM4iwRRa5SJVTbuKV8htr - Bitcoins to this address go to the purchase of Silver.
casascius
Mike Caldwell
VIP
Legendary
*
Offline Offline

Activity: 1344


The Casascius 1oz 10BTC Silver Round (w/ Gold B)


View Profile WWW
August 09, 2012, 05:14:13 PM
 #90

Consider using the algorithm PBKDF2.  It is specifically intended as a "key derivation" algorithm and adds iterations and salt while avoiding the lost entropy problem.

The way I understand it, PBKDF2 is not the entire algorithm - it actually is a partial algorithm that sort of has a "fill in the blank" with the hash algorithm of your choice to do the hashing.  Which algorithm is up to you the implementer, not PBKDF2.  Using PBKDF2 takes a simple hash function and extends it to add salting and iterations without loss of entropy.

So, PBKDF2-HMAC-SHA512 means use the PBKDF2 algorithm and, where it calls for a hash algorithm, use SHA512 to generate the hash.

Avoiding SHA256 is preferable simply due to how fast the Bitcoin community has accelerated SHA256 hashing, making it somewhat less preferable as a key derivation algorithm.

Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable.  I never believe them.  If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins.  I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion.  Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice.  Don't keep coins online. Use paper wallets instead.
anu
Legendary
*
Offline Offline

Activity: 938


P2P Everything


View Profile WWW
August 09, 2012, 05:15:46 PM
 #91

Are you sure about that? I think that Casascius was talking about another algorithm that just hashed the previous hash without introducing any new entropy. By reintroducing the passphrase every round I think the entropy is topped up every iteration to the same amount the passphrase originally introduced. I don't think more bits are needed due to this and it would be nice if this standard made use of existing primitives already in the code base.

No idea what inputing the original passphrase in each round will do.

Interesting idea in looking for a magic hash with 1 in a million properties so as to not know the number of iterations in advance, but wouldn't both the user and the attacker suffer the exact same costs? Seems like a zero sum game, each word still only has one answer. You could also have no control over the depth of your password, it could be very shallow or so deep it takes days to make. You will have no idea if you are almost done making the key or not even close. No progress bar that is for sure.

The purpose of the unknown number of rounds is to make SIMD SIMT... architectures inefficient and force the attacker to use CPUs. Since the user is using CPUs, the attacker has higher costs.

But I don't know if that will have a similar effect on FPGA. If not, this is not such a great idea. But then, doing an operation like the residual divide is making the FPGA waste loads of gates.


Zero Reserve - A distributed Bitcoin Exchange

Install - Getting Started - BitcoinTalk Thread - Github Source
HeavyMetal
Jr. Member
*
Offline Offline

Activity: 42



View Profile
August 09, 2012, 05:16:27 PM
 #92

Avoiding SHA256 is preferable simply due to how fast the Bitcoin community has accelerated SHA256 hashing, making it somewhat less preferable as a key derivation algorithm.

This is a good point. Ideally a method that GPUs could not do easily would be ideal?

1AuAgBTU8FJ2oHM4iwRRa5SJVTbuKV8htr - Bitcoins to this address go to the purchase of Silver.
rjk
Sr. Member
****
Offline Offline

Activity: 420


1ngldh


View Profile
August 09, 2012, 05:44:32 PM
 #93

Avoiding SHA256 is preferable simply due to how fast the Bitcoin community has accelerated SHA256 hashing, making it somewhat less preferable as a key derivation algorithm.

This is a good point. Ideally a method that GPUs could not do easily would be ideal?
Well, Scrypt should fit the bill, and I think that's what's used in bcrypt [sorry, I was wrong there]. Although there are now GPU versions of scrypt miners, that is not a problem for a proper implementation of scrypt. The miner versions (litecoin, etc) of scrypt have tweaked parameters that make it faster, such as reduced memory requirements. If these settings are left at the default, it would be more difficult to make it run on a GPU.

Mining Rig Extraordinaire - the Trenton BPX6806 18-slot PCIe backplane [PICS] Dead project is dead, all hail the coming of the mighty ASIC!
Ukigo
Hero Member
*****
Offline Offline

Activity: 924


View Profile
August 09, 2012, 06:02:59 PM
 #94

Speaking of Scrypt parameters,
standard trinity of 16384, 8, 1 is likely not enough for our case.

If you have enough RAM on board you can use these params :
( from my post above ) :
Code:
dk = Scrypt( pass, salt, 2097152, 9, 9, dk_length)
this setup will take LOOONG time to calculate, but it's Ok ,
because you'll have  a lot of privkeys , and not just one.


"...Enemies are everywhere ! Angka is all rage ! Be a good soldiers, blow everything... " <-- Pol Pot (C)
Pages: « 1 2 3 4 [5]  All
  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!