Feature #12802: Add BLAKE2 support to Digest

• Status: Open
• Assignee: -
• Target version: -

[bascule (Tony Arcieri)]

BLAKE2 is a fast, modern hash function, based on improvements to the BLAKE function, which was a SHA3 finalist. BLAKE2 performs about twice as fast in software as SHA3 winner Keccak:

https://blake2.net/

BLAKE2 has received an informational RFC 7693 from the IETF:

https://tools.ietf.org/html/rfc7693

It was added to the Python standard library in Python 3.6:

https://docs.python.org/3.6/library/hashlib-blake2.html

If there's interest in supporting BLAKE2 in the Ruby standard library, I can put together a patch.

[[e-mail] (ferdinand rosario)]

• Assignee set to core

[hsbt (Hiroshi SHIBATA)]

• Assignee deleted (core)

[nobu (Nobuyoshi Nakada)]

Is BLAKE2b unavailable if 64-bit integer is unavailable?

[bascule (Tony Arcieri)]

BLAKE2b will work on 32-bit CPUs but is optimized for 64-bit CPUs

[nobu (Nobuyoshi Nakada)]

I meant that BLAKE2b seems to need uint64_t.
If a compiler does not support such large integer type, isn't BLAKE2b usable on that platform?

[rhenium (Kazuki Yamaguchi)]

Is there still a supported environment without 64-bit integer support? ext/digest/sha2/sha2.c is already using 64-bit integers. It is compiled only when OpenSSL (or CommonCrypto) is not available, but the current versions of OpenSSL also require uint64_t.

But, I'm wondering, why not add the SHA-3 winner but only BLAKE2?

[nobu (Nobuyoshi Nakada)]

https://github.com/nobu/ruby/tree/feature/digest/sha3

[bascule (Tony Arcieri)]

Nice @ SHA-3 branch. I think it makes sense to add both.

The reason to add BLAKE2 in addition to SHA-3 is that BLAKE2 is, in some cases, over 3X faster than SHA-3 at an equivalent security level:

https://blake2.net/sandy.png

BLAKE2b on a modern Intel CPU is even faster than MD5, but provides substantially better security.

Something of a grassroots movement is pushing for the use of BLAKE2 anywhere speed is important, such as checksumming large files.

[naruse (Yui NARUSE)]

Nobuyoshi Nakada wrote:

I meant that BLAKE2b seems to need uint64_t.
If a compiler does not support such large integer type, isn't BLAKE2b usable on that platform?
Kazuki Yamaguchi wrote:
Is there still a supported environment without 64-bit integer support? ext/digest/sha2/sha2.c is already using 64-bit integers. It is compiled only when OpenSSL (or CommonCrypto) is not available, but the current versions of OpenSSL also require uint64_t.

But, I'm wondering, why not add the SHA-3 winner but only BLAKE2?

Many part of CRuby requires int64_t/uint64_t.
The point seems acceptable.

[shyouhei (Shyouhei Urabe)]

We looked at this issue at today's developer meeting. We could not be sure if we need our own implementation of BLAKE2 (or SHA3). Maybe a matter of time? We might need to use SHA3 someday, but OpenSSL should also have one at that time (BLAKE2 is there already).

Isn't it better for us to encourage people switching from Digest to OpenSSL?

[ioquatix (Samuel Williams)]

Wondering if we can review this again?

[knu (Akinori MUSHA)]

I feel a bit reluctant to have an implementation in our source tree and keep maintaining it when there's almost always a better implementation available in OpenSSL::Digest when you need one.

Here are some examples of Digest gems I wrote, so why not start with a gem and see if there are enough amount of users out there?

https://github.com/knu/ruby-digest-whirlpool
https://github.com/knu/ruby-digest-tiger