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
And consider the NaCl and libsodium API, the box APIs for authenticated public-key encryption, and the sealed box APIs for anonymous public-key encryption.
Create an analogous API here using XChaCha20-Poly1305 and X25519. This should cover sending encrypted messages and signed messages.
Essentially, given Alice and Bob both have XDH keypairs, we can compute a shared secret to generate a symmetric key. Implementing a perfect-forward-secrecy variant involving ephemeral keypairs and signatures for authentication rather than the static XDH keys would be out of scope for messages at this level and is scoped in #6.
The text was updated successfully, but these errors were encountered:
After much experimentation, it seems like Ristretto255 is a bit easier to use for this purpose. https://github.com/jedisct1/libsodium-signcryption provides a nice pattern and implementation. Combined with a similar strategy to #4, a complete message crypto API is possible.
This implementation aims to be compatible with libsodium ristretto255 signcryption and XChaCha20-Poly1305. This relates to #5 with an enhanced implementation of #1.
I created a small test program in C++ using libsodium-signcryption to generate test data and updated the test here to match accordingly: https://github.com/o1c-dev/o1c-compat-tests
Consider the design of Themis: https://docs.cossacklabs.com/themis/crypto-theory/cryptosystems/secure-message/
And consider the NaCl and libsodium API, the box APIs for authenticated public-key encryption, and the sealed box APIs for anonymous public-key encryption.
Create an analogous API here using XChaCha20-Poly1305 and X25519. This should cover sending encrypted messages and signed messages.
Essentially, given Alice and Bob both have XDH keypairs, we can compute a shared secret to generate a symmetric key. Implementing a perfect-forward-secrecy variant involving ephemeral keypairs and signatures for authentication rather than the static XDH keys would be out of scope for messages at this level and is scoped in #6.
The text was updated successfully, but these errors were encountered: