2017-08-22 01:08:08 -07:00
|
|
|
#ifndef _CRYPTO_GCM_H
|
|
|
|
#define _CRYPTO_GCM_H
|
|
|
|
|
2019-07-31 06:05:54 -07:00
|
|
|
#include <linux/errno.h>
|
|
|
|
|
crypto: lib/aesgcm - Provide minimal library implementation
Implement a minimal library version of AES-GCM based on the existing
library implementations of AES and multiplication in GF(2^128). Using
these primitives, GCM can be implemented in a straight-forward manner.
GCM has a couple of sharp edges, i.e., the amount of input data
processed with the same initialization vector (IV) should be capped to
protect the counter from 32-bit rollover (or carry), and the size of the
authentication tag should be fixed for a given key. [0]
The former concern is addressed trivially, given that the function call
API uses 32-bit signed types for the input lengths. It is still up to
the caller to avoid IV reuse in general, but this is not something we
can police at the implementation level.
As for the latter concern, let's make the authentication tag size part
of the key schedule, and only permit it to be configured as part of the
key expansion routine.
Note that table based AES implementations are susceptible to known
plaintext timing attacks on the encryption key. The AES library already
attempts to mitigate this to some extent, but given that the counter
mode encryption used by GCM operates exclusively on known plaintext by
construction (the IV and therefore the initial counter value are known
to an attacker), let's take some extra care to mitigate this, by calling
the AES library with interrupts disabled.
[0] https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-38d.pdf
Link: https://lore.kernel.org/all/c6fb9b25-a4b6-2e4a-2dd1-63adda055a49@amd.com/
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Nikunj A Dadhania <nikunj@amd.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2022-11-03 12:22:59 -07:00
|
|
|
#include <crypto/aes.h>
|
|
|
|
#include <crypto/gf128mul.h>
|
|
|
|
|
2017-08-22 01:08:08 -07:00
|
|
|
#define GCM_AES_IV_SIZE 12
|
|
|
|
#define GCM_RFC4106_IV_SIZE 8
|
|
|
|
#define GCM_RFC4543_IV_SIZE 8
|
|
|
|
|
2019-07-31 06:05:54 -07:00
|
|
|
/*
|
|
|
|
* validate authentication tag for GCM
|
|
|
|
*/
|
|
|
|
static inline int crypto_gcm_check_authsize(unsigned int authsize)
|
|
|
|
{
|
|
|
|
switch (authsize) {
|
|
|
|
case 4:
|
|
|
|
case 8:
|
|
|
|
case 12:
|
|
|
|
case 13:
|
|
|
|
case 14:
|
|
|
|
case 15:
|
|
|
|
case 16:
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* validate authentication tag for RFC4106
|
|
|
|
*/
|
|
|
|
static inline int crypto_rfc4106_check_authsize(unsigned int authsize)
|
|
|
|
{
|
|
|
|
switch (authsize) {
|
|
|
|
case 8:
|
|
|
|
case 12:
|
|
|
|
case 16:
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* validate assoclen for RFC4106/RFC4543
|
|
|
|
*/
|
|
|
|
static inline int crypto_ipsec_check_assoclen(unsigned int assoclen)
|
|
|
|
{
|
|
|
|
switch (assoclen) {
|
|
|
|
case 16:
|
|
|
|
case 20:
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
crypto: lib/aesgcm - Provide minimal library implementation
Implement a minimal library version of AES-GCM based on the existing
library implementations of AES and multiplication in GF(2^128). Using
these primitives, GCM can be implemented in a straight-forward manner.
GCM has a couple of sharp edges, i.e., the amount of input data
processed with the same initialization vector (IV) should be capped to
protect the counter from 32-bit rollover (or carry), and the size of the
authentication tag should be fixed for a given key. [0]
The former concern is addressed trivially, given that the function call
API uses 32-bit signed types for the input lengths. It is still up to
the caller to avoid IV reuse in general, but this is not something we
can police at the implementation level.
As for the latter concern, let's make the authentication tag size part
of the key schedule, and only permit it to be configured as part of the
key expansion routine.
Note that table based AES implementations are susceptible to known
plaintext timing attacks on the encryption key. The AES library already
attempts to mitigate this to some extent, but given that the counter
mode encryption used by GCM operates exclusively on known plaintext by
construction (the IV and therefore the initial counter value are known
to an attacker), let's take some extra care to mitigate this, by calling
the AES library with interrupts disabled.
[0] https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-38d.pdf
Link: https://lore.kernel.org/all/c6fb9b25-a4b6-2e4a-2dd1-63adda055a49@amd.com/
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Nikunj A Dadhania <nikunj@amd.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2022-11-03 12:22:59 -07:00
|
|
|
|
|
|
|
struct aesgcm_ctx {
|
|
|
|
be128 ghash_key;
|
|
|
|
struct crypto_aes_ctx aes_ctx;
|
|
|
|
unsigned int authsize;
|
|
|
|
};
|
|
|
|
|
|
|
|
int aesgcm_expandkey(struct aesgcm_ctx *ctx, const u8 *key,
|
|
|
|
unsigned int keysize, unsigned int authsize);
|
|
|
|
|
|
|
|
void aesgcm_encrypt(const struct aesgcm_ctx *ctx, u8 *dst, const u8 *src,
|
|
|
|
int crypt_len, const u8 *assoc, int assoc_len,
|
|
|
|
const u8 iv[GCM_AES_IV_SIZE], u8 *authtag);
|
|
|
|
|
|
|
|
bool __must_check aesgcm_decrypt(const struct aesgcm_ctx *ctx, u8 *dst,
|
|
|
|
const u8 *src, int crypt_len, const u8 *assoc,
|
|
|
|
int assoc_len, const u8 iv[GCM_AES_IV_SIZE],
|
|
|
|
const u8 *authtag);
|
|
|
|
|
2017-08-22 01:08:08 -07:00
|
|
|
#endif
|