Ristretto Website

[hdevalence]

Tracking issue for putting content on the ristretto.group site.

In terms of the website content, here's a checklist from an email from @bitwiseshiftleft:

• [x] Motivation (like in the curve25519-dalek docs, but possibly expanded)
• [x] Human-readable spec
• [x] Test vectors for ristretto255
• [x] links to curve25519-dalek, libdecaf, and any other conformant implementations
• [x] link to the Decaf paper

It would also be nice to have some reasonable design for the site, and maybe links to high-res versions of the edwards-curve-coffee logo (if those exist).

[hdevalence]

@tarcieri Did you want to make a skeleton for the website?

[tarcieri]

Absolutely

[hdevalence]

We (me and @isislovecruft) started working on trying to fill in the website content and got stuck on how to make static pages in Hexo... it seems like it's optimized for the blog usecase, not for writing documentation.

So I'm going to work on dumping it entirely and using mdbook instead. I'm not quite sure how to get Travis to have both a Rust toolchain and also an npm for all of the firebase tools. But I think it's possible since the rust-wasm stuff uses npm. Alternately we could just put the HTML somewhere.

[tarcieri]

A couple options:

1) ditch CI builds, firebase deploy from a local copy 2) switch to CircleCI which would let us use a Docker image we configure ourselves to do the builds, which would let us mix/match language tools while also keeping build times down

[hdevalence]

Re: #1, in the long run I think that we're not going to be changing the site that much, so I'm not sure whether it makes sense to sink a ton of effort into the Fully Automated Luxury Deploy Pipeline if we're going to run it infrequently.

[hdevalence]

Update, the hybrid Rust-NPM Travis config worked first try. The current master branch now has an mdbook skeleton.

[hdevalence]

Checked off the motivation section (#20) and the link to the decaf paper.

[hdevalence]

Edited the checklist to drop the ristretto448 test vectors for the start, since I'm not sure there's a reason to use Ristretto there instead of Decaf (we can always add ristretto448 test vectors later).

[hdevalence]

Updated checklist since #36 is merged.

[fscoto]

Is the checklist still pending as-is? The ristretto255 implementations page links to various implementations now.

Re ristretto448: Personally, I think the main issue with saying “just use Decaf” is that there are no test vectors, plus the definition of what constitutes a negative number as well as encoding of field elements is implementation-defined. You've noted on the curve selection for the Doppio group, Decaf is much easier and straightforward in the h = 4 case, both conceptionally and practically.

The reason specifying something for Ed448-Goldilocks at all is useful is because of I-D.draft-irtf-cfrg-voprf-03 specifying in § 8.1.4 that they only consider ciphersuites providing 196 bits of security (Not sure if this was supposed to be 192 or if they really did mean 196 bits but include NIST P-384 regardless). While the Internet Draft does account for required cofactor hacks, having a more elegant alternative to implement the IETF (V)OPRF on would probably be useful from an implementation perspective, and a lot less scary.

[hdevalence]

Yup, the checklist is complete and I think the issue just wasn't closed yet. It might be helpful to create a new issue for the 448-related decaf/ristretto question rather than using this one -- it's worth discussing on its own, I think.