Bitcoin Forum
June 22, 2024, 02:45:54 PM *
News: Voting for pizza day contest
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1]
1  Bitcoin / Wallet software / Re: Best wallet for Security + Offline Transactions on: November 29, 2016, 08:49:17 AM
Electrum is more lightweight but it does not offer ♯♯ wallet file security.

This part is not right. Electrum uses AES-256-CBC which is, to my knowledge, a pretty strong way of encrypting the wallet file for security.

I agree with this user.

He is wrong. AES-256-CBC is used in many wallets. So no difference between them. Look at multibit hd beta 0.5 any why it is early. It uses AES-256-CBC and scrypt for key-stretching. Electrum uses SHA256d for key-stretching, same as mining. In this picture you can see brute force attacks with a normal computer. All the wallets use AES-256-CBC. The question is about offline computer. Is encryption important when offline?

(if it does not load, click)

Then what is your explanation for this: http://docs.electrum.org/en/latest/faq.html#what-encryption-is-used-for-wallets
I will add the link to code on GitHub if I can find it since I am bad at python.

Also the picture you have included here is out of context and does not say anything.
What is this result of?
Is it result of brute forcing encrypted wallet files?
How old is this?
How strong or weak was the passwords which were used? (the length of the password for example was it "123" or was it "2Fd#4dlR&jfh8"?
How many tests were performed on how many variations of passwords?

The graph shows brute force attack on wallets. The numbers are passwords/s. It is from my research 2 month ago. All wallets you see use AES-256-CBC. That is not important. If your password is strong, brute force is not working. With electrum you must have a strong password, with others not so much. I will show you in source if it helps.

Here is defined Hash(x), here it is used as secret for encryption. This is normal and called key-stretching or key derivation function. It is used because a password does not have the correct bits.

Now we look at bitcoin core. Here is encryption and look here is benchmark to help find a good number of sha512 rounds. In my research the wallets used 128675 to 240718 rounds. Think what would take longer 128000 rounds sha512 or two rounds sha256. AES is the same for all, it does not matter.

And question again, why is the password and key-stretching important if the computer is offline? Offline computer can have simple or no password.
2  Bitcoin / Wallet software / Re: Best wallet for Security + Offline Transactions on: November 28, 2016, 08:05:36 PM
Electrum is more lightweight but it does not offer ♯♯ wallet file security.

This part is not right. Electrum uses AES-256-CBC which is, to my knowledge, a pretty strong way of encrypting the wallet file for security.

I agree with this user.

He is wrong. AES-256-CBC is used in many wallets. So no difference between them. Look at multibit hd beta 0.5 any why it is early. It uses AES-256-CBC and scrypt for key-stretching. Electrum uses SHA256d for key-stretching, same as mining. In this picture you can see brute force attacks with a normal computer. All the wallets use AES-256-CBC. The question is about offline computer. Is encryption important when offline?

(if it does not load, click)
3  Bitcoin / Wallet software / Re: Electrum vs Multibit on: August 03, 2016, 08:39:03 AM
Not sure know what I can disclose. Electrum uses two rounds SHA256. Multibit HD uses scrypt with 16384,8,1.
Tests on CPU clusters with 24 threads are similar. I can publish more when the thesis is finished. What you take from it now is electrum is not defended against brute force, multibit hd is. ThePokerTranslator asked about security, this attack must have a wallet file. It might not what they ask about.
Ok, so if I am correctly understanding what you are saying... is that 2 rounds of SHA256 is a lot "faster" to compute than Scrypt 16384,8,1... so that, as it currently stands with current technology and methodologies, you can test passwords faster against an Electrum "wallet.dat" than you can against a Multibit HD "wallet.dat", because you can hash the input password faster.

Is that correct?

NOTE: I am not disputing your findings... I was just curious as to the how and what that graph was depicting... and if it is as I have asked, this is indeed useful information to know.

Yes. Is more complex, but yes. See schildbach app, it uses scrypt(4096,8,1). This scrypt can be calculated fast like sha 256. I think because its for phone which is not fast for scrypt default. Multibit classic uses md5. md5 is little bit broken. multibit hd is a good improvement over this.

Do not think now electrum is not good wallet please. Its special attack. Use longer password and all is ok. Dont get your file stolen is even better.
4  Bitcoin / Wallet software / Re: Electrum vs Multibit on: August 02, 2016, 11:54:11 AM
Tests on CPU clusters with 24 threads are similar. I can publish more when the thesis is finished. What you take from it now is electrum is not defended against brute force, multibit hd is. ThePokerTranslator asked about security, this attack must have a wallet file. It might not what they ask about.
5  Bitcoin / Wallet software / Re: Electrum vs Multibit on: August 02, 2016, 11:42:50 AM
Ok, so the graph is showing that there are several orders of magnitude more Passwords/s between Electrum and Multibit HD...

But, playing devils advocate here... what are the actual settings/circumstances being tested here? It doesn't really explain much... Is this purely just the number of passwords per second that one particular brute forcing app was able to test? If so, is that the ONLY brute forcing app in existence? If not, is there any proof that other brute forcing apps can't check Multibit HD Passwords just as fast? ie. is it because Multibit is deliberately slow and only allows a certain number of password entries per time period and ANY brute forcing app will show similar results?

Huh

Not sure know what I can disclose. Electrum uses two rounds SHA256. Multibit HD uses scrypt with 16384,8,1.
6  Bitcoin / Wallet software / Re: Electrum vs Multibit on: August 01, 2016, 09:48:53 AM
I'm figuring out which client to use. Could we discuss which one is better? Major factors to consider: security and ease of use.

Multibit HD is better protected against brute force attack.

7  Bitcoin / Bitcoin Technical Support / Re: wallet.dat password question on: June 07, 2016, 02:12:37 PM
In particular,  the wallet will generate new addresses after the password was changed that the old wallet won't know about. So your old backup will become increasingly invalid over time.

The wallet also re runs the benchmark to determine the number of SHA-512 rounds when setting a new password. On a more powerful system it will improve the defense against brute force attacks on the wallet file.
8  Other / MultiBit / Re: Why MD5 on mulitbit classic? on: May 25, 2016, 08:32:24 AM
For Classic the default bitcoinj key derivation was used.

For HD we switched to Scrypt because we thought the algorithm was superior, and 16,384 rounds was the version used in the Scrypt description paper so we thought it was OK to use.  There are various different salts used in HD so that the same wallet words used for different wallet types (Trezor walet, soft wallet) would not collide.

Thanks, that was helpful. I was surprised that not more wallets use scrypt. Bitcoin-core has some code in place to deploy scrypt in the future though.
9  Other / MultiBit / Why MD5 on mulitbit classic? on: May 20, 2016, 01:00:42 PM
Hello,

I hope this is a good place to ask this question. I do security research on some bitcoin wallets. Among them multibit classic and HD. I was wondering why MD5 was used for key stretching in classic. Also, why was/is a fixed number of rounds used? Classic uses 1024 rounds of MD5. HD uses Scrypt with an N value of 16384 and some more bitcoin specific things.

"I just felt like it" is a perfectly fine answer.
Pages: [1]
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!