google / hctr2 Goto Github PK

HCTR2 specification and test vectors

License: MIT License

Shell 0.03% Python 2.01% Meson 0.11% Assembly 1.11% C 87.95% TeX 8.79%

hctr2's Introduction

HCTR2

HCTR2 is a length-preserving encryption mode that is efficient on processors with instructions to accelerate AES and carryless multiplication, e.g. x86 processors with AES-NI and CLMUL, and ARM processors with the ARMv8 Crypto Extensions.

Usually, the right mode to use for encryption is a mode like AES-GCM or AES-GCM-SIV which includes a tag as well as a fresh nonce. However there are some applications, such as disk encryption, where the ciphertext must be the same size as the plaintext and there is no room for such information. For disk encryption, AES-XTS is often used, but it operates on each block of the plaintext independently, so changes to a given plaintext block affect only the corresponding ciphertext block and vice versa, revealing more information to the attacker than necessary. HCTR2 is a tweakable super-pseudorandom permutation: any change to the plaintext will result in an unrecognizably different ciphertext and vice versa.

For more information, see the HCTR2 paper.

File layout

paper/: LaTeX sources for our paper presenting HCTR2
test_vectors/other/: Test vectors we use to validate our implementations of other primitives
test_vectors/ours/: Test vectors we generate, in JSON format
python/: Python implementation and test vector generation
benchmark/: C implementation and benchmarking code
third_party/: derived works covered by a different license than our main MIT license

Notices

third_party/ includes derived works not covered by the MIT license; specifically software derived from the Linux kernel and licensed under GPLv2.

We include here a variety of algorithms and implementations; we make no guarantee they are suitable for production use.

This is not an officially supported Google product.

hctr2's People

Contributors

Stargazers

Watchers

Forkers

doytsujin

hctr2's Issues

This PR makes it so that there are two test vectors per message size per key size, so 6 total per message size. Maybe cut that down to 1 per message size per key size, so 3 total per message size? Or even less and just assign key sizes randomly.

not very effective to have 2 test vectors per message length per key length. Problems are more likely to arise for different length inputs, not for different input contents. The xctr test vectors are especially odd, as they only test 32 and 255-byte messages, but have 6 test vectors for each length. We could get better test coverage in the same number (or fewer) of test vectors by focusing on different lengths rather than different contents.

The cmp and b instructions in this loop shouldn't be necessary. It would be possible to rework this so that a subs and conditional branch are sufficient.

This produces "hctr2_tv_template" and "xctr_tv_template". It should be "hctr2_aes_tv_template" and "xctr_aes_tv_template".