Let me go to my white board and see what best i can choose. Issue is we don't
want to sore any keys as it is, so is the reason to choose key wrapping.
pkumarn wrote:
>
> One more thanks from side for replying to this query.,.. my comments
> inline...
>
>
> So are you saying that their is no way to extract IV and check back if the
> decrypted key matches the encrypted key? I feel this would give space for
> more vulnerabilities as one needs to make sure before using the decryted
> key it is the right key. Or is it like AES_unwrap() will fail on
> decryption? Not clear on this part...
>
>
> Dave Thompson-5 wrote:
>>
>>> From: owner-openssl-us...@openssl.org On Behalf Of pkumarn
>>> Sent: Monday, 19 March, 2012 09:17
>>
>>> I have a requirement of wrapping a 512-bit DEK witk 256 bit
>>> KEK. I picked up
>>> openssl API and figured out that it provides AES_wrap_key()
>>> to do the job. I
>>
>> OpenSSL's AES_{wrap,unwrap}_key does *a* key wrapping,
>> but not the only possible one. You need to make sure the
>> unwrap matches it (easy if you do the unwrap yourself).
>>
>>> wrote a small program (snippet below) to get the job done but
>>> when i check
>>> out the values in "dek", i see all values as zero. Not sure what i am
>>> missing?
>>>
>> See below.
>>
>>> Also is their anyway i can extract the "IV" when i do the
>>> reverse of above
>>> logic using AES_unwrap_key()?
>>>
>> No, as with other chain modes you must transmit the IV used
>> at encrypt to decrypt -- unless you always make it the same
>> which should be okay here, since the wrappee (data) keys
>> should be unique so duplicate IV (+key) doesn't risk
>> identifying repeats as it would for more generic data.
>> Although internally it is used differently; instead of
>> chaining forward in both encrypt and decrypt, this decrypt
>> (unwrap) chains backward and then verifies the IV;
>> if it extracted the IV instead it would probably be
>> vulnerable to some tampering attacks.
>>
>> <<>> : In my case, i would be storing the wrapped key and not the
>> original key. So when user tries to decrypt the wrapped key, he would get
>> the original key but how do i make sure that is the right key. So the
>> suggestion is to see if i can get the same IV i have used to encrypt
>> which indirectly proves that the key decrypted is the right one.
>>
>>> #define KEY_LEN 32
>>> u8 dek[KEY_LEN + 8];
>>> static const unsigned char default_iv[] = {
>>> 0xA6, 0xA6, 0xA6, 0xA6, 0xA6, 0xA6, 0xA6, 0xA6,
>>> };
>>>
>>> for(n = 0; n < KEY_LEN; n++)
>>> actx.rd_key[n] = kek[n];
>>>
>> I assume actx is an AES_KEY (struct aes_key_st) since you
>> pass it to AES_wrap_key below. This is NOT how you initialize
>> an AES_KEY structure; in fact, in general you should never
>> directly write elements in any OpenSSL-defined structure,
>> and usually you should avoid reading them where OpenSSL
>> provides getters (although it doesn't do that everywhere).
>> Use AES_set_encrypt_key (and _decrypt_ for unwrap).
>>
>> <<>>: Yes "actx" is of type struct aes_key_st. I did come across
>> AES_set_encrypt_key() which did set the data structure of actx but i
>> thought i can also do it directly. Would it give unexpected result, if i
>> set them directly?
>>
>>> /* Here KEK is got as a function parameter
>>> Byte contains DEK key
>>> I am able to successfully print KEK and DEK values and they
>>> are as expected
>>> */
>>>
>>> ret = AES_wrap_key(&actx, default_iv, dek, byte, KEY_LEN - 1);
>>> for(n = 0; n < (KEY_LEN + 8); n++)
>>> printf(" %02x", dek[n]); // this prints all zeros
>>>
>> Check ret before printing or otherwise using dek[]. It can
>> and here did indicate an error, and the output buffer isn't set.
>> Although on checking I see these routines don't fill in
>> the error queue like most (other) OpenSSL routines.
>>
>> KEY_LEN-1 is 31 bytes. You can't wrap a 31-byte value;
>> as I said before it must be a multiple of 8 bytes.
>> You say your requirement is 512 bits; that's 64 bytes
>> (not 32 as your code #define's and allocates).
>> <<>>: My typo in this...as the above code is just a snippet, i have
>> missed few things here...
>>
>> (And as before a 512-bit key if used for a symmetric
>> algorithm usually indicates uninformed design, but
>> I assume that's not your responsibility.)
>>
>>
>> ______________________________________________________________________
>> OpenSSL Project http://www.openssl.org
>> User Support Mailing List openssl-users@openssl.org
>> Automated List Manager majord...@openssl.org
>>
>>
>
>
--
View this message in context:
http://old.nabble.com/How-to-use-AES_wrap_key%28%29-in-openssl-tp33531413p33544645.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
