summaryrefslogtreecommitdiffstats
path: root/crypto/keywrap.c
Commit message (Collapse)AuthorAgeFilesLines
* crypto: keywrap - memzero the correct memoryDan Carpenter2016-02-011-2/+2
| | | | | | | | | | | We're clearing the wrong memory. The memory corruption is likely harmless because we weren't going to use that stack memory again but not zeroing is a potential information leak. Fixes: e28facde3c39 ('crypto: keywrap - add key wrapping block chaining mode') Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: keywrap - add key wrapping block chaining modeStephan Mueller2015-10-151-0/+419
This patch implements the AES key wrapping as specified in NIST SP800-38F and RFC3394. The implementation covers key wrapping without padding. IV handling: The caller does not provide an IV for encryption, but must obtain the IV after encryption which would serve as the first semblock in the ciphertext structure defined by SP800-38F. Conversely, for decryption, the caller must provide the first semiblock of the data as the IV and the following blocks as ciphertext. The key wrapping is an authenticated decryption operation. The caller will receive EBADMSG during decryption if the authentication failed. Albeit the standards define the key wrapping for AES only, the template can be used with any other block cipher that has a block size of 16 bytes. During initialization of the template, that condition is checked. Any cipher not having a block size of 16 bytes will cause the initialization to fail. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
OpenPOWER on IntegriCloud