Page MenuHomeFreeBSD
Differential D18592 Diff 52132 sys/opencrypto/cryptodev.h

Changeset View

Standalone View

View Options

sys/opencrypto/cryptodev.h

Show First 20 Lines • Show All 80 Lines • ▼ Show 20 Lines
#define SHA2_224_HASH_LEN 28 #define SHA2_224_HASH_LEN 28
#define SHA2_256_HASH_LEN 32 #define SHA2_256_HASH_LEN 32
#define SHA2_384_HASH_LEN 48 #define SHA2_384_HASH_LEN 48
#define SHA2_512_HASH_LEN 64 #define SHA2_512_HASH_LEN 64
#define MD5_KPDK_HASH_LEN 16 #define MD5_KPDK_HASH_LEN 16
#define SHA1_KPDK_HASH_LEN 20 #define SHA1_KPDK_HASH_LEN 20
#define AES_GMAC_HASH_LEN 16 #define AES_GMAC_HASH_LEN 16
#define POLY1305_HASH_LEN 16 #define POLY1305_HASH_LEN 16
#define AES_CBC_MAC_HASH_LEN 16
cemUnsubmitted
Not Done
Inline Actions

It's not a hash, but neither is POLY1305 or GMAC, so, whatever :-).

cem: It's not a hash, but neither is POLY1305 or GMAC, so, whatever :-).
/* Maximum hash algorithm result length */ /* Maximum hash algorithm result length */
#define HASH_MAX_LEN SHA2_512_HASH_LEN /* Keep this updated */ #define HASH_MAX_LEN SHA2_512_HASH_LEN /* Keep this updated */
#define MD5_BLOCK_LEN 64 #define MD5_BLOCK_LEN 64
#define SHA1_BLOCK_LEN 64 #define SHA1_BLOCK_LEN 64
#define RIPEMD160_BLOCK_LEN 64 #define RIPEMD160_BLOCK_LEN 64
#define SHA2_224_BLOCK_LEN 64 #define SHA2_224_BLOCK_LEN 64
#define SHA2_256_BLOCK_LEN 64 #define SHA2_256_BLOCK_LEN 64
#define SHA2_384_BLOCK_LEN 128 #define SHA2_384_BLOCK_LEN 128
#define SHA2_512_BLOCK_LEN 128 #define SHA2_512_BLOCK_LEN 128
/* HMAC values */ /* HMAC values */
#define NULL_HMAC_BLOCK_LEN 64 #define NULL_HMAC_BLOCK_LEN 64
/* Maximum HMAC block length */ /* Maximum HMAC block length */
#define HMAC_MAX_BLOCK_LEN SHA2_512_BLOCK_LEN /* Keep this updated */ #define HMAC_MAX_BLOCK_LEN SHA2_512_BLOCK_LEN /* Keep this updated */
#define HMAC_IPAD_VAL 0x36 #define HMAC_IPAD_VAL 0x36
#define HMAC_OPAD_VAL 0x5C #define HMAC_OPAD_VAL 0x5C
/* HMAC Key Length */ /* HMAC Key Length */
#define AES_128_GMAC_KEY_LEN 16 #define AES_128_GMAC_KEY_LEN 16
#define AES_192_GMAC_KEY_LEN 24 #define AES_192_GMAC_KEY_LEN 24
#define AES_256_GMAC_KEY_LEN 32 #define AES_256_GMAC_KEY_LEN 32
#define AES_128_CBC_MAC_KEY_LEN 16
#define AES_192_CBC_MAC_KEY_LEN 24
#define AES_256_CBC_MAC_KEY_LEN 32
#define POLY1305_KEY_LEN 32 #define POLY1305_KEY_LEN 32
/* Encryption algorithm block sizes */ /* Encryption algorithm block sizes */
#define NULL_BLOCK_LEN 4 /* IPsec to maintain alignment */ #define NULL_BLOCK_LEN 4 /* IPsec to maintain alignment */
#define DES_BLOCK_LEN 8 #define DES_BLOCK_LEN 8
#define DES3_BLOCK_LEN 8 #define DES3_BLOCK_LEN 8
#define BLOWFISH_BLOCK_LEN 8 #define BLOWFISH_BLOCK_LEN 8
▲ Show 20 Lines • Show All 76 Lines • ▼ Show 20 Lines
#define CRYPTO_CHACHA20 31 /* Chacha20 stream cipher */ #define CRYPTO_CHACHA20 31 /* Chacha20 stream cipher */
#define CRYPTO_SHA2_224_HMAC 32 #define CRYPTO_SHA2_224_HMAC 32
#define CRYPTO_RIPEMD160 33 #define CRYPTO_RIPEMD160 33
#define CRYPTO_SHA2_224 34 #define CRYPTO_SHA2_224 34
#define CRYPTO_SHA2_256 35 #define CRYPTO_SHA2_256 35
#define CRYPTO_SHA2_384 36 #define CRYPTO_SHA2_384 36
#define CRYPTO_SHA2_512 37 #define CRYPTO_SHA2_512 37
#define CRYPTO_POLY1305 38 #define CRYPTO_POLY1305 38
#define CRYPTO_ALGORITHM_MAX 38 /* Keep updated - see below */ #define CRYPTO_AES_CCM_16 39 /* cipher side */
cemUnsubmitted
Not Done
Inline Actions

