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
This could be inspired by libsodium's. The high-level should at least accommodate returning a shared secret that is safer to use directly, than that returned in hazardous.
I think it would be a good idea to consider an approach here, that enforces one-time uses of key-pairs for X25519, as in most cases these should be generated freshly for each instantiation of a protocol sessions. So an API that takes ownership of the private key such that it can only be used once.
When implementing the same key-exchange approach as libsodium, it's important to note that because orion uses X25519 compliant with the RFC, then orion will probably reject less public keys than libsodium, because of their blacklist of public X25519 keys. This difference should be mentioned in the documentation.
TODO:
Update the TODO refs in the hazardous::ecc::x25519 docs
This is a follow up to #197. See also #199.
This could be inspired by libsodium's. The high-level should at least accommodate returning a shared secret that is safer to use directly, than that returned in
hazardous
.I think it would be a good idea to consider an approach here, that enforces one-time uses of key-pairs for X25519, as in most cases these should be generated freshly for each instantiation of a protocol sessions. So an API that takes ownership of the private key such that it can only be used once.
When implementing the same key-exchange approach as libsodium, it's important to note that because orion uses X25519 compliant with the RFC, then orion will probably reject less public keys than libsodium, because of their blacklist of public X25519 keys. This difference should be mentioned in the documentation.
TODO:
hazardous::ecc::x25519
docskex
module orion-fuzz#17)The text was updated successfully, but these errors were encountered: