Thanks! I don't have means for a proper review (I'm on a phone).

I believe SHA256 and SHA512 are actually the same thing (SHA2) but using different lengths. I'll read more about that and about SHA1, and see whether it could make sense to have a single SHA2 implementation, possibly sharing some code with SHA1.

How fast is this implementation, compared to using OpenSSL::Digest for example?

For the test vectors, I took the tests from sha1_spec.cr and rehashed them using shasum -a 256.
SHA-256 and SHA-512 are very similar indeed, but SHA-512 use 64 bit words. I've seen that crystal supports something close to C++ templates, so it may be possible to share some code between the two.

As for the speed, I don't know. This implementation is based on the existing Digest::SHA1 implementation. I am very new to crystal, so I have no idea how benchmarks are done here (do you have something like the Benchmark module in ruby?), but I would be glad to make one, and optimize the implementation.

Yes, our benchmark stdlib has roughly the same API as Ruby's and that of the benchmark-ips gem.

Ok, I did this small benchmark :

require "benchmark"
require "openssl"
require "digest/sha256"

n = 10000
strings = [] of String
ssl_sha256 = OpenSSL::Digest.new("sha256")

n.times do
    len = (rand * 100).to_i * 1024 # (1k..100k range)
    str = "a" * len
    strings << str
end

Benchmark.bm do |x|
    x.report("OpenSSL::Digest") do
        strings.each do |str|
            ssl_sha256.reset
            ssl_sha256 << str
            ssl_sha256.digest
        end
    end

    x.report("Digest::SHA256") do
        strings.each {|str| Digest::SHA256.digest(str) }
    end
end

It generates strings full of 'a's, with a random length between 1k and 100k.
On my machine, OpenSSL is twice as fast. However, when dealing with smaller strings (1 ~ 1k), Digest::SHA256 is up to twice as fast as OpenSSL. I suppose this come from the block reading method, in Digest::SHA* modules, this is done one byte at a time, while it is possible (but nontrivial due to padding) to read up to 512 bits into the buffer.

Thanks for digging more. I'll definitely take a closer look.

Any news about this ?

I originally implemented Digest::SHA1 in pure Crystal so we don't depend on openssl for websockets, which are needed for crystal play. The one that comes with openssl is fine, I think, so I don't think we'll want to implement every algorithm in pure crystal, mostly because of security reasons. In fact I can imagine removing Digest::SHA1 eventually once we can workaround some issues with building the compiler with openssl.