You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[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.
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.
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:
Against the implementation in
aes_kw
, and also in Python versus thecryptography.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:
It doesn't work: the result is
f80268cb6552342449a0e088b9846c061c6622249558ce1fddaf777783d8a480094857707e7d09d2
instead.What am I doing wrong? thank you!
The text was updated successfully, but these errors were encountered: