Re: target parameter to PK11_Derive
On 05/07/2015 11:49 AM, Andrew Cagney wrote: [inline] On 5 May 2015 at 13:18, Robert Relyea rrel...@redhat.com wrote: The target Mechanism is the operation you are going to use the target key for, It shouldn't match the mechanism used to derive the key. It is basically used to set the appropriate key type and flags on the resultant key. Example psuedo code: key1 = derive(keybase, mech=CKM_XOR_BASE_AND_DATA, target=CKM_SHA1_KEY_DERIVATION, data); key2 = derive(key1, mech=CKM_SHA1_KEY_DERIVATION, target=CKM_AES_CBC, NULL); decrypt(key2, mech=CKM_AES_CBC, input, output); Ideally you should try to keep it consistent with how your are planning on using the key, but in practice as long as the key is basically the same kind of key, the extact value of target is not necessary (You can use a key generated with target CKM_AES_CBC on an CKM_AES_ECB operation, for instance). Target may also be used to try to set the appropriate key length (if key length isn't supplied). Thanks for the clarification; my reading of the documentation wasn't too far off. For the intermediate values I think I'll try something like CKM_VENDOR_DEFINED; and, to your point, ensure all the final keys have meaningful values. I'm not sure CKM_VENDOR_DEFINED will be the right thing. The intermediate values are likely CKK_SECRET_KEYS with CKA_DERIVE set to true, It's probably best if you want to use the same value to use something like CKM_XOR_BASE_AND_DATA or something similiar. bob smime.p7s Description: S/MIME Cryptographic Signature -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: target parameter to PK11_Derive
[inline] On 5 May 2015 at 13:18, Robert Relyea rrel...@redhat.com wrote: The target Mechanism is the operation you are going to use the target key for, It shouldn't match the mechanism used to derive the key. It is basically used to set the appropriate key type and flags on the resultant key. Example psuedo code: key1 = derive(keybase, mech=CKM_XOR_BASE_AND_DATA, target=CKM_SHA1_KEY_DERIVATION, data); key2 = derive(key1, mech=CKM_SHA1_KEY_DERIVATION, target=CKM_AES_CBC, NULL); decrypt(key2, mech=CKM_AES_CBC, input, output); Ideally you should try to keep it consistent with how your are planning on using the key, but in practice as long as the key is basically the same kind of key, the extact value of target is not necessary (You can use a key generated with target CKM_AES_CBC on an CKM_AES_ECB operation, for instance). Target may also be used to try to set the appropriate key length (if key length isn't supplied). Thanks for the clarification; my reading of the documentation wasn't too far off. For the intermediate values I think I'll try something like CKM_VENDOR_DEFINED; and, to your point, ensure all the final keys have meaningful values. Andrew Most of these key derive operations either ignore keyType or take CKK_GENERIC_SECRET keys, so bad things aren't likely to happen if you mix up target a bit, but certainly the final resultant keys should target the proper crypto targets our your decrypt operation will fail with an inappropriate key type. bob Andrew PS: If there's documentation I've missed, please let me know :-) -- (1): It's computing the hash using calls like PK11_Derive (derive=CKM_SHA1_KEY_DERIVATION) rather than the lower level hash interface. This is because PK11_Derive returns a PK11SymKey, hopefully keeping the result secure. (2): Once the keying material has been created things become more sane, for instance when extracting (CKM_EXTRACT_KEY_FROM_KEY) an AES_GCM key the target is CKM_AES_GCM; and when extracting IV that ends up on the wire the target is CKM_VENDOR_DEFINED. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
target parameter to PK11_Derive
Hi, I'm cleaning up some code (it has a long history) that, among other things, computes IKE's PRF (hmac) and PRF+ (key derivation function). The computation involves the use of PK11_Derive to perform lots of concatenation, padding, xoring, and hashing(1). To get an idea, the prf+ (which uses PRF, which uses HASH) is defined in the RFC as: prf+ (K,S) = T1 | T2 | T3 | T4 | ... where: T1 = prf (K, S | 0x01) T2 = prf (K, T1 | S | 0x02) T3 = prf (K, T2 | S | 0x03) T4 = prf (K, T3 | S | 0x04) For specifics: PRF http://tools.ietf.org/html/rfc2104 PRF+ http://tools.ietf.org/html/rfc7296#page-48 The code works - at least in the sense that it computes the same values as the test vectors found on http://csrc.nist.gov/groups/STM/cavp/index.html The thing I'm not sure about is how the code is using PK11_Derive target parameter for its intermediate(2) operations. For instance, when doing concatenation and xoring, the derive parameter might have sane with values like: CKM_CONCATENATE_DATA_AND_BASE CKM_CONCATENATE_BASE_AND_DATA CKM_CONCATENATE_BASE_AND_KEY CKM_XOR_BASE_AND_DATA the *target* parameter might be: CKM_EXTRACT_KEY_FROM_KEY CKM_ SHA1_KEY_DERIVATION (when BASE_AND_KEY) CKM_CONCATENATE_BASE_AND_DATA Similarly, when performing the hash using PK11_Derive, the derive parameter is something sane like: CKM_SHA1_KEY_DERIVATION yet the *target* parameter is: CKM_CONCATENATE_BASE_AND_KEY Does any of this matter? Is there a preferred value? (If there is I could simplify some code further). And are there any, mumble mumble, security, mumble, mumble, implications? Andrew PS: If there's documentation I've missed, please let me know :-) -- (1): Its computing the hash using calls like PK11_Derive (derive=CKM_SHA1_KEY_DERIVATION) rather than the lower level hash interface. This is because PK11_Derive returns a PK11SymKey, hopefully keeping the result secure. (2): Once the keying material has been created things become more sane, for instance when extracting (CKM_EXTRACT_KEY_FROM_KEY) an AES_GCM key the target is CKM_AES_GCM; and when extracting IV that ends up on the wire the target is CKM_VENDOR_DEFINED. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
target parameter to PK11_Derive
Hi, I'm cleaning up some code (it has a long history) that, among other things, computes IKE's PRF (hmac) and PRF+ (key derivation function). The computation involves the use of PK11_Derive to perform lots of concatenation, padding, xoring, and hashing(1). To get an idea, the PRF+ function (which uses PRF, which uses HASH) is described in the RFC as: prf+ (K,S) = T1 | T2 | T3 | T4 | ... where: T1 = prf (K, S | 0x01) T2 = prf (K, T1 | S | 0x02) T3 = prf (K, T2 | S | 0x03) T4 = prf (K, T3 | S | 0x04) For specifics: PRF http://tools.ietf.org/html/rfc2104 PRF+ http://tools.ietf.org/html/rfc7296#page-48 The code works - at least in the sense that it computes the same values as the test vectors found on http://csrc.nist.gov/groups/STM/cavp/index.html The thing I'm not sure about is how the code is using PK11_Derive target parameter for its intermediate(2) operations. For instance, when doing concatenation and xoring, the derive parameter might have sane with values like: CKM_CONCATENATE_DATA_AND_BASE CKM_CONCATENATE_BASE_AND_DATA CKM_CONCATENATE_BASE_AND_KEY CKM_XOR_BASE_AND_DATA while the *target* parameter gets values like: CKM_EXTRACT_KEY_FROM_KEY CKM_ SHA1_KEY_DERIVATION (when BASE_AND_KEY) CKM_CONCATENATE_BASE_AND_DATA Similarly, when performing the hash using PK11_Derive, the derive parameter is something sane like: CKM_SHA1_KEY_DERIVATION yet the *target* parameter is: CKM_CONCATENATE_BASE_AND_KEY Does any of this matter? Is there a preferred value? (If there is I could simplify some code further). And are there any, mumble mumble, security, mumble, mumble, implications? Andrew PS: If there's documentation I've missed, please let me know :-) -- (1): It's computing the hash using calls like PK11_Derive (derive=CKM_SHA1_KEY_DERIVATION) rather than the lower level hash interface. This is because PK11_Derive returns a PK11SymKey, hopefully keeping the result secure. (2): Once the keying material has been created things become more sane, for instance when extracting (CKM_EXTRACT_KEY_FROM_KEY) an AES_GCM key the target is CKM_AES_GCM; and when extracting IV that ends up on the wire the target is CKM_VENDOR_DEFINED. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: target parameter to PK11_Derive
On 05/05/2015 08:42 AM, Andrew Cagney wrote: Hi, I'm cleaning up some code (it has a long history) that, among other things, computes IKE's PRF (hmac) and PRF+ (key derivation function). The computation involves the use of PK11_Derive to perform lots of concatenation, padding, xoring, and hashing(1). To get an idea, the PRF+ function (which uses PRF, which uses HASH) is described in the RFC as: prf+ (K,S) = T1 | T2 | T3 | T4 | ... where: T1 = prf (K, S | 0x01) T2 = prf (K, T1 | S | 0x02) T3 = prf (K, T2 | S | 0x03) T4 = prf (K, T3 | S | 0x04) For specifics: PRF http://tools.ietf.org/html/rfc2104 PRF+ http://tools.ietf.org/html/rfc7296#page-48 The code works - at least in the sense that it computes the same values as the test vectors found on http://csrc.nist.gov/groups/STM/cavp/index.html The thing I'm not sure about is how the code is using PK11_Derive target parameter for its intermediate(2) operations. For instance, when doing concatenation and xoring, the derive parameter might have sane with values like: CKM_CONCATENATE_DATA_AND_BASE CKM_CONCATENATE_BASE_AND_DATA CKM_CONCATENATE_BASE_AND_KEY CKM_XOR_BASE_AND_DATA while the *target* parameter gets values like: CKM_EXTRACT_KEY_FROM_KEY CKM_ SHA1_KEY_DERIVATION (when BASE_AND_KEY) CKM_CONCATENATE_BASE_AND_DATA Similarly, when performing the hash using PK11_Derive, the derive parameter is something sane like: CKM_SHA1_KEY_DERIVATION yet the *target* parameter is: CKM_CONCATENATE_BASE_AND_KEY Does any of this matter? Is there a preferred value? (If there is I could simplify some code further). And are there any, mumble mumble, security, mumble, mumble, implications? The target Mechanism is the operation you are going to use the target key for, It shouldn't match the mechanism used to derive the key. It is basically used to set the appropriate key type and flags on the resultant key. Example psuedo code: key1 = derive(keybase, mech=CKM_XOR_BASE_AND_DATA, target=CKM_SHA1_KEY_DERIVATION, data); key2 = derive(key1, mech=CKM_SHA1_KEY_DERIVATION, target=CKM_AES_CBC, NULL); decrypt(key2, mech=CKM_AES_CBC, input, output); Ideally you should try to keep it consistent with how your are planning on using the key, but in practice as long as the key is basically the same kind of key, the extact value of target is not necessary (You can use a key generated with target CKM_AES_CBC on an CKM_AES_ECB operation, for instance). Target may also be used to try to set the appropriate key length (if key length isn't supplied). Most of these key derive operations either ignore keyType or take CKK_GENERIC_SECRET keys, so bad things aren't likely to happen if you mix up target a bit, but certainly the final resultant keys should target the proper crypto targets our your decrypt operation will fail with an inappropriate key type. bob Andrew PS: If there's documentation I've missed, please let me know :-) -- (1): It's computing the hash using calls like PK11_Derive (derive=CKM_SHA1_KEY_DERIVATION) rather than the lower level hash interface. This is because PK11_Derive returns a PK11SymKey, hopefully keeping the result secure. (2): Once the keying material has been created things become more sane, for instance when extracting (CKM_EXTRACT_KEY_FROM_KEY) an AES_GCM key the target is CKM_AES_GCM; and when extracting IV that ends up on the wire the target is CKM_VENDOR_DEFINED. smime.p7s Description: S/MIME Cryptographic Signature -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
