search

cculianu / brute38

Resumable BIP38 Brute Force Password Cracker, written in Go
MIT License
41 stars 18 forks source link

Passing the encrypted key as bytes instead of as string #1

Closed stevenroose closed 6 years ago

stevenroose commented 10 years ago

The DecryptWithPassphrase method takes the key as a string and decodes it to a byte array. This decoding is done with every passphrase guess.

I think performing the decoding once and handing over the byte array as the key will increase performance.

cculianu commented 10 years ago

Hi,

Thanks for the suggestion. Sure, I can change it. But the guesses themselves take so LONG to try (at best i get about 7 guesses per second on my system!), that this optimization may not make much of a difference in the long-run. You may shave off 30-100 microseconds per guess (if that), but that's peanuts compared to the gargantuan amount of time the guesses themselves take to apply to the key.

I'll put in the change though, since I guess over the course of days of this program running it could mean a few minutes saved. Which, I suppose, is something! :P

Thanks for your suggestion again!

-Calin

On Fri, Mar 7, 2014 at 2:51 PM, Steven Roose notifications@github.comwrote:

The DecryptWithPassphrase method takes the key as a string and decodes it to a byte array. This decoding is done with every passphrase guess.

I think performing the decoding once and handing over the byte array as the key will increase performance.

Reply to this email directly or view it on GitHubhttps://github.com/cculianu/brute38/issues/1 .

stevenroose commented 10 years ago

Wow, 7 guesses per second is really low! I knew SCrypt is slow and it is meant to be so by design, but 7 per second is really slow, I suppose you are running either an i5 or i7 processor?

What's the point of brute-forcing it then, if you can only have 7 guesses per second? That only makes sense if you already have a lot of information about the password, f.e. when you lost it.

On Fri, Mar 7, 2014 at 4:56 PM, Calin Culianu notifications@github.comwrote:

Hi,

Thanks for the suggestion. Sure, I can change it. But the guesses themselves take so LONG to try (at best i get about 7 guesses per second on my system!), that this optimization may not make much of a difference in the long-run. You may shave off 30-100 microseconds per guess (if that), but that's peanuts compared to the gargantuan amount of time the guesses themselves take to apply to the key.

I'll put in the change though, since I guess over the course of days of this program running it could mean a few minutes saved. Which, I suppose, is something! :P

Thanks for your suggestion again!

-Calin

On Fri, Mar 7, 2014 at 2:51 PM, Steven Roose <notifications@github.com

wrote:

The DecryptWithPassphrase method takes the key as a string and decodes it to a byte array. This decoding is done with every passphrase guess.

I think performing the decoding once and handing over the byte array as the key will increase performance.

Reply to this email directly or view it on GitHub< https://github.com/cculianu/brute38/issues/1> .

Reply to this email directly or view it on GitHubhttps://github.com/cculianu/brute38/issues/1#issuecomment-37036956 .

cculianu commented 10 years ago

Well, 7 per second on my machine. I have a Quad core i7. Some people get more than that.

And.. there are 48 core machines out there.

And people have access to clusters. (Which my app is good for, using the --chunk option).

Right, the best way to brute force is if someone wrote a GPU BIP38 cracker. None exists as far as I know. I may go ahead and add OpenCL/GPU support to this app some day though.

The point is these contests come out occasionally on reddit to brute force keys and it takes days or weeks for someone to finally do it. It's fun.

On Sat, Mar 8, 2014 at 4:05 AM, Steven Roose notifications@github.comwrote:

Wow, 7 guesses per second is really low! I knew SCrypt is slow and it is meant to be so by design, but 7 per second is really slow, I suppose you are running either an i5 or i7 processor?

What's the point of brute-forcing it then, if you can only have 7 guesses per second? That only makes sense if you already have a lot of information about the password, f.e. when you lost it.

On Fri, Mar 7, 2014 at 4:56 PM, Calin Culianu <notifications@github.com

wrote:

Hi,

Thanks for the suggestion. Sure, I can change it. But the guesses themselves take so LONG to try (at best i get about 7 guesses per second on my system!), that this optimization may not make much of a difference in the long-run. You may shave off 30-100 microseconds per guess (if that), but that's peanuts compared to the gargantuan amount of time the guesses themselves take to apply to the key.

I'll put in the change though, since I guess over the course of days of this program running it could mean a few minutes saved. Which, I suppose, is something! :P

Thanks for your suggestion again!

-Calin

On Fri, Mar 7, 2014 at 2:51 PM, Steven Roose <notifications@github.com

wrote:

The DecryptWithPassphrase method takes the key as a string and decodes it to a byte array. This decoding is done with every passphrase guess.

I think performing the decoding once and handing over the byte array as the key will increase performance.

Reply to this email directly or view it on GitHub< https://github.com/cculianu/brute38/issues/1> .

Reply to this email directly or view it on GitHub< https://github.com/cculianu/brute38/issues/1#issuecomment-37036956>

.

Reply to this email directly or view it on GitHubhttps://github.com/cculianu/brute38/issues/1#issuecomment-37085948 .

stevenroose commented 10 years ago

Is it possible to write a GPU BIP0038 cracker? BIP0038 involves SCrypt, SHA-256 and ECDSA private-to-public key generation. The combination of those things is a lot harder to optimize for GPU utilization then f.e. mining, which only involves SHA-256 calculations. On Mar 8, 2014 8:56 AM, "Calin Culianu" notifications@github.com wrote:

