Merlin dep is broken on big-endian machines

[rozbb]

merlin fails tests on big endian machines dalek-cryptography/merlin#60 (comment), due to some underlying casting that isn't respectful of endianness. It probably isn't a security issue, but I don't like it.

Currently there are two PRs on two different merlin repos that fix this.

• In dalek-cryptography/merlin this replaces the STROBE impl entirely with strobe-rs
• In zkcrypto/merlin this fixes the incorrect cast that the keccakf function does

If we don't have write access to either repo, we might have to fork and maintain yet another :(

[burdges]

I'd wager deterministic batch verification is not used by many people yet, and this crates gets it wrong anyways, and ed25519-zebra uses Sha512 for this. I'd swap in Sha512 now and slap on a warning that deterministic batching is unstable.

[rozbb]

this crate gets it wrong anyways

How so? It would be really bad if we published something broken

I'd swap in Sha512 now

In place of what? Merlin? Using Merlin is far more secure than making my own transcript mechanism. STROBE has figured all of these things out for me.

[burdges]

You need the validity criteria to be permissive like ed25519-zebra, not merely in the batch verification but in the stand along verification too. It's not I think deterministic batch verification otherwise.

It's merely an xof that sha512 lacks, not the full transcript functionality, so you'd hash the batch and then expand via cloning the sha512 state or chacha or whatever ed25519-zebra does. I like merlin but it's a dependency and ed25519 uses sha512

[tarcieri]

ed25519-dalek has moved to: https://github.com/dalek-cryptography/curve25519-dalek/tree/main/ed25519-dalek

If you feel this issue has not yet been addressed, please request this issue be moved to that repo by leaving a comment, or open a new issue on that repo.