[openssl.org #1660] Request for feature, all Windows systems, all OpenSSL versions.
I agree with Shaw Graham George's post on openssl-dev. Modifying system settings upon installation would seem to be too intrusive for the OpenSSL source package. OpenSSL as distributed by the OpenSSL team does not modify system settings during installation on any platform. Typically integrators providing distributions like (name-your-favorite) Linux distribution are providing such functions as their value add... and besides they do know more about the specific installation requirements than we do. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: 64 bits computer always returns the same salt
David Erosa García wrote:
Hello all.
I tried the openssl-users list but I think this may be a question for
the devel list:
I'm doing my homework about openssl, but *this question has nothing to
do with it*. It's just a doubt that arised while doing it.
There is one exercise with the following text:
Con el comando “openssl enc” y la siguiente clave AES:
188458A6D15034DFE386F23B61D43774 se puede descifrar cierta información.
Podrías decir cual?
Using the command openssl enc and the following AES key:
188458A6D15034DFE386F23B61D43774 you can decode some information, could
you say what?
I started playing with openssl enc and I thought the only thing I
could guess was the salt (Surely I'm wrong).
So I ran the command with a random IV:
openssl enc -aes128 -K 188458A6D15034DFE386F23B61D43774 -iv 1 -P
I found that the salt varies as it should on two machines with 32 bit
CPU (not my main one):
Office's computer (openssl 0.9.8g-4ubuntu2):
salt=4075DFB76496F2B7
salt=4045D8B76466EBB7
salt=40C5DAB764E6EDB7
salt=4015DEB76436F1B7
salt=4025DFB76446F2B7
A server I have somewhere else (openssl 0.9.8c-4etch1):
salt=50D882BF0C00
salt=B05DD9BF0C00
salt=A0CCC7BF0C00
salt=E0C88BBF0C00
salt=204190BF0C00
But when I run it on my main computer, it always outputs the same salt!
This machine is a 64bit CPU, running a 64bits linux distribution
(openssl 0.9.8g-4ubuntu2):
salt=0004
salt=0004
salt=0004
salt=0004
I've been searching through the openssl lists and found nothing about
this behavior.
What can be happening? Is it about the 64 bit version of openssl?
No, the actual output may depend on the system but the reason behind it
is found in apps/enc.c:
...
if (cipher != NULL)
{
/* Note that str is NULL if a key was passed on the command
* line, so we get no salt in that case. Is this a bug?
*/
if (str != NULL)
...
In the case the str == NULL the memory containing the salt is an
uninitialized part of the stack so its content is undefined and the
behavior will depend on system and compiler (options) used.
Best regards,
Lutz
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: 64 bits computer always returns the same salt
On Wed, Apr 16, 2008, Lutz Jaenicke wrote:
David Erosa García wrote:
He???llo all.
I tried the openssl-users list but I think this may be a question for
the devel list:
I'm doing my homework about openssl, but *this question has nothing to
do with it*. It's just a doubt that arised while doing it.
There is one exercise with the following text:
Con el comando ???openssl enc??? y la siguiente clave AES:
188458A6D15034DFE386F23B61D43774 se puede descifrar cierta información.
Podrías decir cual?
Using the command openssl enc and the following AES key:
188458A6D15034DFE386F23B61D43774 you can decode some information, could
you say what?
I started playing with openssl enc and I thought the only thing I
could guess was the salt (Surely I'm wrong).
So I ran the command with a random IV:
openssl enc -aes128 -K 188458A6D15034DFE386F23B61D43774 -iv 1 -P
I found that the salt varies as it should on two machines with 32 bit
CPU (not my main one):
Office's computer (openssl 0.9.8g-4ubuntu2):
salt=4075DFB76496F2B7
salt=4045D8B76466EBB7
salt=40C5DAB764E6EDB7
salt=4015DEB76436F1B7
salt=4025DFB76446F2B7
A server I have somewhere else (openssl 0.9.8c-4etch1):
salt=50D882BF0C00
salt=B05DD9BF0C00
salt=A0CCC7BF0C00
salt=E0C88BBF0C00
salt=204190BF0C00
But when I run it on my main computer, it always outputs the same salt!
This machine is a 64bit CPU, running a 64bits linux distribution
(openssl 0.9.8g-4ubuntu2):
salt=0004
salt=0004
salt=0004
salt=0004
I've been searching through the openssl lists and found nothing about
this behavior.
What can be happening? Is it about the 64 bit version of openssl?
No, the actual output may depend on the system but the reason behind it
is found in apps/enc.c:
...
if (cipher != NULL)
{
/* Note that str is NULL if a key was passed on the command
* line, so we get no salt in that case. Is this a bug?
*/
if (str != NULL)
...
In the case the str == NULL the memory containing the salt is an
uninitialized part of the stack so its content is undefined and the
behavior will depend on system and compiler (options) used.
Note that the salt is used to derive the key an IV from a passphrase in the
enc utility so if a key and IV are specified on the command line the salt
is never used. The bug is that it still prints out the unused salt.
Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Homepage: http://www.drh-consultancy.demon.co.uk
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1663] bug report openssl-0.9.8g on Windows XP
Andrew Lamoureux via RT wrote: Hi, I'd like to report a bug in openssl-0.9.8g compiled with Visual Studio. OS is Windows XP. Access violation occurs when BN_rshift() is used on a BIGNUM whose bit length is less (amount required varies) than the number of bits requesting to be shifted. Here is very simple code that reliably reproduces the problem: BIGNUM * bnp = BN_new(); BN_rand(bnp, 64, 0, 0); BN_rshift(bnp, bnp, 67); It does crash in BN_rshift() with a segmentation violation on Linux as well. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1662] key generation creates world-readable keys by default
OpenSSL does create keys in more components than just gen(r|d)sa. In none of these functions any file permission mask is used. All of the components in openssl/apps are using the file-BIO which behaves like stdio and does not have idea about file permissions. People using OpenSSL to generate their keys should rather use safe umask settings. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
