Expand coverage of different buffer sizes.

[jhb]

Summary

• When -z is used, include small buffers from 1 to 32 bytes to test stream ciphers. Note that while AES-XTS claims to support a block size of 1 in OpenSSL, it does require a minimum of 1 block of cipher text as it is not a stream cipher but depends on CTS to pad out the final partial block.

• Permit multiple AAD sizes to be set via multiple -A options, or via -z. When -z is set, use small buffers from 0 to 32 bytes followed by powers of 2 up to 256. When multiple sizes are specified, the ETA and AEAD algorithms perform the full matrix of AAD sizes by payload sizes.

• Only warn on unchanged ciphertext instead of erroring. The currently generated ciphertext and key for AES-CTR with a buffer size of 1 results in plaintext that matches the ciphertext.

Test Plan

• cryptocheck -z against cryptosoft0, aesni0, and ccr0

[jhb]

Currently several AES-CCM tests this now covers fail on both aesni0 and cryptosoft0. They pass on ccr0 though, so I think this is a bug in sys/opencrypto/cbc_mac.c. XTS also gives various warnings with -z due to lack of cipher text stealing support in cryptosoft. The tests which have cipher text which matches plain text:

cryptocheck: OpenSSL aes-ctr+sha224hmac (31, 1): cipher text unchanged
cryptocheck: OpenSSL aes-ctr192+sha1hmac (11, 1): cipher text unchanged

It is debatable how useful that check really is? We don't have it in the AEAD function to test GCM/CCM.

tools/tools/crypto/cryptocheck.c

219

It is tempting to make these C++ vectors.

[cem]

LGTM.

tools/tools/crypto/cryptocheck.c

114

ETA doesn't require a hmac; why add 'h'?

1344–1349

This is probably going to make for a very spammy verbose mode.

[jhb]

tools/tools/crypto/cryptocheck.c

114

While it doesn't, it's only useful in this tool to use hmacs as a MAC (and that's what the current code does so it doesn't try to use GMAC or plain hashes with simple ciphers). I've thought about also adding a bool to tag which MACs and ciphers are ok to mix for our ETA mode to basically limit it to AES + HMAC. The chacha20 + poly1035 will not be ETA but a separate AEAD algorithm. I could leave this bit out of this change though.

1344–1349

Well, adding more things via -z makes it more spammy, mostly due to XTS requests failing due to the lack of CTS. Adding the AAD length doesn't add more lines here though, just more detail to these lines so you can tell which set of settings to run to reproduce a failure.

Cutting out chacah20 + <random HMAC> would reduce the overall spam from -v a bit. I've also thought about adding a -vv mode and hiding certain errors (like when OCF reports that an algorithm isn't supported) behind that to help reduce spam for driver developers when a driver doesn't support all the algorithms. The warn() about identical cipher text might be something we can just drop as well.