Add AES Key Wrapping and Key Wrapping with Padding support

[groumage]

Hi, this PR add AES Key Wrapping (AES-KW) and AES Key Wrapping with Padding (AES-KWP) feature for crypto-condor. I implemented key wrapping algorithms on the C library of AES to follow the existing structure. I followed SP 800-38F (https://csrc.nist.gov/pubs/sp/800/38/f/final) and RFC 3394 (https://datatracker.ietf.org/doc/html/rfc3394) to create the implementation.

The test vectors I added to crypto-condor come from both NIST test vector (https://csrc.nist.gov/Projects/cryptographic-algorithm-validation-program/cavp-testing-block-cipher-modes) and wycheproof test vectors for AES-KWP (https://github.com/C2SP/wycheproof/blob/main/testvectors_v1/aes_kwp_test.json).

make all is working and returns no errors or warnings.

[JulioLoayzaM]

Hi @groumage, thank you for the PR!

I'll do a proper review later this week but from a quick glance it looks good. :)

I do have some remarks in the meantime:

• The Wycheproof file aes_kwp_test.json is missing.
• I see that RFC 3394 has some test vectors (from Section 4), do you know if either CAVP or Wycheproof have the same ones?
• From the test harness I see that OpenSSL uses the same encrypt/decrypt API but the RFC and both pycryptodome and pyca/cryptography use a different nomenclature (wrap/unwrap or seal/unseal). I'm not very familiar with KWP but I'd be tempted to follow suit and use wrap/unwrap, potentially with a new AES Protocol to really differentiate this mode. Do you have an opinion on this?

[groumage]

Hi @JulioLoayzaM,

• I added a commit with aes_kwp_test.json which was missing.
• CAVP or Wycheproof do not have the test vectors presented in RFC 3394. In fact, test vectors of RFC 3394 are useful to test internal functioning of AES KW:
  • Test vectors of CAVP and Wycheproof only provide plaintext/ciphertext, KEK and corresponding ciphertext/plaintext.
  • Test vectors of RFC 3394 also provide "intermediate cipher blocks" that are computed at step 2 of index-based algorithm AES KW at section 2.2.1 of RFC 3394. As there are already CAVP and Wycheproof, I don't think it is needed to considered test vectors of RFC 3394 as crypto-condor aims to be a conformity check tool.

For the last point, I think wrap/unwrap and seal/unseal nomenclature are here to emphasize that besides encrypt/decrypt, AES KW and KWP primitives manage the 8-byte block for integrity which is prepend to the key (= plaintext). When encrypt, this block is prepended and when decrypt, the value of this block is verified (in my PR, all of this are done in the AES C code).

Maybe creating a new AES protocol would be too much as, even if there is this 8-byte block management, the high-level protocol is "encrypt a plaintext with a key", there is no additional elements. That being said, it is relevant to follow pycryptodome and pyca/cryptography nomenclature. My suggestion is to keep all the same AES protocols but replace

# ECB / KW / KW_INV / KWP / KWP_INV
@overload
def _encrypt(mode: Literal[Mode.ECB, Mode.KW, Mode.KW_INV, Mode.KWP, Mode.KWP_INV],
             key: bytes,
             plaintext: bytes) -> bytes: ...

with something like

# ECB
@overload
def _encrypt(mode: Literal[Mode.ECB],
             key: bytes,
             plaintext: bytes) -> bytes: ...

# KW / KW_INV / KWP / KWP_INV
@overload
def _seal(mode: LiteralMode.KW, Mode.KW_INV, Mode.KWP, Mode.KWP_INV],
             key: bytes,
             plaintext: bytes) -> bytes: ...

to emphasize that with _seal, an 8-byte blocks is prepended (same with _decrypt and _unseal). Anyway, I stay open for any further discussions :)

[groumage]

Hi @JulioLoayzaM,

I hope you doing well. Do you have any more insight about my PR? I stay available for further discussions if needed.