Why SHA256 and not SHA3-256?

[valerini]

It seems more systems start to move to SHA3, since the keccak family gives a more diverse crypto-toolkit (also protection against length-extension attacks), so some projects find themselves in the situation where they need to support both SHA-3 (for their application) and SHA-2 (to comply with the signature standard, e.g. EdDSA). But support for security critical algorithms is quite complex, so it seems advantageous to keep the security-critical code to the bare minimum if possible, e.g. support one hash function instead of two.

Could you elaborate on what was your rational for choosing SHA-2?

[JustinDrake]

One of the big consumers of BLS signatures is the blockchain industry (Dfinity, Eth2, Algorand, Harmony, Cosmos, Chia, and others). The overwhelming application-layer hash function for blockchains is SHA256, and NIST recommends it as the hash function for interoperability.

[mimoo]

I'd like to see the RFC support SHA-3 and SHAKE (and cSHAKE) as well. Otherwise we're probably going to have to write an extension/another RFC later on.

(I'd rather have cSHAKE everywhere, but I can understand how some project might want SHA-3 instead)

[kwantam]

Just to be 100% sure I understand the issue: this is a discussion about the ciphersuites that are specified, right? In other words, is it reasonable to interpret this as a request to specify a SHA3--based ciphersuite in addition to the SHA2--based one?

(Because, as I'm sure you know, the document is generic with respect to the underlying hash function, meaning that of course you can use SHA-3 if you wish.)

Regarding length extension: that seems to be out of scope here, since every use of H (including in the underlying hash-to-curve invocation) is wrapped in HKDF, which in turn is based on HMAC.

[mimoo]

Indeed, it sounds like this is more of a problem on the hash to curve side not providing enough ciphersuites right?

[valerini]

Yes, exactly, the request is to specify both ciphersuites. The HKDF is also another place targeting specifically SHA-2 in the spec by referring to RFC5869, but the keccak family offers a cSHAKE function that can be used as an HKDF.

[kwantam]

Yes, exactly, the request is to specify both ciphersuites.

Great, thanks for the clarification.

The HKDF is also another place targeting specifically SHA-2 in the spec by referring to RFC5869, but the keccak family offers a cSHAKE function that can be used as an HKDF.

I'm not sure I agree that HKDF somehow implies SHA-2. It's a generic construction, and in particular it's one that's completely safe to use with SHA-3. To be sure, there are other ways to use SHA-3 as a KDF. The advantage of specifying HKDF is that we can safely specify one KDF to use with any underlying hash function.

As some more background, we discussed this in the context of hash-to-curve (part of the discussion is here: cfrg/draft-irtf-cfrg-hash-to-curve#137; part was offline) and decided that the complexity of supporting multiple hash-based KDFs far outweighed any potential benefit. In particular, even if the computational cost of SHAKE is significantly less than that of HKDF, that does not translate to any improvement in overall cost because the KDF is effectively free compared to the rest of hash-to-curve.

So: we can (should) certainly chat about this (I see cfrg/draft-irtf-cfrg-hash-to-curve#165 opens the discussion), but my current thinking (which---of course---could change) is that this is a bad idea.

[kwantam]

Hi @valerini quick question about this: hash_to_curve now supports SHAKE and other constructions (see issue 212 over there for a discussion of why). So now we could pretty easily specify a suite that uses SHAKE and/or SHA-3 for BLS.

Here's the question: it seems like we'd definitely want to use SHAKE-128 for hash-to-curve, but what about the hash function H for the BLS suite? It's used in the KeyGen function. Seems like SHA3-256 would be a reasonable pairing with SHAKE-128, but it's slightly a shame to have to use two different primitives. I guess we could just use SHAKE-128 with 32-byte outputs...

Thoughts?

---

The suite would probably be defined like this:

BLS_SIG_BLS12381G1_XOF:SHAKE-128_SSWU_RONUL:

• SC: basic
• SV: minimal-signature-size
• EC: BLS12-381
• H: SHA3-256 (or SHAKE-128 with 32-byte output???)

• hash_to_point: BLS12381G1_XOF:SHAKE-128_SSWURO with domain-separation tag

  BLS_SIG_BLS12381G1_XOF:SHAKE-128_SSWU_RO_NUL_

where BLS12381G1_XOF:SHAKE-128_SSWURO is a hash-to-curve suite identical to BLS12381G1_XMD:SHA-256_SSWURO except that expand_message uses the expand_message_xof variant instantiated with SHAKE-128.

Does this seem like it would be reasonable for your use-case? Do you prefer SHA3-256 or SHAKE-128 for H?

[kwantam]

ah also cc @mimoo

[mimoo]

if SHAKE is already used in one place, better to use in the other place instead of SHA-3.

BTW if you use cSHAKE then you can add a custom string to separate the two use cases.

[kwantam]

Good point about cSHAKE.

In hash-to-curve, we want to be able to support any XOF (not just ones that explicitly support customization / domain separation), so we append a prefix-free-encoded domain separation tag. I believe this captures the difference between SHAKE and cSHAKE (but please let me know if this doesn't seem correct).

I'll have to give some more thought to a clear way to define BLS's KeyGen in terms of (c)SHAKE.