Open jvz opened 3 years ago
By making the token a little bigger to include a version constant, this will make it easier to support other key types in #7 with potentially different token sizes.
One key design issue here should also include breaking up larger data buffers into chunks of authenticated encrypted blocks. This can also incorporate the padme padding algorithm to remove side channel info about message lengths.
Consider the design of Themis: https://docs.cossacklabs.com/themis/crypto-theory/cryptosystems/secure-cell/
Similarly, in NaCl and libsodium, this concept is exposed as a secretbox API for authenticated encryption, and the secretstream API is used as a higher level API for authenticated encryption of arbitrary length data streams (the lower level API should be limited to smaller, well tested data limits).
The high level API to develop here should address a similar use case to secretstream.
Note that password-based keys are out of scope for this issue and is covered in #7.