Commit 1c719b75 authored by Drew's avatar Drew

Separate keys out to different APIs

For some time now, there have been various issues with the key API.  It
is confusing (resolve #14), and in some cases dangerous (resolve #6).

The class `Key` is ambiguous as to whether or not it is a public or
private key.

What's more, keys are not interchangeable, and it is somewhere between
stupid and dangerous to pass one type of key to a function that expects
another.  We already have so-called *provenance* issues where public
keys sometimes contain and other times don't contain a reference to some
secret key (depending on whether they were generated togehter), and this
gets worse when you want to implement digital signature verification for
which public keys cannot be derived from private keys due to NaCl
internal implementation details.

To resolve this, the API formerly known as `Key` is now deprecated.
This breaks probably all programs, but the migration path should be
fairly minor (non-semver FTW!)

Internally, `Key` is now `KeyImpl` and implements all the side-channel
attack logic as previously.

New public protocols `PublicKey` and `SecretKey` expose external API
surface that was previously available NaOH-wide.  (One notable exception
are the constructors, you need to know what you're constructing in order
to make one, so those are key-type-specific).

Function parameters now take an appropriate particular key type, which
are implemented as structs.  However, the implementation is not copy-on-
write for the private key data, which continues to be guarded against
side-channel attacks.

For applications, the primary aspects of the migration are:

* Use a specific key type, instead of `Key`:
  try [CryptoBoxSecretKey, CryptoSecretBoxSecretKey, ChaCha20SecretKey],
  or check the parameter type of the function you're calling.
* If no specific type is appropriate, try `SecretKey`.
* Consider replacing custom file logic that references
  `humanReadableString` with `saveToFile`
* Custom key types can no longer be created; consider using typealiases
  or file a bug
parent 120880f2
Pipeline #1260 passed with stages