Crypto dependencies

[simon-friedberger]

It might be difficult to pull ring into a project that already has a crypto library dependency, maybe even boringSSL, which ring seems to be based on but not using.
Especially since both the versioning and the licensing of ring are a bit problematic.

I don't have a good overview of the Rust crypto landscape but if we could keep the VDAF core free of ring that might simplify things in some cases.

In general it would be ideal if we could somehow support multiple cryptolibs.

I am also not sure how dependencies should be handled in general. Currently, cargo tree -d shows that we have the following duplicates:

1. aes as 0.8.1 and 0.7.5
2. cipher as 0.3.0 and 0.4.3
3. ctr as 0.8.0 and 0.9.1
4. itoa as 0.4.7 and 1.0.1

[cjpatton]

It seems like most of our ring dependencies are for ENPA (i.e, Prio v2) stuff. Perhaps ENPA could be put behind a feature flag?

Note that #52 is related.

[simon-friedberger]

I had a look and afaict the dependencies are caused by:

1. Prio2 ECIES which needs: ring, aes-gcm (which in turn uses aead, aes, cipher, ctr, ....)
2. The PRG in vdaf/prg.rs which needs: aes, cipher, cmac, ctr
   Where the latter is iiuc still up for discussion.

[tgeoghegan]

+1 to hiding ENPA behind a feature flag, since nobody but the existing deployments should ever use that stuff.

[tgeoghegan]

@simon-friedberger is there anything left to do here now that #272 is merged?

[tgeoghegan]

We discussed offline -- closing this, and I will ship a patch release of prio to crates.io, just as soon as I can get #277 merged.