Module lair_keystore_api::internal::crypto_box [−][src]
Expand description
Wrapper around whatever upstream crate we’re using for crypto_box. Currently the crypto_box crate, future likely to be libsodium.
Structs
“Additional associated data” as per the aead rust crate Payload. May be empty. Must be valid if present.
Data to be encrypted. Not associated with a nonce because we enforce random nonces.
The nonce and encrypted data together. @todo include additional associated data?
Newtype for the nonce for safety.
Constants
The delimiter for padding as per ISO 7816-4.
The size of blocks to pad encrypted data to. We have no idea how big incoming data is, but probably it is generally smallish. Devs can always do their own padding on top of this, but we want some safety for unpadded data. Libsodium optionally supports ISO 7816-4 padding algorithm. @see https://doc.libsodium.org/padding#algorithm
Length of the crypto box aead nonce. Ideally this would be exposed from upstream but I didn’t see a good way to get at it directly.
Functions
@todo all of this can be opened up to be more flexible over time. Eventually all possible input such as nonces and associated data should be settable by the external interface. In the short term everyone is getting their heads around the 80/20 usage patterns that are as safe as we can possibly make them to avoid subtleties that lead to nonce or key re-use etc.
Wrapper around crypto_box_open from whatever lib we use.
Exact inverse of crypto_box_open so nonce must be provided in CryptoBoxEncryptedData.
The recipient’s private key encrypts from the sender’s pubkey.