You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: