Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Accelerating SHA256 by 100x in Golang on ARM

blog.minio.io

Post reply on HN
Print view View original

21–30 of 93 posts

Re: Show HN: Accelerating SHA256 by 100x in Golang on ARM

#21

Post by niftich »

WhitneyLand wrote: post #18
niftich wrote: post #5

Earlier quoted context omitted.

> but I'm not sure how this illustrates that SHA2 just got even faster, so it illustrates rather well that you wouldn't want to use it for password storage -- of course that was always true, but the improvement drives that point home.

My understanding is that SHA2 is fine for password storage, given a prudent number of hashing rounds.

It's fine to use a SHA2 variant HMAC in PBKDF2 with an obscene, ever-increasing number of rounds, but the scrypt paper [1] provides a detailed justification why you may want to switch to a dedicated password hashing function regardless. To quote their website [2]:

"We estimate that on [circa-2009] hardware, if 5 seconds are spent computing a derived key, the cost of a hardware brute-force attack against scrypt is roughly 4000 times greater than the cost of a similar attack against bcrypt (to find the same password), and 20000 times greater than a similar attack against PBKDF2."

Specifically, PBKDF2 is a tool to produce mostly-okay password storage hash from crypto primitives that are totally unfit for it, while bcrypt, scrypt, Argon2 are purpose-designed to make certain kinds of attacks difficult, like time-memory tradeoffs, parallelized custom hardware attacks, etc.

[1] http://www.tarsnap.com/scrypt/scrypt.pdf

[2] http://www.tarsnap.com/scrypt.html

Re: Show HN: Accelerating SHA256 by 100x in Golang on ARM

#22

Post by giovannibajo1 »

theparanoid wrote: post #20

The amount of assembly in the Go ecosystem is crazy, ~1% of the standard library is assembly. There are better ways.

Most of it is written to take advantage of special hardware instructions in CPUs. If you take OpenSSL (a C library), it's got many assembly code paths as well.

I'm not sure why this should be a problem, it just shows attention to performance in my opinion.

Re: Show HN: Accelerating SHA256 by 100x in Golang on ARM

#24

Post by mrb »

"Interestingly enough, there are actually comparable Intel SHA extensions to the ARM equivalents. Linux 4.4 has added support for this but so far we have not been able to identify any CPUs that will actually run this code."

Intel Goldmont is the only microarch that implements the instructions. It was "released" in April: http://www.extremetech.com/computing/226800-intels-new-low-c... But it is one of these annoying soft launches where the processors are not for sale anywhere, the specs are incomplete, and even ark.intel.com doesn't know about them. sigh

Re: Show HN: Accelerating SHA256 by 100x in Golang on ARM

#25

Post by y7 »

WhitneyLand wrote: post #18
niftich wrote: post #5

Earlier quoted context omitted.

> but I'm not sure how this illustrates that SHA2 just got even faster, so it illustrates rather well that you wouldn't want to use it for password storage -- of course that was always true, but the improvement drives that point home.

My understanding is that SHA2 is fine for password storage, given a prudent number of hashing rounds.

The problem with using iterated SHA2 for passwords is that GPU/FPGA/ASIC are orders of magnitude faster than the CPU-based "normal" usage. So while increasing the number of rounds makes it more difficult for an attacker, they already have an edge by being able to use faster technologies.

Ideally you'd use something like Argon2 or any of the other finalists from the Password Hashing Competition[1].

1: https://password-hashing.net/

Re: Show HN: Accelerating SHA256 by 100x in Golang on ARM

#27

Post by nickcw »

serge2k wrote: post #26

> WORD $0x4cdf2025 // ld1 {v5.16b-v8.16b}, [x1], #64 Why is the code written as words like this instead of just the assembly instructions?

Because the Go assembler doesn't have those instructions built in most likely.

That sort of thing is quite common in Go assembler. The assemblers are a little primitive and they force the assembly language for each processor into a common pattern, so when you are writing ARM assembler for instance, everything is backwards.

I imagine having rationalised the assemblers between processors somewhat it makes the core developers lives easier though who have to lightly touch lots of different processor assembler.

Re: Show HN: Accelerating SHA256 by 100x in Golang on ARM

#28

Post by sbierwagen »

loeg wrote: post #4
matt_wulfeck wrote: post #2

Are aes instructions new in aarch64 processors? I'm surprised this doesn't work magically "out of the box", but I'm not up to date with this stuff. Also, this is another really good reason never to use a sha2 as your hashing algo for password storage.

AES and SHA2 are completely different algorithms. > Also, this is another really good reason never to use a sha2 as your hashing algo for password storage. I don't know what you mean by this. I understand that SHA2 is poor for some things, but I'm not sure how this illustrates that.

  I don't know what you mean by this. I understand that 
  SHA2 is poor for some things, but I'm not sure how this 
  illustrates that.
You want password hashes to be very slow, (and to use a lot of RAM) to make brute force attacks difficult. SHA2 is fast, and having hardware support makes it even faster. This makes it a bad choice for a password hash.

Re: Show HN: Accelerating SHA256 by 100x in Golang on ARM

#29

Post by white-flame »

bradleyjg wrote: post #23
theparanoid wrote: post #20

The amount of assembly in the Go ecosystem is crazy, ~1% of the standard library is assembly. There are better ways.

What's the alternative in this case?

From a bird's eye view, adjust the compiler until it outputs the assembly you would have written. Hopefully this is done in such a way that such adjustments can be cross-beneficial across platforms, and can be easily created.

Re: Show HN: Accelerating SHA256 by 100x in Golang on ARM

#30

Post by kalden_ »

mrb wrote: post #24

"Interestingly enough, there are actually comparable Intel SHA extensions to the ARM equivalents. Linux 4.4 has added support for this but so far we have not been able to identify any CPUs that will actually run this code." Intel Goldmont is the only microarch that implements the instructions. It was "released" in April: http://www.extremetech.com/computing/226800-intels-new-low-c... But it is one of these annoying s…

It seemed to me that some Xeons had those since 2014. See https://software.intel.com/en-us/isa-extensions/intel-sha

Should something be understood instead?

Post reply on HN