Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(iroh-willow): Private Area Intersection #2422

Merged
merged 8 commits into from
Jul 2, 2024
Merged

feat(iroh-willow): Private Area Intersection #2422

merged 8 commits into from
Jul 2, 2024

Conversation

Frando
Copy link
Member

@Frando Frando commented Jun 27, 2024

Description

Implementation of Private Area Intersection as defined in the WGPS spec.

The implementation of the PaiFinder is ported from the TypeScript implementation in willow-js.

The PR currently uses the following cryptographic scheme:

  • The PsiGroup uses RistrettoPoint from curve25519_dalek, and hash_to_group uses sha512 for hashing to a curve point. Went with sha512 because RistrettoPoint::hash_from_bytes needs a digest with 64 bytes length.
  • The PsiScalar uses the Scalar type from curve25519_dalek

The smoke test passes 🔥

Breaking Changes

Notes & open questions

Earthstar) uses RFC 9380 with edwards25519_XMD:SHA-512_ELL2_RO_, which hashes to edwards25519, a different curve from ristretto255.

We want to use the RFC as well, it seems the best option after a longer discussion (TODO: Link to Discord?). The curve25519_dalek crate from RustCrypto only supports hash-to-curve for ristretto255, but there's an open PR for hashing to an edwards25519 curve: dalek-cryptography/curve25519-dalek#377, which is waiting for review and might need updates because it was developed against a draft of the RFC.

Change checklist

  • Self-review.
  • Documentation updates if relevant.
  • Tests if relevant.
  • All breaking changes documented.

@Frando Frando changed the base branch from main to willow June 27, 2024 16:29
@matheus23
Copy link
Contributor

The PsiGroup uses RistrettoPoint from curve25519_dalek, and hash_to_group uses sha512 for hashing to a curve point. Went with sha512 because RistrettoPoint::hash_from_bytes needs a digest with 64 bytes length.

SHA512 is not a bad choice, but FWIW, blake3 supports extended output functions - so you can make blake3 give you 64 byte hashes.

That said, the most important factor in choosing this stuff (in my opinion) would be checking with what other people are planning on using. Are the earthstar folks planning to go with SHA-512, too?

@Frando
Copy link
Member Author

Frando commented Jun 27, 2024

FWIW, blake3 supports extended output functions - so you can make blake3 give you 64 byte hashes.

Cool, I didn't know. However the rustcrypto Digest trait is impl'd in blake3 with size 32, so we'd have to write some wrapper type that impls Digest with size 64 ourselves (if we wanted to use blake3 over sha512 here).

Are the earthstar folks planning to go with SHA-512, too?

Earthstar uses SHA512 too:

https://willowprotocol.org/earthstar/spec/index.html#es6_wgps_pai

The hash_into_group function encodes a fragment using the encode_fragment function that we define below, then uses the encoding as input to edwards25519_XMD:SHA-512_ELL2_RO_ with the ascii encoding of the string earthstar6i as the domain separation tag.

I did not yet add a domain separation tag but that'll be a straightforward change.

@AljoschaMeyer
Copy link

AljoschaMeyer commented Jun 27, 2024

Jup, we went with the recommendation in RFC9830 RFC9380 . Note that Earthstar uses Edwards25519 as its curve though, not ristretto255.

@Frando
Copy link
Member Author

Frando commented Jun 27, 2024

Jup, we went with the recommendation in RFC9830. Note that Earthstar uses Edwards25519 as its curve though, not ristretto255.

Aha, interesting. Will read more, I don't know enough about the differences between these primitives.

I used ristretto because curve25519_dalek has RistrettoPoint::from_hash but there's no such method on EdwardsPoint.

@matheus23
Copy link
Contributor

This is the RFC @AljoschaMeyer is referring to: https://www.rfc-editor.org/rfc/rfc9380.html

@matheus23
Copy link
Contributor

FWIW, blake3 supports extended output functions - so you can make blake3 give you 64 byte hashes.

Cool, I didn't know. However the rustcrypto Digest trait is impl'd in blake3 with size 32, so we'd have to write some wrapper type that impls Digest with size 64 ourselves (if we wanted to use blake3 over sha512 here).

Not that we should do it, this is how you'd do it: use the blake3 crate (ignore the rustcrypto Digest trait):

let mut hasher = blake3::Hasher::new();
hasher.update(b"Hello, world!");
let mut xof = hasher.finalize_xof();
let mut output = [0u8; 64];
xof.fill(&mut output);

@Frando
Copy link
Member Author

Frando commented Jul 2, 2024

I am going to merge this.
Left TODOs in the code for switching to ed25519 with RFC9380 once the crypto is available (or we wrote it).

@Frando Frando merged commit 2c81e63 into willow Jul 2, 2024
18 of 24 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

3 participants