Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Trouble running NIST SP800-38F test vectors #9

Open
bunnie opened this issue Jul 24, 2022 · 0 comments
Open

Trouble running NIST SP800-38F test vectors #9

bunnie opened this issue Jul 24, 2022 · 0 comments

Comments

@bunnie
Copy link

bunnie commented Jul 24, 2022

I'm trying to run some NIST SP800-38F test vectors against this crate, but it's failing. Can you please tell me what I'm doing wrong?

The vectors come from: https://csrc.nist.gov/CSRC/media/Projects/Cryptographic-Algorithm-Validation-Program/documents/mac/kwtestvectors.zip

For example, if I try this vector:

[PLAINTEXT LENGTH = 248]

COUNT = 0
K = e9bb7f44c7baafbf392ab912589a2f8db53268106eafb74689bb1833136e6113
P = ffe952604834bff899e63658f34246815c91597eb40a21729e0a8a959b61f2
C = 15b9f06fbc765e5e3d55d6b824616f21921d2a6918ee7bf1406b524274e170b4a78333ca5ee92af5

Against the implementation in aes_kw, and also in Python versus the cryptography.hazmat.primitives.keywrap import aes_key_wrap_with_padding implementation, I get a ciphertext that matches the test vector.

However, when I run this code:

    let key_vec = hex::decode("e9bb7f44c7baafbf392ab912589a2f8db53268106eafb74689bb1833136e6113").unwrap();
    let kwp = Aes256KeyWrap::new(&key_vec.try_into().unwrap());

    let p_vec = hex::decode("ffe952604834bff899e63658f34246815c91597eb40a21729e0a8a959b61f2").unwrap();
    let enc = kwp.encapsulate(&p_vec).unwrap();
    assert_eq!(enc, hex::decode("15b9f06fbc765e5e3d55d6b824616f21921d2a6918ee7bf1406b524274e170b4a78333ca5ee92af5").unwrap());

It doesn't work: the result is f80268cb6552342449a0e088b9846c061c6622249558ce1fddaf777783d8a480094857707e7d09d2 instead.

What am I doing wrong? thank you!

bunnie added a commit to betrusted-io/xous-core that referenced this issue Jul 24, 2022
The crate we originally grabbed for AES-KWP seems to be non-compliant
(or I'm an idiot and I can't figure out how to call it in a way
that is compliant).

See jedisct1/rust-aes-keywrap#9

Turns out that `aes_kw` *is* compliant, but unfortunately, it didn't
exist back when the PDDB was being written. The PDDB started in October
2021, and `aes_kw` was pushed in Jan 2022. *just* barely missed it.

Anyways, caught this error while trying to implement some CI for
backups. Hurray for testing!

This patch removes the encryption path using the incorrect version
of the algorithm, but leaves the decryption path in place. The
system will try to decrypt initially with the correct version,
but if that fails, it will fall back and try the incorrect version.
If that succeeds, it returns an error code with the correct key and
an updated wrapped key, which the caller can store so that future
calls do not fail. Thus, we have a seamless migration from the
incorrect version to the correct version.

Have verified that the aes_kw version *does* work with the CI
script, insofar as it has been written (we just got to that point
and got stuck). So, full speed ahead. Users shouldn't notice this
change.

Also, fwiw, I did take a look at the "incorrect" implementation,
and it doesn't look obviously insecure. Printing out the various
rounds of the wrapping function looks like the first couple rounds
match, but it diverges somewhere probably due to an off-by-one
in a counter or something like that. I didn't chase it out -- just
wanted to make sure that nothing looked like a huge data compromise.

Good news is this comes right on the heels of v0.9.9 release, so
this will be pushed as a hotfix right away.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant