Am Dienstag, 19. Mai 2020, 21:02:09 CEST schrieb Ard Biesheuvel: Hi Ard, > Stephan reports that the arm64 implementation of cts(cbc(aes)) deviates > from the generic implementation in what it returns as the output IV. So > fix this, and add some test vectors to catch other non-compliant > implementations. > > Stephan, could you provide a reference for the NIST validation tool and > how it flags this behaviour as non-compliant? Thanks. The test definition that identified the inconsistent behavior is specified with [1]. Note, this testing is intended to become an RFC standard. To facilitate that testing, NIST offers an internet service, the ACVP server, that allows obtaining test vectors and uploading responses. You see the large number of concluded testing with [2]. A particular completion of the CTS testing I finished yesterday is given in [3]. That particular testing was also performed on an ARM system with CE where the issue was detected. I am performing the testing with [4] that has an extension to test the kernel crypto API. [1] https://github.com/usnistgov/ACVP/blob/master/artifacts/draft-celi-acvp-block-ciph-00.txt#L366 [2] https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/ validation-search?searchMode=validation&family=1&productType=-1&ipp=25 [3] https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/ details?validation=32608 [4] https://github.com/smuellerDD/acvpparser > > Cc: Stephan Mueller <smueller@xxxxxxxxxx> > > Ard Biesheuvel (2): > crypto: arm64/aes - align output IV with generic CBC-CTS driver > crypto: testmgr - add output IVs for AES-CBC with ciphertext stealing > > arch/arm64/crypto/aes-modes.S | 2 ++ > crypto/testmgr.h | 12 ++++++++++++ > 2 files changed, 14 insertions(+) Ciao Stephan
