Hi Dave,
I was going through the RFC of AES and it does say we get the IV upon
unwrapping . Check the below link
http://www.ietf.org/rfc/rfc3394.txt
-Prashanth
pkumarn wrote:
>
> 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-tp33531413p33544715.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
