[−][src]Crate arx_kw
This library features implementations of the ARX-KW family of novel Key Wrap constructions.
Background
ARX-KW was first presented in this paper written by Satō Shinichi and submitted to the IACR Cryptology ePrint Archive in January 2020. As the name
suggests, these constructions make extensive use of add-rotate-xor algorithms: each of the four
variants specified involves both the SipHash-2-4 pseudorandom function with 128-bit output and
a stream cipher from the ChaCha
family of stream ciphers.
ARX-KW is a cipher for deteministic, authenticated encryption which aims to provide strong authenticity and confidentiality while minimizing the storage overhead and simplicity of use when compared to existing constructions using the ChaCha cipher either which require keeping state for a nonce and a block counter or have a substantial storage overhead in order to manage the nonce statelessly.
ARX-KW has a static overhead of 128 bits for each of its four variants without the need to keep state for the nonce used by ChaCha, making the storage overhead only 50% for a 256-bit key
Use
When
As noted above, the ARX-KW constructions are Key Wrap algorithms, designed and intended to protect other cryptographic keys using symmetric encryption. It is important to note that as ARX-KW, like all Key Wrap constructions, was designed with the expectation that its input data is highly entropic, as is the case with secret keys. This is because it is a deterministic encryption scheme and will always yield the same ciphertext output for a given input; if used to encrypt low-entropy data (as with general-purpose encryption schemes), it is vulnerable to "leakage", described here:
Deterministic encryption can leak information to an eavesdropper, who may recognize known ciphertexts. For example, when an adversary learns that a given ciphertext corresponds to some interesting message, they can learn something every time that ciphertext is transmitted. To gain information about the meaning of various ciphertexts, an adversary might perform a statistical analysis of messages transmitted over an encrypted channel, or attempt to correlate ciphertexts with observed actions (e.g., noting that a given ciphertext is always received immediately before a submarine dive).
If used to store secret key material (by nature high entropy), this is not an issue as an attacker gains no information about the key encapsulated within.
How
Each public module of this crate contains a struct corresponding to one of the four specified
ARX-KW-8-2-4 variants: ARX-8-2-4-E
, ARX-8-2-4-G
, ARX-8-2-4-EX
, and ARX-8-2-4-GX
. If you're not
sure which to use, gx::GX
is recommended. The functionality is provided by the ArxKW
trait,
so that will need to be in scope to use the encrypt
and decrypt
methods.
Encrypt a key
extern crate hex; use hex::FromHex; use arx_kw::{ ArxKW, gx::GX }; // Encrypt a key using ARX-KW-8-2-4-GX // The values used here are from the test vectors in the original ARX-KW paper. // Inputs let k = <[u8; 32]>::from_hex("000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f")?; // The key we are using to wrap the plaintext secret key let p = <[u8; 32]>::from_hex("deadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef")?; // The plaintext secret key we want to store/transport securely // Expected outputs let c_expected = <[u8; 32]>::from_hex("2f83f391c97f3606ccd5709c6ee15d66cd7e65a2aeb7dc3066636e8f6b0d39c3")?; // The ciphertext which contains the wrapped key. let t_expected = <[u8; 16]>::from_hex("016325cf6a3c4b2e3b039675e1ccbc65")?; // The authentication tag let (ciphertext, authentication_tag) = GX::encrypt(&k, &p)?; assert_eq!(ciphertext, c_expected); assert_eq!(authentication_tag, t_expected); // Decrypt the wrapped key let plaintext = GX::decrypt(&k, &ciphertext, &authentication_tag)?; assert_eq!(plaintext, p);
Modules
e | |
ex | |
g | |
gx |
Enums
ArxKwError | |
InvalidLengthError |
Traits
ArxKW | Provides encryption and decryption capabilites |
Type Definitions
AuthTag | The type used as the authentication tag (unencrypted data to be stored alongside encrypted keys)
This is the same for all variants at time of writing (a single, static 128 bits), making
for a 50% storage overhead for a 256-bit key like those used for |