Re: How to use AES_wrap_key() in openssl
On Mon, Mar 26, 2012 at 1:49 AM, Prashanth kumar N prashanth.kuma...@gmail.com wrote: [SNIP] : 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. No, you should not do this. The Handbook of Applied Cryptography specifically warns against the meaningful decrypted text syndrome. From page 364: A common misconception is that encryption provides data origin authentication and data integrity, under the argument that if a message is decrypted with a key shared only with party A, and the message is meaningful, then it must have originated from A. Even if you could recover the IV instead of supplying it, as this wrap algorithm *could* do (unlike normal CBC etc.), it doesn't prove the unwrapped=decrypted key is correct. CBC modes are often vulnerable to blockwise attacks (although I haven't worked out this one specifically). In general most encryption schemes don't attempt to provide integrity protection and shouldn't be relied on for that; If your scheme is not authenticating its data, then your scheme is probably broken. In memory keys might have a different threat model so that the attacker never gets access to a program's memory. But then it begs the question: why wrap at all? Padding Oracles and the Beast Attack are possible because the encryption system is broken. They were not using Authenticated Encryption properly. I'd encourage folks who are combining primitives (AES, HMACs, or using 'padding' as an authenticagtion tag) to review Hugo Krawczyk 2001 paper, The Order of Encryption and Authentication for Protecting Communications. From the Krawczyk paper, we learned SSH was broken, and SSL could be broken under the right circumstances. The only protocol which was provably correct was IPSec. The folks who are using padding as an authentication tag remind me of these comments (they are actully doing a bit worse than described): ...people had been doing rather poorly when they tried to glue together a traditional (privacy-only) encryption scheme and a message authentication code (MAC) - Bellare, Rogaway, and Wagner in A Conventional Authenticated-Encryption Mode and ...it is very easy to accidentally combine secure encryption schemes with secure MACs and still get insecure authenticated encryption schemes - Kohno, Viega, Whiting in The CWC Authenticated Encryption (Associated Data) Mode. Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: How to use AES_wrap_key() in openssl
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 Listopenssl-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
Re: How to use AES_wrap_key() in openssl
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
On Fri, Mar 23, 2012 at 9:24 AM, Dave Thompson dthomp...@prinpay.comwrote:
From: owner-openssl-us...@openssl.org On Behalf Of pkumarn
Sent: Wednesday, 21 March, 2012 02:02
One more thanks from side for replying to this query.,.. my comments
inline...
Aside: Usenet convention is response lines, including 'inline'
ones, have no prefix, and (all) quoted lines do, usually
(as I have) a greater-than sign. That is unambiguous and
easier to see at a glance than your embedded marks.
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...
Yes, there is no way to extract the IV from AES_unwrap_key,
and it will return 0 if you don't give the correct IV.
As with other IV-based modes, the decryptor MUST provide
the same IV the encryptor used. In most uses the encryptor
chooses the IV randomly, and therefore the IV must be
transmitted or stored along with the ciphertext. But for
key wrapping like this, assuming your data keys are random
as they should be, you don't really need nonce IVs, and
you could have both wrap and unwrap use the default in
those routines (8 x A6) or some other fixed value.
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.
Even if you could recover the IV instead of supplying it,
as this wrap algorithm *could* do (unlike normal CBC etc.),
it doesn't prove the unwrapped=decrypted key is correct.
CBC modes are often vulnerable to blockwise attacks
(although I haven't worked out this one specifically).
In general most encryption schemes don't attempt to provide
integrity protection and shouldn't be relied on for that;
even the common practice of checking PKCS#5 padding (for
varying data in a block mode) is weak and many cryptosystems
that relied on 'if it decrypts sensibly it must be correct'
have been broken precisely that way. This is even more true
where the encrypted data is a key which is just bits.
If you want a check on the key unwrap (and usually people
do, because of the impact if it is wrong), do a check.
One common technique is for the wrapper to (separately)
use the original key to encrypt a known block, such as
all 0 or KEY CHECK VALUE, and transmit/store that value
along with the wrapped key, or a portion of it like the
first 4 bytes or so. The unwrapper uses the recovered key
to do the same encryption and compares. More generic
methods are to add an MDC (a hash) to the original key
before wrapping, or a MAC (such as a keyed hash) after;
but for the latter you now need to share (and manage)
the MAC key as well as the wrap=encryption key.
In the last few years special modes have been developed which
do provide both encryption and integrity (or authentication).
TLSv1.2 defines some ciphersuites using Galois Counter Mode
(GCM) which are apparently implemented in brand-new 1.0.1.
#define KEY_LEN 32
u8 dek[KEY_LEN + 8];
static const
RE: How to use AES_wrap_key() in openssl
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 Listopenssl-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 Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
RE: How to use AES_wrap_key() in openssl
From: owner-openssl-us...@openssl.org On Behalf Of pkumarn
Sent: Wednesday, 21 March, 2012 02:02
One more thanks from side for replying to this query.,.. my comments
inline...
Aside: Usenet convention is response lines, including 'inline'
ones, have no prefix, and (all) quoted lines do, usually
(as I have) a greater-than sign. That is unambiguous and
easier to see at a glance than your embedded marks.
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...
Yes, there is no way to extract the IV from AES_unwrap_key,
and it will return 0 if you don't give the correct IV.
As with other IV-based modes, the decryptor MUST provide
the same IV the encryptor used. In most uses the encryptor
chooses the IV randomly, and therefore the IV must be
transmitted or stored along with the ciphertext. But for
key wrapping like this, assuming your data keys are random
as they should be, you don't really need nonce IVs, and
you could have both wrap and unwrap use the default in
those routines (8 x A6) or some other fixed value.
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.
Even if you could recover the IV instead of supplying it,
as this wrap algorithm *could* do (unlike normal CBC etc.),
it doesn't prove the unwrapped=decrypted key is correct.
CBC modes are often vulnerable to blockwise attacks
(although I haven't worked out this one specifically).
In general most encryption schemes don't attempt to provide
integrity protection and shouldn't be relied on for that;
even the common practice of checking PKCS#5 padding (for
varying data in a block mode) is weak and many cryptosystems
that relied on 'if it decrypts sensibly it must be correct'
have been broken precisely that way. This is even more true
where the encrypted data is a key which is just bits.
If you want a check on the key unwrap (and usually people
do, because of the impact if it is wrong), do a check.
One common technique is for the wrapper to (separately)
use the original key to encrypt a known block, such as
all 0 or KEY CHECK VALUE, and transmit/store that value
along with the wrapped key, or a portion of it like the
first 4 bytes or so. The unwrapper uses the recovered key
to do the same encryption and compares. More generic
methods are to add an MDC (a hash) to the original key
before wrapping, or a MAC (such as a keyed hash) after;
but for the latter you now need to share (and manage)
the MAC key as well as the wrap=encryption key.
In the last few years special modes have been developed which
do provide both encryption and integrity (or authentication).
TLSv1.2 defines some ciphersuites using Galois Counter Mode
(GCM) which are apparently implemented in brand-new 1.0.1.
#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
RE: How to use AES_wrap_key() in openssl
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 Listopenssl-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-tp33531413p33543618.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
RE: How to use AES_wrap_key() in openssl
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.
#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).
/* 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).
(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 Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
How to use AES_wrap_key() in openssl
Hi,
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
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?
Also is their anyway i can extract the IV when i do the reverse of above
logic using AES_unwrap_key()?
#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];
/* 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
printf(\n);
--
View this message in context:
http://old.nabble.com/How-to-use-AES_wrap_key%28%29-in-openssl-tp33531413p33531413.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
