Bitcoin Forum
April 19, 2024, 03:03:31 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 [5]  All
  Print  
Author Topic: Brain Wallet standardization  (Read 15378 times)
Ente
Legendary
*
Offline Offline

Activity: 2126
Merit: 1001



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

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

Posts: 1713495811

View Profile Personal Message (Offline)

Ignore
1713495811
Reply with quote  #2

1713495811
Report to moderator
1713495811
Hero Member
*
Offline Offline

Posts: 1713495811

View Profile Personal Message (Offline)

Ignore
1713495811
Reply with quote  #2

1713495811
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1713495811
Hero Member
*
Offline Offline

Posts: 1713495811

View Profile Personal Message (Offline)

Ignore
1713495811
Reply with quote  #2

1713495811
Report to moderator
flipperfish
Sr. Member
****
Offline Offline

Activity: 350
Merit: 251


Dolphie Selfie


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

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?
cbeast (OP)
Donator
Legendary
*
Offline Offline

Activity: 1736
Merit: 1006

Let's talk governance, lipstick, and pigs.


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

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

Activity: 42
Merit: 0



View Profile
August 09, 2012, 04:13:32 PM
Last edit: August 09, 2012, 04:24:18 PM by HeavyMetal
 #84

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

Activity: 1218
Merit: 1001


RepuX - Enterprise Blockchain Protocol


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


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 );

▄▄▄▄▄▄▄▄▄▄        ▄▄▄▄▄▄▄▄▄
███████████▄    ▄███████████
█████████████▄▄█████████████
████████████████████████████
████████████████████████████
▀█████████████████████████▀
  ▀█████████████████████▀
   ▄████████████████████▄
 ████████████████████████▄
████████████████████████████
████████████████████████████
█████████████▀▀█████████████
███████████▀    ▀███████████
▀▀▀▀▀▀▀▀▀▀        ▀▀▀▀▀▀▀▀▀
RepuX▄██▄
████
████
████
████
████
████
████
▀██▀
.Decentralized Data & Applications Protocol For SMEs.
.
▔▔▔▔  ●  Twitter  ●  Facebook  ●  Bitcointalk  ●  Reddit  ●  ▔▔▔▔
▄██▄
████
████
████
████
████
████
████
▀██▀
Enterprise Blockchain Protocol
.GET WHITELISTED.
Token Sale starts 6th of February 2018
HeavyMetal
Newbie
*
Offline Offline

Activity: 42
Merit: 0



View Profile
August 09, 2012, 04:35:30 PM
Last edit: August 09, 2012, 05:06:50 PM by HeavyMetal
 #86


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.
casascius
Mike Caldwell
VIP
Legendary
*
Offline Offline

Activity: 1386
Merit: 1136


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


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

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 or hardware wallets instead.
anu
Legendary
*
Offline Offline

Activity: 1218
Merit: 1001


RepuX - Enterprise Blockchain Protocol


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

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.


▄▄▄▄▄▄▄▄▄▄        ▄▄▄▄▄▄▄▄▄
███████████▄    ▄███████████
█████████████▄▄█████████████
████████████████████████████
████████████████████████████
▀█████████████████████████▀
  ▀█████████████████████▀
   ▄████████████████████▄
 ████████████████████████▄
████████████████████████████
████████████████████████████
█████████████▀▀█████████████
███████████▀    ▀███████████
▀▀▀▀▀▀▀▀▀▀        ▀▀▀▀▀▀▀▀▀
RepuX▄██▄
████
████
████
████
████
████
████
▀██▀
.Decentralized Data & Applications Protocol For SMEs.
.
▔▔▔▔  ●  Twitter  ●  Facebook  ●  Bitcointalk  ●  Reddit  ●  ▔▔▔▔
▄██▄
████
████
████
████
████
████
████
▀██▀
Enterprise Blockchain Protocol
.GET WHITELISTED.
Token Sale starts 6th of February 2018
HeavyMetal
Newbie
*
Offline Offline

Activity: 42
Merit: 0



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

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?
rjk
Sr. Member
****
Offline Offline

Activity: 448
Merit: 250


1ngldh


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

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!
Pages: « 1 2 3 4 [5]  All
  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!