• Drew's avatar
    Separate keys out to different APIs · 1c719b75
    Drew authored
    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
    1c719b75
Dockerfile 562 Bytes