vidpf: Use the `Xof` API from the base draft for hashing

[cjpatton]

Closes #17.

Replace SHA-3 with XofShake128 (SHAKE128). This has two benefits:

1. It simplifies domain separation, which will be useful if we end up needing to model instances of this object as random oracles in security proofs.

2. It allows us to easily swap XofShake128 with XofTurboShake128 (TurboSHAKE128) as required in the next draft (draft-irtf-cfrg-vdaf-08).

We also replace update the base "cs proof" by using the SHA256 hash of a fixed string instead of SHA3. This is because SHA256 is more likely to be implemented in common cryptographic libraries.

[hannahdaviscrypto]

Small question: don't we need SHA3 (or another indifferentiable hash function) for the FLPs? So in the case where SHA256 is implemented but SHA3 isn't, Mastic may not be a good candidate regardless of the choice for the cs proof.

[cjpatton]

Small question: don't we need SHA3 (or another indifferentiable hash function) for the FLPs? So in the case where SHA256 is implemented but SHA3 isn't, Mastic may not be a good candidate regardless of the choice for the cs proof.

This change is replacing SHA3 with SHAKE128, not SHA256. SHAKE128 is Keccak-based, just like SHA3.

[hannahdaviscrypto]

Small question: don't we need SHA3 (or another indifferentiable hash function) for the FLPs? So in the case where SHA256 is implemented but SHA3 isn't, Mastic may not be a good candidate regardless of the choice for the cs proof.

This change is replacing SHA3 with SHAKE128, not SHA256. SHAKE128 is Keccak-based, just like SHA3.

Sorry, miscommunication. My comment was in reference to the ROOT_PI_PROOF only, which this commit changes from a SHA3 digest to a SHA256 digest. The initial PR description suggests this is because SHA256 is more likely to be implemented, but we're going to need a Keccak implemenation regardless.

[cjpatton]

Small question: don't we need SHA3 (or another indifferentiable hash function) for the FLPs? So in the case where SHA256 is implemented but SHA3 isn't, Mastic may not be a good candidate regardless of the choice for the cs proof.

This change is replacing SHA3 with SHAKE128, not SHA256. SHAKE128 is Keccak-based, just like SHA3.

Sorry, miscommunication. My comment was in reference to the ROOT_PI_PROOF only, which this commit changes from a SHA3 digest to a SHA256 digest. The initial PR description suggests this is because SHA256 is more likely to be implemented, but we're going to need a Keccak implemenation regardless.

That's my bad, I didn't provide enough context.

We're using SHAKE, but when we align with the latest VDAF draft (draft-irtf-cfrg-vdaf-08), we will switch to TurboSHAKE. (See https://mailarchive.ietf.org/arch/msg/cfrg/cFTfEq9zWSzgnomY4TMEeXPcoVU/ for reasoning.) SHAKE and TurboSHAKE both use Keccak (as SHA3 does) but but TurboSHAKE uses half as many rounds. Thus an implementation of permutation may not be interchangeable.

In fact, the function we use to derive the root proof doesn't matter. I expect implementations to hard-code the hash in any case. We're sort of using this value as a salt: we want it to be unlikely that some other application would have the same hard-coded salt in it. We could just pick a random 32-byte number, but using a hash of a public value ensure there are no "nothing-up-my-sleeve" constants in the spec (https://words.filippo.io/dispatches/seeds-bounty/).

I'd be happy to go back to using SHA3 instead.

[hannahdaviscrypto]

Small question: don't we need SHA3 (or another indifferentiable hash function) for the FLPs? So in the case where SHA256 is implemented but SHA3 isn't, Mastic may not be a good candidate regardless of the choice for the cs proof.

This change is replacing SHA3 with SHAKE128, not SHA256. SHAKE128 is Keccak-based, just like SHA3.

Sorry, miscommunication. My comment was in reference to the ROOT_PI_PROOF only, which this commit changes from a SHA3 digest to a SHA256 digest. The initial PR description suggests this is because SHA256 is more likely to be implemented, but we're going to need a Keccak implemenation regardless.

That's my bad, I didn't provide enough context.

We're using SHAKE, but when we align with the latest VDAF draft (draft-irtf-cfrg-vdaf-08), we will switch to TurboSHAKE. (See https://mailarchive.ietf.org/arch/msg/cfrg/cFTfEq9zWSzgnomY4TMEeXPcoVU/ for reasoning.) SHAKE and TurboSHAKE both use Keccak (as SHA3 does) but but TurboSHAKE uses half as many rounds. Thus an implementation of permutation may not be interchangeable.

In fact, the function we use to derive the root proof doesn't matter. I expect implementations to hard-code the hash in any case. We're sort of using this value as a salt: we want it to be unlikely that some other application would have the same hard-coded salt in it. We could just pick a random 32-byte number, but using a hash of a public value ensure there are no "nothing-up-my-sleeve" constants in the spec (https://words.filippo.io/dispatches/seeds-bounty/).

I'd be happy to go back to using SHA3 instead.

Nope, that makes perfect sense. Thanks for the additional explanation!