Well, 7 per second on my machine. I have a Quad core i7. Some people get more than that.

And.. there are 48 core machines out there.

And people have access to clusters. (Which my app is good for, using the --chunk option).

Right, the best way to brute force is if someone wrote a GPU BIP38 cracker. None exists as far as I know. I may go ahead and add OpenCL/GPU support to this app some day though.

The point is these contests come out occasionally on reddit to brute force keys and it takes days or weeks for someone to finally do it. It's fun.

On Sat, Mar 8, 2014 at 4:05 AM, Steven Roose <notifications@github.com

wrote:

Wow, 7 guesses per second is really low! I knew SCrypt is slow and it is meant to be so by design, but 7 per second is really slow, I suppose you are running either an i5 or i7 processor?

What's the point of brute-forcing it then, if you can only have 7 guesses per second? That only makes sense if you already have a lot of information about the password, f.e. when you lost it.

On Fri, Mar 7, 2014 at 4:56 PM, Calin Culianu <notifications@github.com

wrote:

Hi,

Thanks for the suggestion. Sure, I can change it. But the guesses themselves take so LONG to try (at best i get about 7 guesses per second on my system!), that this optimization may not make much of a difference in the long-run. You may shave off 30-100 microseconds per guess (if that), but that's peanuts compared to the gargantuan amount of time the guesses themselves take to apply to the key.

I'll put in the change though, since I guess over the course of days of this program running it could mean a few minutes saved. Which, I suppose, is something! :P

Thanks for your suggestion again!

-Calin

On Fri, Mar 7, 2014 at 2:51 PM, Steven Roose <notifications@github.com

wrote:

The DecryptWithPassphrase method takes the key as a string and decodes it to a byte array. This decoding is done with every passphrase guess.

I think performing the decoding once and handing over the byte array as the key will increase performance.

Reply to this email directly or view it on GitHub< https://github.com/cculianu/brute38/issues/1> .

Reply to this email directly or view it on GitHub< https://github.com/cculianu/brute38/issues/1#issuecomment-37036956>

.

Reply to this email directly or view it on GitHub< https://github.com/cculianu/brute38/issues/1#issuecomment-37085948> .

Reply to this email directly or view it on GitHubhttps://github.com/cculianu/brute38/issues/1#issuecomment-37091924 .

cculianu commented 10 years ago

I'm actually looking into this! I may work on a GPU-based BIP0038 cracker in the coming day/days (schedule permitting). It certainly would/should be faster than a CPU-based one. Scrypt GPU miners are faster than CPU miners, after all.

On Sun, Mar 9, 2014 at 8:14 PM, Steven Roose notifications@github.comwrote:

Is it possible to write a GPU BIP0038 cracker? BIP0038 involves SCrypt, SHA-256 and ECDSA private-to-public key generation. The combination of those things is a lot harder to optimize for GPU utilization then f.e. mining, which only involves SHA-256 calculations.

On Mar 8, 2014 8:56 AM, "Calin Culianu" notifications@github.com wrote:

Well, 7 per second on my machine. I have a Quad core i7. Some people get more than that.

And.. there are 48 core machines out there.

And people have access to clusters. (Which my app is good for, using the --chunk option).

Right, the best way to brute force is if someone wrote a GPU BIP38 cracker. None exists as far as I know. I may go ahead and add OpenCL/GPU support to this app some day though.

The point is these contests come out occasionally on reddit to brute force keys and it takes days or weeks for someone to finally do it. It's fun.

On Sat, Mar 8, 2014 at 4:05 AM, Steven Roose <notifications@github.com

wrote:

Wow, 7 guesses per second is really low! I knew SCrypt is slow and it is meant to be so by design, but 7 per second is really slow, I suppose you are running either an i5 or i7 processor?

What's the point of brute-forcing it then, if you can only have 7 guesses per second? That only makes sense if you already have a lot of information about the password, f.e. when you lost it.

On Fri, Mar 7, 2014 at 4:56 PM, Calin Culianu < notifications@github.com

wrote:

Hi,

Thanks for the suggestion. Sure, I can change it. But the guesses themselves take so LONG to try (at best i get about 7 guesses per second on my system!), that this optimization may not make much of a difference in the long-run. You may shave off 30-100 microseconds per guess (if that), but that's peanuts compared to the gargantuan amount of time the guesses themselves take to apply to the key.

I'll put in the change though, since I guess over the course of days of this program running it could mean a few minutes saved. Which, I suppose, is something! :P

Thanks for your suggestion again!

-Calin

On Fri, Mar 7, 2014 at 2:51 PM, Steven Roose < notifications@github.com

wrote:

The DecryptWithPassphrase method takes the key as a string and decodes it to a byte array. This decoding is done with every passphrase guess.

I think performing the decoding once and handing over the byte array as the key will increase performance.

Reply to this email directly or view it on GitHub< https://github.com/cculianu/brute38/issues/1> .

Reply to this email directly or view it on GitHub< https://github.com/cculianu/brute38/issues/1#issuecomment-37036956>

.

Reply to this email directly or view it on GitHub< https://github.com/cculianu/brute38/issues/1#issuecomment-37085948> .

Reply to this email directly or view it on GitHub< https://github.com/cculianu/brute38/issues/1#issuecomment-37091924>

.

Reply to this email directly or view it on GitHubhttps://github.com/cculianu/brute38/issues/1#issuecomment-37133755 .