This is unrelated to this change

cem: This is unrelated to this change
sefAuthorUnsubmitted
Done
Inline Actions

I noted in the initial message for this change review that I didn't strip out the value for CRYPTO_AES_CCM_16, but could if really necessary.

sef: I noted in the initial message for this change review that I didn't strip out the value for…
cemUnsubmitted
Not Done
Inline Actions

It seems easy enough to remove here and add in the revision that adds CCM so I'd certainly prefer that.

cem: It seems easy enough to remove here and add in the revision that adds CCM so I'd certainly…
#define CRYPTO_AES_128_CCM_CBC_MAC 41 /* auth side */
#define CRYPTO_AES_192_CCM_CBC_MAC 42 /* auth side */
#define CRYPTO_AES_256_CCM_CBC_MAC 43 /* auth side */
cemUnsubmitted
Not Done
Inline Actions

Can this be reduced to a single cryptodev algorithm, as John requested in the earlier review? The key size is already encoded in the crd.

cem: Can this be reduced to a single cryptodev algorithm, as John requested in the earlier review?
sefAuthorUnsubmitted
Done
Inline Actions

I know I had a reason for doing it this way, but I'm blanking on it for now. I'll leave this incomplete until I either remember why, or change it.

sef: I know I had a reason for doing it this way, but I'm blanking on it for now. I'll leave this…
cemUnsubmitted
Not Done
Inline Actions

Thanks!

cem: Thanks!
sefAuthorUnsubmitted
Done
Inline Actions

Oh. I did it that way because of CRYPTO_AES_${SIZE}_NIST_GMAC.

sef: Oh. I did it that way because of CRYPTO_AES_${SIZE}_NIST_GMAC.
jhbUnsubmitted
Not Done
Inline Actions

Yes, that's the bug (there wasn't a good reason for GCM to do it). It would be really nice to not have it if we can avoid it.

jhb: Yes, that's the bug (there wasn't a good reason for GCM to do it). It would be really nice to…
sefAuthorUnsubmitted
Done
Inline Actions

It's also what CRYPTO_SHA2_${SIZE} does. So it's not just GCM. Are there any of the crypto or auth ones that do? (He asks while rewriting the code to see how annoying or not it is :).)

sef: It's also what CRYPTO_SHA2_${SIZE} does. So it's not just GCM. Are there any of the crypto or…
sefAuthorUnsubmitted
Done
Inline Actions

Well, any auth ones that do; the crypto ones have min and max keys, while the auth struct only has key size.

sef: Well, any auth ones that do; the crypto ones have min and max keys, while the auth struct only…
jhbUnsubmitted
Not Done
Inline Actions

But AEAD (GCM and CCM) are different. They don't actually have separate keys. You use the same key for both the cipher and the auth. I think it's a bug that the CRYPTO_AES_*_NIST_GMAC constants exist at all and plan to remove them in my OCF rework branch. There should only be the GCM (cipher with tag) and GMAC (hash) algorithms in my mind with the right axf pointer chosen based on the key size. Similarly for CCM and CBC-MAC. I know we can't yet quite get there today in the current OCF, but I think we could easily use a single constant for the auth side of CCM for now and have drivers and consumers just switch on the key size to choose the right axf pointer.

https://github.com/bsdjhb/freebsd/compare/master...ocf_rework shows the WIP

jhb: But AEAD (GCM and CCM) are different. They don't actually have separate keys. You use the…
sefAuthorUnsubmitted
Done
Inline Actions

I've got two responses to this, equally valid:

First, I can surely rip out all of the specific key size ones, and just have a generic one, because the code isn't plumbed up -- and won't be until the code that changes the OCF interfaces. But...

Second, that's telling me to write this code to an API that isn't currently in the system, while this is intended to go into the current system. And in the existing one, I have to have the different keysize variants as distinct entries, because the setup code will fail if the key sizes don't match.

