Roadmap for 1.0 release

[hannesm]

The next release will break the API, and be a 1.0. Notably:

• remove P224 due to not much usage mirage-crypto-ec: remove NIST P224 support #209
• remove Hash, use digestif remove Hash #213
• remove sexplib0 converters from mirage-crypto-pk mirage-crypto-pk: remove s-expression converters and sexplib0 dependency #208
• improve performance of symmetric ciphers (AES-GCM, Chacha20-Poly1305)
  • including use string in chacha/poly1305 Chacha20-Poly1305: use string instead of cstruct #203
• remove usage of Cstruct.t, use string in the API
  • mirage-crypto-ec moves to string mirage-crypto-ec: move API to string (instead of cstruct) #210
  • mirage-crypto-pk moves to string mirage-crypto-pk: revise API to not use Cstruct.t #211
  • mirage-crypto moves to string remove cstruct from mirage-crypto #214
  • mirage-crypto-rng moves to string mirage-crypto-rng: use string instead of cstruct #212
  • use Digestif instead of Mirage_crypto.Hash mirage-crypto-rng: use string instead of cstruct #212 use digestif 1.2.0 API #215
• eventually add encrypt_into API to move the allocations to the call site (raising exceptions if too small buffers are passed in)
  • an initial experiment WIP aead into, WIP #204
• investigate and benchmark usage of global buffers (see Fix some data-races into mirage-crypto #186), now that bytes/string are used avoid global buffers #219
• avoid data races in des mirage-crypto: revise DES to avoid global state in key derivation / key usage #223 Fix some data-races into mirage-crypto #186
• (eventually) avoid mutating globals (Atomic) Use an atomic instead of a reference to be domain-safe #221 Fix some data-races into mirage-crypto #186
• Revise API (remove intermediate modules) #224

If you've further comments or are keen to retain the old API, please comment in this issue. The 0.x series will be unsupported at the point when 1.0 is released.

[hannesm]

We may want to think and address the "storing secret keys in memory (with a GC around)", as raised in https://discuss.ocaml.org/t/ann-mirage-crypto-0-11-3-with-more-speed-for-elliptic-curves-and-the-future-roadmap-of-mirage-crypto/14200/7 (e.g. rust has https://github.com/cesarb/clear_on_drop)

[Firobe]

Not a breaking change: I'd like to finish the work on NIST curves scalar multiplication for the non-base case, to improve performance a bit more for key generation in particular (which won't be pre-computed)

[Firobe]

Also, would 1.0 be the right time to discuss if we keep maintaining 32-bit support? Not to drop it for 1.0, but at least begin surveying potential users and announcing deprecation if we decide so

[hannesm]

I think the 32 bit support is to discuss for a 1.0, but I'm unsure whether it is worth dropping (esp. nowadays that we have CI machines (arm32, x86_32), and not too much trouble with 32 bit (or is there lots of trouble?)

In respect to mirage-crypto-ec, since cl.exe/dkml seem to use the 32 bit code paths (since 128bit integers aren't available), I assume removing 32 bit support wouldn't clean that up!?