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