I'm blocked on doing the other parts of this, since it was requested to be broken down into multiple smaller bits; that in turn is blocking the ZFS work we want to move forward with.

So which is it: do I write this for a future kernel change, or do I write this for the existing one?

sef: I've got two responses to this, equally valid: First, I can surely rip out all of the specific…
jhbUnsubmitted
Not Done
Inline Actions

I'm saying it's fine to have multiple struct auth_xform that differ per key-size. I would just have a single constant and have code that's using the constant do something like:

case CRYPTO_AES_CCM_CBC_MAX:
     switch (keysize) {
     case 16:
         axf = &auth_<mumble>_128;
         break;
     case 24:
         axf = &auth_<mumble>_192;
         break;
     case 32:
         axf = &auth_<mumble>_256;
         break;

Does that make sense? Even with the current API I feel like GCM could/should have used that approach IMO. I think it also makes life less complicated in consumers and drivers as you don't have to add a bunch of silly checks for things like "does the specific CCM MAC constant match the key length of the cipher key" because you are using the cipher key length directly with a single constant that doesn't on its own indicate a key size.

jhb: I'm saying it's fine to have multiple struct auth_xform that differ per key-size. I would just…
sefAuthorUnsubmitted
Done
Inline Actions

My recollection at having tried different things in the past is that if I use the single entry with auth, the existing setup code will look at the key size given in the crp, and compare it with the key size given in the structure, and error out if they're not the same. My recollection could be entirely wrong of course!

sef: My recollection at having tried different things in the past is that if I use the single entry…
sefAuthorUnsubmitted
Done
Inline Actions

Either my recollection was wrong, or the code change -- it looks for "thash->keysize != 0 && sop->mackeylen > thash->keysize" which means it should work. Coming up as soon as I have some reliable networking again!

sef: Either my recollection was wrong, or the code change -- it looks for "thash->keysize != 0 &&…
#define CRYPTO_ALGORITHM_MAX 43 /* Keep updated - see below */
#define CRYPTO_ALGO_VALID(x) ((x) >= CRYPTO_ALGORITHM_MIN && \ #define CRYPTO_ALGO_VALID(x) ((x) >= CRYPTO_ALGORITHM_MIN && \
(x) <= CRYPTO_ALGORITHM_MAX) (x) <= CRYPTO_ALGORITHM_MAX)
/* Algorithm flags */ /* Algorithm flags */
#define CRYPTO_ALG_FLAG_SUPPORTED 0x01 /* Algorithm is supported */ #define CRYPTO_ALG_FLAG_SUPPORTED 0x01 /* Algorithm is supported */
#define CRYPTO_ALG_FLAG_RNG_ENABLE 0x02 /* Has HW RNG for DH/DSA */ #define CRYPTO_ALG_FLAG_RNG_ENABLE 0x02 /* Has HW RNG for DH/DSA */
#define CRYPTO_ALG_FLAG_DSA_SHA 0x04 /* Can do SHA on msg */ #define CRYPTO_ALG_FLAG_DSA_SHA 0x04 /* Can do SHA on msg */
▲ Show 20 Lines • Show All 155 Lines • ▼ Show 20 Linesstruct cryptostats {
struct cryptotstat cs_invoke; /* crypto_dipsatch -> crypto_invoke */ struct cryptotstat cs_invoke; /* crypto_dipsatch -> crypto_invoke */
struct cryptotstat cs_done; /* crypto_invoke -> crypto_done */ struct cryptotstat cs_done; /* crypto_invoke -> crypto_done */
struct cryptotstat cs_cb; /* crypto_done -> callback */ struct cryptotstat cs_cb; /* crypto_done -> callback */
struct cryptotstat cs_finis; /* callback -> callback return */ struct cryptotstat cs_finis; /* callback -> callback return */
}; };
#ifdef _KERNEL #ifdef _KERNEL
#if 0 #ifdef CRYPTO_DEBUG
cemUnsubmitted
Not Done
Inline Actions

This seems like an unrelated change

cem: This seems like an unrelated change
#define CRYPTDEB(s, ...) do { \ #define CRYPTDEB(s, ...) do { \
printf("%s:%d: " s "\n", __FILE__, __LINE__, ## __VA_ARGS__); \ printf("%s:%d: " s "\n", __FILE__, __LINE__, ## __VA_ARGS__); \
} while (0) } while (0)
#else #else
#define CRYPTDEB(...) do { } while (0) #define CRYPTDEB(...) do { } while (0)
#endif #endif
/* Standard initialization structure beginning */ /* Standard initialization structure beginning */
▲ Show 20 Lines • Show All 188 Lines • Show Last 20 Lines