RE: ACK message usage
Hello, thanks your answer, it was really detailed. Tamas On Mon, 2012-03-19 at 21:30 -0400, Dave Thompson wrote: > RE: ACK message usage __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: How to use PKCS5_PBKDF2_HMAC_SHA1()
Thanks a lot Dave for pointing out few things which i need to take care. By
the way as this is not complete code, original code already has taken care
of few things.
Now coming to the original question, how do i make sure
PKCS5_PBKDF2_HMAC_SHA1() is generating the correct result of my i/p data?
When i input RAND_bytes() data into PKCS5_PBKDF2_HMAC_SHA1(), i get a
different result but when the same is converted to ASCII (human readable
format), i get a different result. ...
Any thoughts on this?
Dave Thompson-5 wrote:
>
>> From: owner-openssl-us...@openssl.org On Behalf Of pkumarn
>> Sent: Monday, 19 March, 2012 03:06
>
>> I am trying to use PKCS5_PBKDF2_HMAC_SHA1() and below is my
>> sample program.
>> I wanted to make sure if my result of
>> PKCS5_PBKDF2_HMAC_SHA1() is correct so
>> i verified the same with the below wesbite
>> http://anandam.name/pbkdf2/ and i
>> see a different result... Am i using the API correctly?
>> I am having doubts if i am passing salt value correctly...
>>
> That site is Javascript which treats the salt (and password)
> directly as data. I don't know if or how browser(s) can
> reliably enter data other than printable ASCII in a ;
> it may very well depend on browser and locale settings.
> For simplicity if you want to interoperate with this PBKDF2
> implementation I would therefore limit both salt and password
> to printable ASCII 0x20-0x7E. (32 chars of salt, even restricted
> to 5 or 6 bits entropy each, is far more than needed, especially
> if you are deriving a 40-bit key as your code indicates.)
>
>> #include
>> #include
>> #include
>> #include
>> #include
>> #include
>> #include
>>
>> #include
>>
>> #include
>> #include
>> #include
>> #include
>>
> Asides: malloc.h is not standard or portable; standardly
> malloc() and related functions are in stdlib.h.
> types.h is not standard C (though sys/types.h is POSIX).
> Repeating string.h is clutter and may waste time.
> I would group openssl/rand.h with the other openssl/*.
>
>> #include
>> #define KEY_LEN32// 32 bytes - 256 bits
>> #define KEK_KEY_LEN 5
>> #define ITERATION 1000
>>
>> //unsigned char salt_value[32]={"5d85947b4292ea6463faf6893451232"};
>> unsigned char salt_value[KEY_LEN];
>> unsigned char AESkey[KEY_LEN];
>> unsigned char XTSkey[KEY_LEN];
>> u8 fuse_key[KEY_LEN];
>>
> Aside: using KEY_LEN as the length of the salt (which is not a key
> of any kind) is somewhat confusing; suggest SALT_LEN instead.
> KEK_KEY_LEN is redundant, like "CPU unit"; suggest KEK_LEN.
>>
>> void main()
>
> main returning void is not standard and never has been,
> and has no advantage whatsoever over the standard, int.
>
>> {
>>
>> s32 i=0;
>> s32 len =0;
>> u8 *out;
>> u8 *rspHMAC;
>> const s8 pwd[] = "test";
>> s8 rspPKCS5[KEK_KEY_LEN * 2];
>> s32 ret;
>>
> Note: these types are not standard or portable. C99
> (still not implemented everywhere, even though C11 has
> just come out) *may* have types of the form int8_t etc.
> However, below you treat pwd and rspPKCS5 below as arrays
> of 'plain' char. 'Plain' char is unsigned on some systems,
> so you would either have to make 's8' unsigned which is
> confusing and likely to lead to bugs, or leave s8 signed
> but convert all your accesses to be unsigned, which is
> a good deal of extra work and easy to get wrong.
>
>> rspHMAC = (unsigned char *) malloc(sizeof(char) * KEY_LEN);
>> out = (unsigned char *) malloc(sizeof(char) * KEK_KEY_LEN);
>>
> The return from malloc never needs to be cast in valid C; in C++
> it does but in C++ you generally shouldn't use malloc at all.
> For these small fixed sizes, dynamic allocation is a waste of
> effort and clutter. sizeof(char) is always 1 so it isn't needed,
> although if you consistently follow the pattern of N*sizeof(E)
> for all types it doesn't hurt to be consistent here.
>
>> RAND_bytes(salt_value, KEY_LEN);
>>
>>
>> printf("\n salt_value[0] = %x; salt_value[31]= %x", salt_value[0],
>> salt_value[31]);
>> printf("\n strlen(salt_value) = %d; sizeof(salt_value) = %d\n",
>> strlen(salt_value), sizeof(salt_value));
>> //printf("\n salt_value = %s", salt_value);
>>
> As I said before, RAND_bytes generates random bytes,
> which can include null and then strlen() is too low;
> while your buffer didn't include a null terminator (nor room
> for one) so in general strlen() could be too high -- although
> here salt_value is file-scope static and very likely to be
> followed in memory by the next file-scope static here AESkey
> which appears to be unused and thus still zero, although some
> implementations may follow salt_value by the next _referenced_
> external static and that may well contain nonnull bytes.
>
> If you want a constant length, use a constant for length.
> If you want variable length, determine it and remember it.
>
> But as above if you want to interoperate with the Javascrip
Re: Why does openssl still pad data for aes-128-cbc encrypting when the file-size%16==0?
Dear All, Thanks for reply. And I have more question. For example, the actual file size is 16B, and it will be encrypted to 32B. Then, how does decrypt side know its actual size is 16B or 17B? 2012/3/20 Dave Thompson > > From: owner-openssl-us...@openssl.org On Behalf Of Jakob Bohm > > Sent: Monday, 19 March, 2012 13:25 > > > On 3/19/2012 5:26 PM, Nicle wrote: > > > Hi all, > > > > > > I can understand if file-size%16 != 0, openssl will pad data. > > > > > > But it will also pad 16bytes for those file size exactly 16 times. > > > > > > The following description says 16, when it should really > > say "the block size of the algorithm " > > > > OpenSSL is using the same padding rule as specified for > > SSL connections: > > > > Pad with bytes whose value is the number of padding bytes, > > so decryption can see how many bytes to remove to get the > > actual file data without padding. > > > Note TLS uses a slightly modified rule: the padding (N bytes) > and length (1 byte) are defined as separate fields, so each > padding byte AND the count byte contains the count of the > padding bytes not including the count byte! And TLS allows > 'extra' padding -- up to 255 bytes even when the cipher > blocksize doesn't need it. OpenSSL doesn't choose that. > > And no padding is required or done for a stream cipher > (pretty much only RC4) or a stream mode (only GCM). > > > > > So the rule is to pad with 1 to 16 bytes, each of which is > > the number of bytes in the padding. > > > That is the rule for PKCS#5 padding, used by default by EVP > and (thus) commandline enc which is apparently the OP's question. > > > Of cause if you are just using the "openssl enc" command > > line command as a way to access the raw encryption with > > your own padding and security around it, then you can > > just feed it a multiple of 16 bytes, and then throw away > > the 16 bytes of encrypted padding at the end of the result. > > > Or better just specify -nopad. Also on decrypt, where just > adding a guess block wouldn't work well at all, unless > you're implementing the padding oracle attack. > > Commandline enc also by default uses password-based with salt, > which adds another 16 bytes (8 label and 8 salt, regardless > of cipher blocksize) to the file. You can disable that with > -nosalt (but then you have to be careful about passphrase reuse) > or skip PB entirely with -K and -iv (then you must transmit > the IV, either added to the file or along with it). > > > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org >
RE: Why does openssl still pad data for aes-128-cbc encrypting when the file-size%16==0?
> From: owner-openssl-us...@openssl.org On Behalf Of Jakob Bohm > Sent: Monday, 19 March, 2012 13:25 > On 3/19/2012 5:26 PM, Nicle wrote: > > Hi all, > > > > I can understand if file-size%16 != 0, openssl will pad data. > > > > But it will also pad 16bytes for those file size exactly 16 times. > > > The following description says 16, when it should really > say "the block size of the algorithm " > > OpenSSL is using the same padding rule as specified for > SSL connections: > > Pad with bytes whose value is the number of padding bytes, > so decryption can see how many bytes to remove to get the > actual file data without padding. > Note TLS uses a slightly modified rule: the padding (N bytes) and length (1 byte) are defined as separate fields, so each padding byte AND the count byte contains the count of the padding bytes not including the count byte! And TLS allows 'extra' padding -- up to 255 bytes even when the cipher blocksize doesn't need it. OpenSSL doesn't choose that. And no padding is required or done for a stream cipher (pretty much only RC4) or a stream mode (only GCM). > So the rule is to pad with 1 to 16 bytes, each of which is > the number of bytes in the padding. > That is the rule for PKCS#5 padding, used by default by EVP and (thus) commandline enc which is apparently the OP's question. > Of cause if you are just using the "openssl enc" command > line command as a way to access the raw encryption with > your own padding and security around it, then you can > just feed it a multiple of 16 bytes, and then throw away > the 16 bytes of encrypted padding at the end of the result. > Or better just specify -nopad. Also on decrypt, where just adding a guess block wouldn't work well at all, unless you're implementing the padding oracle attack. Commandline enc also by default uses password-based with salt, which adds another 16 bytes (8 label and 8 salt, regardless of cipher blocksize) to the file. You can disable that with -nosalt (but then you have to be careful about passphrase reuse) or skip PB entirely with -K and -iv (then you must transmit the IV, either added to the file or along with it). __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: ACK message usage
> From: owner-openssl-us...@openssl.org On Behalf Of Fekete, Tamás (lesswire AG Ungarn) > Sent: Saturday, 17 March, 2012 01:03 > But I am thinking, maybe a trivial question to you. > Do I need use something "to ACK" messages? Maybe. It depends on your application(s). SSL/TLS, like TCP which it is designed to partly replace, is (stream-oriented and) only conditionally reliable -- IF the data is delivered it will be correct (in-sequence, not duplicated, not altered including insert or delete) but it may be delayed arbitrarily long, and a suffix may be lost entirely (albeit with an indication for >=3.0 IIRC). > As I know lower layers treat ACK and if something went wrong > I receive error message during the sending yet. Is it true, is not? At the SSL/TLS protocol level there is no explicit ack or flow control of data. (There are some implicit acks in the handshake protocol.) SSL/TLS just passes data down to TCP which should get it there. TCP does have acks, but not synchronous; a send call can and often does return 'successfully' before all of the data has been actually sent on the wire, or _any_ of it has been received. If the data isn't acked 'soon' by the receiving stack, according to various rules/heuristics, the sender stack will retry, and if it still gets no ack after some number of retries, or if it gets an explicit down indication (RST or various ICMP), it will return an error to the caller on the *next* send *or recv* call. (Here TCP returns the error to OpenSSL, which in turn returns it to the application.) Moreover, even if the receiving TCP stack acks some data, that doesn't mean the receiving *application* got the data, much less processed it successfully. > And in this way if I implemented ACK mechanism > into my protocol it would be useless. If you need an application level ack, it is not useless. > Or maybe do you know such kind of situation where > it can be useful? Because in that case if I find one situation > I let it in my code, but in other hand I remove that. Generally if there is any importance to the transmission of data additional to the content of the response if any, consider ack-ing. A common and relatively understandable example is HTTP (commonly used over both SSL/TLS and TCP). If you send a request and get back a page*, or an HTTP error like 404, you know the request was received and processed. If you get a disconnect before/without any HTTP response, you don't know what happened, but often you can just retry the same request on a new connection. Some requests, often POSTs, shouldn't be retried because that might result, for example, in making two payments when you intended only one. If the processing of the request takes a long time, during which an interruption leaves the status of the request "in doubt", you might issue an interim (dummy) response that says "I got request X and am processing it, check later for results" and then use a GET with a unique id to check for and (eventually) get the results, with (safe) retries if needed. However, there will always be some window, even if you make it shorter, where a transaction/request/whatever is in doubt, and must be resolved by some other means. This is inherent in nearly all distributed protocols and is generically called the "last-ack" problem. And it is true even for any ack's you put in your application protocol, so think about how your users can/will deal with problem cases. * Technically any resource, not necessarily a webpage; but in my experience requests that get non-HTML resources are always(?) idempotent i.e. safely retriable. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Difference b/w TLS Connection and TLS Session
> From: owner-openssl-us...@openssl.org On Behalf Of Mr.Rout > Sent: Sunday, 18 March, 2012 03:55 > We have fixed the Segment lost issue which was causing Packet > drop. But we > are still seeing the "Encryption Alert" again. I am attaching one more > packet capture which has all the information. > You are seeing "Encrypted Alert", not "Encryption Alert". > Due to my limited knowledge i request would you please > explain me the exact > reason for this Error message. > The alert is encrypted, which prevents us from knowing for sure which alert it is. But the only alert that usually follows application data in this way is alert #0 Close, which is quite normal and not an error as far as SSL/TLS is concerned. It may be an error at the application level if the application (endpoint) shouldn't have closed this connection at this time. If so you need application level information to debug this. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: How to use PKCS5_PBKDF2_HMAC_SHA1()
> From: owner-openssl-us...@openssl.org On Behalf Of pkumarn
> Sent: Monday, 19 March, 2012 03:06
> I am trying to use PKCS5_PBKDF2_HMAC_SHA1() and below is my
> sample program.
> I wanted to make sure if my result of
> PKCS5_PBKDF2_HMAC_SHA1() is correct so
> i verified the same with the below wesbite
> http://anandam.name/pbkdf2/ and i
> see a different result... Am i using the API correctly?
> I am having doubts if i am passing salt value correctly...
>
That site is Javascript which treats the salt (and password)
directly as data. I don't know if or how browser(s) can
reliably enter data other than printable ASCII in a ;
it may very well depend on browser and locale settings.
For simplicity if you want to interoperate with this PBKDF2
implementation I would therefore limit both salt and password
to printable ASCII 0x20-0x7E. (32 chars of salt, even restricted
to 5 or 6 bits entropy each, is far more than needed, especially
if you are deriving a 40-bit key as your code indicates.)
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> #include
>
> #include
> #include
> #include
> #include
>
Asides: malloc.h is not standard or portable; standardly
malloc() and related functions are in stdlib.h.
types.h is not standard C (though sys/types.h is POSIX).
Repeating string.h is clutter and may waste time.
I would group openssl/rand.h with the other openssl/*.
> #include
> #define KEY_LEN32// 32 bytes - 256 bits
> #define KEK_KEY_LEN 5
> #define ITERATION 1000
>
> //unsigned char salt_value[32]={"5d85947b4292ea6463faf6893451232"};
> unsigned char salt_value[KEY_LEN];
> unsigned char AESkey[KEY_LEN];
> unsigned char XTSkey[KEY_LEN];
> u8 fuse_key[KEY_LEN];
>
Aside: using KEY_LEN as the length of the salt (which is not a key
of any kind) is somewhat confusing; suggest SALT_LEN instead.
KEK_KEY_LEN is redundant, like "CPU unit"; suggest KEK_LEN.
>
> void main()
main returning void is not standard and never has been,
and has no advantage whatsoever over the standard, int.
> {
>
> s32 i=0;
> s32 len =0;
> u8 *out;
> u8 *rspHMAC;
> const s8 pwd[] = "test";
> s8 rspPKCS5[KEK_KEY_LEN * 2];
> s32 ret;
>
Note: these types are not standard or portable. C99
(still not implemented everywhere, even though C11 has
just come out) *may* have types of the form int8_t etc.
However, below you treat pwd and rspPKCS5 below as arrays
of 'plain' char. 'Plain' char is unsigned on some systems,
so you would either have to make 's8' unsigned which is
confusing and likely to lead to bugs, or leave s8 signed
but convert all your accesses to be unsigned, which is
a good deal of extra work and easy to get wrong.
> rspHMAC = (unsigned char *) malloc(sizeof(char) * KEY_LEN);
> out = (unsigned char *) malloc(sizeof(char) * KEK_KEY_LEN);
>
The return from malloc never needs to be cast in valid C; in C++
it does but in C++ you generally shouldn't use malloc at all.
For these small fixed sizes, dynamic allocation is a waste of
effort and clutter. sizeof(char) is always 1 so it isn't needed,
although if you consistently follow the pattern of N*sizeof(E)
for all types it doesn't hurt to be consistent here.
> RAND_bytes(salt_value, KEY_LEN);
>
>
> printf("\n salt_value[0] = %x; salt_value[31]= %x", salt_value[0],
> salt_value[31]);
> printf("\n strlen(salt_value) = %d; sizeof(salt_value) = %d\n",
> strlen(salt_value), sizeof(salt_value));
> //printf("\n salt_value = %s", salt_value);
>
As I said before, RAND_bytes generates random bytes,
which can include null and then strlen() is too low;
while your buffer didn't include a null terminator (nor room
for one) so in general strlen() could be too high -- although
here salt_value is file-scope static and very likely to be
followed in memory by the next file-scope static here AESkey
which appears to be unused and thus still zero, although some
implementations may follow salt_value by the next _referenced_
external static and that may well contain nonnull bytes.
If you want a constant length, use a constant for length.
If you want variable length, determine it and remember it.
But as above if you want to interoperate with the Javascript
on that website, it's probably easiest to limit yourself to
bytes which are printable ASCII characters. The simplest way
is just use columns 4 and 5 (0x40-0x5F). For that do:
if( RAND_bytes (salt_value,N) <= 0 ) /* ERROR! */
for( i = 0; i < N; i ++ )
salt_value[i] = (salt_value[i] & 0x1F) | 0x40;
// parens redundant but shown for clarity
As above, 32 chars of 5 bits entropy is more than needed
for security; 50-100 bits (10-20 x 5) is usually plenty
and usually more than the actual strength of the password.
> for(i = 0; i < KEY_LEN; i++) {
> printf("%02x", salt_value[i]);
>
Here you correctly use the constant length KEY_LEN,
to convert to hex. B
Re: Why does openssl still pad data for aes-128-cbc encrypting when the file-size%16==0?
It makes the response unambiguous. If a 16 byte file was not padded, how does the receiver know whether the file was 16 bytes or 1-15 bytes plus padding. By having at least one byte of padding, and (in some padding schemes) having the padding itself define the number of padding bits, one can always recover the length of the file. On 3/19/2012 12:26 PM, Nicle wrote: I can understand if file-size%16 != 0, openssl will pad data. But it will also pad 16bytes for those file size exactly 16 times. For example: original file size 16 bytes, cipher file size: 32 bytes. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Why does openssl still pad data for aes-128-cbc encrypting when the file-size%16==0?
On 3/19/2012 5:26 PM, Nicle wrote: Hi all, I can understand if file-size%16 != 0, openssl will pad data. But it will also pad 16bytes for those file size exactly 16 times. For example: original file size 16 bytes, cipher file size: 32 bytes. Any help will be so appreciated. Best Regards Neo The following description says 16, when it should really say "the block size of the algorithm you select, e.g. 8 for DES, IDEA, 3DES and Blowfish, 16 for AES and TwoFish etc." OpenSSL is using the same padding rule as specified for SSL connections: Pad with bytes whose value is the number of padding bytes, so decryption can see how many bytes to remove to get the actual file data without padding. To make this work for file-size%16 == 0, it is necessary to pad with 16 bytes whose value are all 16, otherwise, decryption could not tell the difference between a 16 byte file whose last byte was 1 and a 15 byte file. Some beginners have suggested only padding with 16 x 16 if the last bytes of plain text happens to be one of the 16 padding patterns, but this would cause the size of the encrypted file to reveal if the last bytes of the plain text file was one of those values or not, which was supposed to be hidden by the encryption. So the rule is to pad with 1 to 16 bytes, each of which is the number of bytes in the padding. There is one more rule: If decryption sees a result which does not end with a valid padding, it must not return an error message any different from what it would have returned for any other corrupt file, as otherwise an attacker can use the error message to tell how close she is to guessing the secret key. Of cause if you are just using the "openssl enc" command line command as a way to access the raw encryption with your own padding and security around it, then you can just feed it a multiple of 16 bytes, and then throw away the 16 bytes of encrypted padding at the end of the result. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Why does openssl still pad data for aes-128-cbc encrypting when the file-size%16==0?
Hi all, I can understand if file-size%16 != 0, openssl will pad data. But it will also pad 16bytes for those file size exactly 16 times. For example: original file size 16 bytes, cipher file size: 32 bytes. Any help will be so appreciated. Best Regards Neo
Re: support of RFC-5280
On Fri, Mar 16, 2012 at 4:14 PM, Jakob Bohm wrote: > On 3/15/2012 7:04 PM, pankaj jain wrote: > >> Hi, >> I am using openssl-0.9.8 release; >> I could not find any documentation if it supports RFC-5280. >> >> basically I am looking for the answers about following capabilities: >> >> 1. While receiving a certificate can I extract the canonical hostname >> from the subjectCommonName (CN) if (and only if) it is not present in the >> subjectAltName. >> >> >> I believe all OpenSSL versions ever allow you to see both the CN > and all the subjectAltName's and make your own decisions. > > Note that whatever RFC5280 may say, the Postel principle implies > that you should accept the certificate as valid even if it has a list > of subjectAltName attributes that do not duplicate the CN, as this > appears to be the common practice in certificates currently issued > by trusted public CAs. > > -- > Jakob Bohm, CIO, partner, WiseMo A/S. http://www.wisemo.com > Transformervej 29, 2730 Herlev, Denmark. direct: +45 31 13 16 10 > > This message is only for its intended recipient, delete if misaddressed. > WiseMo - Remote Service Management for PCs, Phones and Embedded > __**__**__ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org > Hi Jakob, Thanks for your response; I should have asked my question differently; basically I wanted to know the default behavior of openssl with respect to extracting the canonical hostname to verify the certificate. does it give priority to subjectAltName and use the CN if and only if subjectAltName is empty. excuse me if I am asking something obvious.
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
Regarding TLS resumption patch
Hi All, I am trying to add tls resumption code in my currently existing application which uses openssl-0.9.8l. Its already includes 4507 patch. Please let me know is it contains any vulnerability or shall I use the TLS SessionTickets extension patch which supports RFC 5077. Thanks in Advance Best Regards, Gayathri
Re: Maintenance releases on 0.9.8
On 3/19/2012 7:50 AM, grarpamp wrote: Since OpenSSL 0.9.8 is still in widespread use it will still be maintained for some time yet. I think part of this is may due to the new 1.x.x releases not being able to compile on older releases of operating systems. Perhaps a short round of effort in resolving that would allow people to move forward? Another issue is that 0.9.8 has been incorporated into various distributions that have themselves been declared as "long term support" releases, meaning that those distributions and their use of 0.9.8 will persist for some time to come. A third issue is that currently, 0.9.8 is the only OpenSSL release to support a FIPS certified configuration, while the upcoming 2.0 FIPS module will add that feature to 1.0.1 as well, the nature of government work will be keeping 0.9.8+FIPS 1.2 around for years to come. Should there be developed a customary formal policy on this as many others now do? Ie: date of release plus n amount of time Such policies, as spearheaded by Microsoft are a bad idea. As a bare minimum, the date to count from should be the date of the superseding release, not the date of the original release, as projects that need X years of future support might begin at any time during the upstream (in this case OpenSSL) release cycle. If upstream takes an unpredictable X years between two releases, those X years should not be deducted from the time that users can rely on security updates for whatever was the current release when they downloaded it. Also, there was a thread on here not long ago about how to compile openssl fully statically both with and without zlib. I don't think anyone really happened to address that well. What would be required to request further consideration of that thread? I am interested in that as well. There are many good reasons to link openssl statically rather than as a dynamic library. On platforms that support dynamic libraries there are equally good reasons to link openssl statically into a plugin-style dynamic library whose primary functionality is something else. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
How to use PKCS5_PBKDF2_HMAC_SHA1()
Hi,
I am trying to use PKCS5_PBKDF2_HMAC_SHA1() and below is my sample program.
I wanted to make sure if my result of PKCS5_PBKDF2_HMAC_SHA1() is correct so
i verified the same with the below wesbite http://anandam.name/pbkdf2/ and i
see a different result... Am i using the API correctly?
I am having doubts if i am passing salt value correctly...
I have pasted my result and website result after the program...
Please guide me to understand this...
===
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define KEY_LEN32// 32 bytes - 256 bits
#define KEK_KEY_LEN 5
#define ITERATION 1000
//unsigned char salt_value[32]={"5d85947b4292ea6463faf6893451232"};
unsigned char salt_value[KEY_LEN];
unsigned char AESkey[KEY_LEN];
unsigned char XTSkey[KEY_LEN];
u8 fuse_key[KEY_LEN];
void main()
{
s32 i=0;
s32 len =0;
u8 *out;
u8 *rspHMAC;
const s8 pwd[] = "test";
s8 rspPKCS5[KEK_KEY_LEN * 2];
s32 ret;
rspHMAC = (unsigned char *) malloc(sizeof(char) * KEY_LEN);
out = (unsigned char *) malloc(sizeof(char) * KEK_KEY_LEN);
RAND_bytes(salt_value, KEY_LEN);
printf("\n salt_value[0] = %x; salt_value[31]= %x", salt_value[0],
salt_value[31]);
printf("\n strlen(salt_value) = %d; sizeof(salt_value) = %d\n",
strlen(salt_value), sizeof(salt_value));
//printf("\n salt_value = %s", salt_value);
for(i = 0; i < KEY_LEN; i++) {
printf("%02x", salt_value[i]);
}
ret = PKCS5_PBKDF2_HMAC_SHA1(pwd, strlen(pwd), salt_value,
strlen(salt_value), ITERATION, KEK_KEY_LEN, out);
printf("\n PKCS#5 :");
for(len = 0; len < KEK_KEY_LEN; len++){
printf("%02x", out[len]);
/* o/p of PKCS5 is stored in buf "out". This cannot be used directly
as each out[len] will have 2 char
but for key gen, we need to consider each char of out as a value. -
Needs sentence reframing
*/
sprintf(&rspPKCS5[len * 2], "%02x", out[len]);
}
printf("\n");
}
Sample O/P:
salt_value[0] = e2; salt_value[31]= 12
strlen(salt_value) = 32; sizeof(salt_value) = 32
e258017933f3e629a4166cece78f3162a3b0b7edb2e94c93d76fe6c38198ea12
PKCS#5 :7d7ec9f411
Website result:
The derived 40-bit key is: a5caf6a0d3
--
View this message in context:
http://old.nabble.com/How-to-use-PKCS5_PBKDF2_HMAC_SHA1%28%29-tp33529423p33529423.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
