Re: [openssl.org #181] Makefile enhancement requests

[Aleksi Suhonen via RT]

Hello,

Quote from "Richard Levitte via RT":
} > > * When linking the libraries, make sure that libssl finds libcrypto
} > > and that they both find all their external dependencies at run time.
} > > This is accomplished by the -R, -rpath or --rpath flags which behave
} > > just like the -L flag. It is not necessary when all libraries can be
} > > found using the default paths. To recap: giving --prefix to config
} > > should automatically add -R${prefix}/lib and giving -L... to config
} > > should automatically generate the same -R...
} > > (Which flag to use depends on which compiler one is using.)

} Isn't there a case when the -L and the -R arguments have different
} arguments?

Yes, in hind sight I see I made a generalization. Normally one tries to
link against libraries that are already installed, in which case the -L
and -R match, but in your case you are linking against libraries that
haven't been installed yet.

} For example, the openssl program is linked against libssl and libcrypto
} in the parent directory, so the linking command includes -L.. .
} However, the -R switch would indicate where the libraries are found by
} default, so adding such a switch should look like this, roughly:
} -R${prefix}/lib, even when we have a -L.. .  Right?

Yes, that is correct.

-L tells the linker where to find the libraries when linking and
-R tells the dynamic run-time linker where to find the libraries when
running the program.

This is also true when trying to dynamically link a library that wants
to dynamically link another library. (E.g. libssl uses libcrypto, so
when creating libssl.so the linker should be told where libcrypto.so
will finally reside when installed.)

To check that everything works the way it should, try installing
openssl in /some/weird/directory and then compiling some other piece
of software, like openssh, against it.

To debug the link paths, use ldd -v [library | executable]. On
Solaris you should also give the flag -s to ldd to see the verbose
search path. I couldn't find a similar flag in the Linux Debian
Unstable ldd. I couldn't find a linker debugger on the OSF1 (Tru64)
machine I have access to and the HP-UX machine I have access to is
down at the moment.

--
Aleksi Suhonen

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [openssl.org #451] SX6 port

[Wendy Palm via RT]

$ ./openssl req -x509 -new -nodes -out sscert.pem -rand /tmp/somefile
Generating a 1024 bit RSA private key
++
..++
writing new private key to 'privkey.pem'
-
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-
Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:
Email Address []:



Stephen Henson via RT wrote:

> [[EMAIL PROTECTED] - Sat Feb  1 00:02:48 2003]:
> 
> 
>>$ cd apps
>>$ ./openssl req -x509 -new -nodes -out sscert.pem
>>
>>unable to load 'random state'
>>This means that the random number generator has not been seeded
>>with much random data.
>>Generating a 1024 bit RSA private key
>>8953:error:24064064:random number generator:SSLEAY_RAND_BYTES:PRNG not
>>seeded:md_rand.c:503:You need to read the OpenSSL FAQ,
>>http://www.openssl.org/support/faq.html
>>8953:error:04069003:rsa routines:RSA_generate_key:BN
>>lib:rsa_gen.c:182:
>>
>>it didn't get as far as asking any questions
>>
>>
> 
> OK, the PRNG doesn't get seeded. So it should get further if you try:
> 
> openssl req -x509 -new -nodes -out sscert.pem -randfile ./somefile
> 
> where "somefile" is a file with some random data in it, any old text
> file will do for this test.
> 
> Steve.
> 


-- 
wendy palm
Cray OS Sustaining Engineering, Cray Inc.
[EMAIL PROTECTED], 651-605-9154

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #451] SX6 port

[Stephen Henson via RT]

[[EMAIL PROTECTED] - Sat Feb  1 00:02:48 2003]:

> $ cd apps
> $ ./openssl req -x509 -new -nodes -out sscert.pem
> 
> unable to load 'random state'
> This means that the random number generator has not been seeded
> with much random data.
> Generating a 1024 bit RSA private key
> 8953:error:24064064:random number generator:SSLEAY_RAND_BYTES:PRNG not
> seeded:md_rand.c:503:You need to read the OpenSSL FAQ,
> http://www.openssl.org/support/faq.html
> 8953:error:04069003:rsa routines:RSA_generate_key:BN
> lib:rsa_gen.c:182:
> 
> it didn't get as far as asking any questions
> 

OK, the PRNG doesn't get seeded. So it should get further if you try:

openssl req -x509 -new -nodes -out sscert.pem -randfile ./somefile

where "somefile" is a file with some random data in it, any old text
file will do for this test.

Steve.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [openssl.org #487] bug in BN_generate_prime for small n.

[Cameron Gregory via RT]

G'Day Bodo,
A descent solution here is just to update to the documentation,
since the man page says it generates a num bit prime but in certain
cases, it does not :-) (num < 15?)
Some mention to the randomness of the prime at low num might
also be worthy (if indeed there is some issue around num=15 to 20)
(yes, my code requested safe primes, but the same problem happens if you
don't ask for safe primes!)

thanks,

Cameron

   

Bodo Moeller via RT wrote:

>On Fri, Jan 31, 2003 at 08:12:41AM +0100, Cameron Gregory via RT wrote:
>
>  
>
>>for num < 15 .. always get the same result.. and it's larger than
>>expected...
>>
>>
>
>Reason: The internal OpenSSL function 'probable_prime' (in
>crypto/bn/bn_prime.c) uses a built-in list of small primes for sieving
>out candidate random numbers that cannot be prime.  But the test does
>not correctly the handle the special case that the candidate *is* one
>of small primes in the list -- they will be falsely rejected.
>
>Generally the design cannot handle generation of *short* primes well,
>the desired bit-length is actually treated as a lower limit: if a
>candidate is rejected, some delta will be added to obtain a new
>candidate.  For very short numbers, this addition is likely to
>increase the bit-length of the candidate.
>
>(Your code requests safe primes, so it is in general impossible to
>exactly meet the requested bit-length -- there is a two-bit prime,
>namely 3, but it is not a safe prime.)
>
>
>  
>

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [openssl.org #451] SX6 port

[Wendy Palm via RT]

$ cd apps
$ ./openssl req -x509 -new -nodes -out sscert.pem

unable to load 'random state'
This means that the random number generator has not been seeded
with much random data.
Generating a 1024 bit RSA private key
8953:error:24064064:random number generator:SSLEAY_RAND_BYTES:PRNG not 
seeded:md_rand.c:503:You need to read the OpenSSL FAQ, 
http://www.openssl.org/support/faq.html
8953:error:04069003:rsa routines:RSA_generate_key:BN lib:rsa_gen.c:182:

it didn't get as far as asking any questions

Stephen Henson via RT wrote:

> [[EMAIL PROTECTED] - Fri Jan 31 21:36:01 2003]:
> 
> 
>>i'm happy to test anything you want, but crays are more my forte
>>and NEC just my spare time, so i can't provide much programming
>>help myself.
>>
>>
> 
> I don't have acess to anything like that myself so...
> 
>>From that report it looks like the stuff that creates a self signed
> certificate in OpenSSL is dumping core.
> 
> If you could try:
> 
> openssl req -x509 -new -nodes -out sscert.pem
> 
> (just hit return through all the prompts)
> 
> see if that crashes and then get some idea where the crash occurs with a
> debugger that would help a lot.
> 
> Thanks, Steve.
> 


-- 
wendy palm
Cray OS Sustaining Engineering, Cray Inc.
[EMAIL PROTECTED], 651-605-9154

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #451] SX6 port

[Stephen Henson via RT]

[[EMAIL PROTECTED] - Fri Jan 31 21:36:01 2003]:

> i'm happy to test anything you want, but crays are more my forte
> and NEC just my spare time, so i can't provide much programming
> help myself.
> 

I don't have acess to anything like that myself so...

>From that report it looks like the stuff that creates a self signed
certificate in OpenSSL is dumping core.

If you could try:

openssl req -x509 -new -nodes -out sscert.pem

(just hit return through all the prompts)

see if that crashes and then get some idea where the crash occurs with a
debugger that would help a lot.

Thanks, Steve.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [openssl.org #359] Calling SSL_read and SSL_write with non-emptyerror stack may cause an error

[Arne Ansper]

> >>I just checked. Seems that SSL_CTX_use_certificate_chain_file has a same
> >>problem. Other uses of ERR_peek_error seem to be immune to the old entries
> >>in error stack.
> >
> >
> > One theory is that applications should not call arbitrary OpenSSL
> > functions while there is stuff in the error queue.
> >
> > A second theory is that OpenSSL should always clear the error queue by
> > calling ERR_clear_error() if stuff left in the error queue might cause
> > confusion later.
>
> How can it cause confusion (I think I missed something here)? You should
> only look at the error stack if you got an error, surely?

There are places (three if I remember correctly) in OpenSSL that look at
the error stack and when there is something decide that something went
wrong.

When the ticket was opened I proposed that one should not use the contents
of the error stack for anything else other than reporting the error. If
you must differentiate between two types of errors that may happen in some
function, add an additional parameter to the function (of type int* for
example) that can carry out the special error condition from the function.

There are actually very few places inside OpenSSL where ERR_peek_error and
ERR_get_error are used, so the required changes are not big.

Arne

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [openssl.org #451] SX6 port

[Wendy Palm via RT]

i'm happy to test anything you want, but crays are more my forte
and NEC just my spare time, so i can't provide much programming
help myself.

Stephen Henson via RT wrote:

> [[EMAIL PROTECTED] - Fri Jan 31 21:06:07 2003]:
> 
> 
>>i'm sorry for the delay in response.  i've been out of the office
>>   during the
>>last couple of weeks.
>>
>>yes, more tests fail than i reported, but we only wanted enough
>>   openssl
>>to work with openssh, so once i got what i wanted, i didn't go any
>>   further
>>until i had more time to devote to it.
>>
>>attached is the test output you requested.
>>
>>
> 
> Hmmm... this is a bit worrying:
> 
> 
> convert the certificate request into a self signed certificate using 'x509'
> unable to load 'random state'
> This means that the random number generator has not been seeded
> with much random data.
> Consider setting the RANDFILE environment variable to point at a file that
> 'random' data can be kept in (the file will be overwritten).
> Signature ok
> subject=/C=AU/O=Dodgy Brothers/CN=Dodgy CA
> core dumping
> ./testss: 3837 Memory fault - core dumped
> error using 'x509' to self sign a certificate request
> *** Error code 1 (bu21)
> --
> 
> might be related to the new ASN1 code but its not possible to be sure
> from that.
> 


-- 
wendy palm
Cray OS Sustaining Engineering, Cray Inc.
[EMAIL PROTECTED], 651-605-9154

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #451] SX6 port

[Stephen Henson via RT]

[[EMAIL PROTECTED] - Fri Jan 31 21:06:07 2003]:

> i'm sorry for the delay in response.  i've been out of the office
>during the
> last couple of weeks.
> 
> yes, more tests fail than i reported, but we only wanted enough
>openssl
> to work with openssh, so once i got what i wanted, i didn't go any
>further
> until i had more time to devote to it.
> 
> attached is the test output you requested.
> 

Hmmm... this is a bit worrying:


convert the certificate request into a self signed certificate using 'x509'
unable to load 'random state'
This means that the random number generator has not been seeded
with much random data.
Consider setting the RANDFILE environment variable to point at a file that
'random' data can be kept in (the file will be overwritten).
Signature ok
subject=/C=AU/O=Dodgy Brothers/CN=Dodgy CA
core dumping
./testss: 3837 Memory fault - core dumped
error using 'x509' to self sign a certificate request
*** Error code 1 (bu21)
--

might be related to the new ASN1 code but its not possible to be sure
from that.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [openssl.org #451] SX6 port

[Wendy Palm via RT]

i'm sorry for the delay in response.  i've been out of the office during the
last couple of weeks.

yes, more tests fail than i reported, but we only wanted enough openssl
to work with openssh, so once i got what i wanted, i didn't go any further
until i had more time to devote to it.

attached is the test output you requested.

Richard Levitte via RT wrote:

> Will anything happen with this?
> 
> [[EMAIL PROTECTED] - Sat Jan 18 11:02:31 2003]:
> 
> 
>>I already answered this once, but it didn't come through for some
>>reason...
>>
>>
>+ "sx6", "cc:-g -DTERMIOS::(unknown):::SIXTY_FOUR_BIT DES_INT:::",
>
>
No optimization? Not even lousy -O?

>>>-g overrides any optimization you give,
>>>
>>Yes, that's what normally happens...
>>
>>
>>>and i think there's a problem with
>>>the optimizer anyway because with default optimization, aes-128-cbc
>>>
>>test fails.
>>
>>>it's fine with -g.
>>>
>>I wonder if AES is the only one affected. Could you run 'make -k test'
>>and submit output?
>>
>>A.
>>
>>
> 
> 


-- 
wendy palm
Cray OS Sustaining Engineering, Cray Inc.
[EMAIL PROTECTED], 651-605-9154
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #484] openssl question

[Stephen Henson via RT]

[[EMAIL PROTECTED] - Fri Jan 31 07:56:07 2003]:

> In message <[EMAIL PROTECTED]> on Fri, 31 Jan
> 2003 04:59:36 +0100 (MET), " via RT" <[EMAIL PROTECTED]> said:
> 
> rt>
> rt> Do you have any ideia when?
> 
> 0.9.8 at the earliest.

0.9.8 at the latest :-)

I'm currently testing some code that handles IPv6 and I'll check it into
0.9.8-dev in the next day or so.

Steve.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [openssl.org #359] Calling SSL_read and SSL_write with non-emptyerror stack may cause an error

[Ben Laurie]

Bodo Moeller via RT wrote:

On Tue, Nov 26, 2002 at 10:44:15PM +0200, Arne Ansper wrote:



I just checked. Seems that SSL_CTX_use_certificate_chain_file has a same
problem. Other uses of ERR_peek_error seem to be immune to the old entries
in error stack.



One theory is that applications should not call arbitrary OpenSSL
functions while there is stuff in the error queue.

A second theory is that OpenSSL should always clear the error queue by
calling ERR_clear_error() if stuff left in the error queue might cause
confusion later.


How can it cause confusion (I think I missed something here)? You should 
only look at the error stack if you got an error, surely?

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #328] DH_compute_key incompatable with PKCS #3

[Stephen Henson via RT]

[[EMAIL PROTECTED] - Thu Nov 14 18:54:19 2002]:

> 
> RFC 2246 is very vague:
> 
> """
> 8.1.2. Diffie-Hellman
> 
>A conventional Diffie-Hellman computation is performed. The
>negotiated key (Z) is used as the pre_master_secret, and is
> converted
>into the master_secret, as specified above.
> """
> 
> [looks like this was copied directly from Netscape's SSLv3 docs]
> 
> What "conventional" is supposed to mean in this case is totally
> unclear to
> me. If I read this with no other knowledge, I would probably assume
> conventional == compatible with PKCS #3, since that was the DH
> standard of
> choice around the time SSLv3 came out, and since Netscape probably
> used
> B-SAFE for the initial SSL implementations. OTOH, who knows?
> 

None of the older version of Netscape implemented DH ciphersuites, dunno
if any of their internal stuff ever did though.

I did add EDH client only ciphersuite support to later versions of NSS
which may be in some versions of Mozilla. It never had any interop
problems with OpenSSL (other than a known issue with SSLv3 and DSS
signature format). I could just have been lucky (or arguably unlucky).
That uses their own internal security library, not sure what it does though.

I'll dig out the NSS source and see if I can work out if it does the
same as us.

Steve.



__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #181] Makefile enhancement requests

[Richard Levitte via RT]

OK, I'm ready to look at what remains of this ticket.  I've got a question:

[levitte - Fri Dec 13 16:19:05 2002]:

> > * When linking the libraries, make sure that libssl finds libcrypto
> > and that they both find all their external dependencies at run time.
> > This is accomplished by the -R, -rpath or --rpath flags which behave
> > just like the -L flag. It is not necessary when all libraries can be
> > found using the default paths. To recap: giving --prefix to config
> > should automatically add -R${prefix}/lib and giving -L... to config
> > should automatically generate the same -R...
> > (Which flag to use depends on which compiler one is using.)

Isn't there a case when the -L and the -R arguments have different arguments?

For example, the openssl program is linked against libssl and libcrypto in the parent 
directory, so the linking command includes -L.. .  However, the -R switch would 
indicate where the libraries are found by default, so adding such a switch should look 
like this, roughly: -R${prefix}/lib, even when we have a -L.. .  Right?

-- 
Richard Levitte
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [openssl.org #481] (0.9.7 on Win32) openssl ca crashes when exiting...

[Jeffrey Altman]

Richard Levitte via RT wrote:


OK, does anyone know a good way to detect (in run-time!) when the program is running as a service?  If there's a way, the rest should be easy.
 

Sorry I have been out of contact on this issue but the problems here are 
not about OpenSSL being used within a service but how OpenSSL is used 
within a service.  Kermit 95 uses OpenSSL and it can be installed as a 
service and the RAND_poll() functions work just fine.  Accessing the 
desktop will not be a fatal error if it cannot be reached.

Where the problem lies is in the calls to obtain performance data.  If 
RAND_poll() is called from within a DLL initialization function and if 
the service uses OLE components there is a race condition in which the 
internal process data structures necessary to read the performance data 
and/or walk the tree are not yet stable.  Attempts to process the 
performance data can therefore result in unexplained exceptions.

What we need is not a way to determine if we are running as a service 
BUT a way to give developers the ability to tell OpenSSL how the library 
is being used so that we know whether or not it is safe to perform 
certain types of randomness gathering.

- Jeff




__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [openssl.org #359] Calling SSL_read and SSL_write with non-empty error stack may cause an error

[Richard Levitte - VMS Whacker via RT]

In message <[EMAIL PROTECTED]> on Fri, 31 Jan 2003 15:50:06 
+0100 (MET), "Bodo Moeller via RT" <[EMAIL PROTECTED]> said:

rt> A second theory is that OpenSSL should always clear the error queue by
rt> calling ERR_clear_error() if stuff left in the error queue might cause
rt> confusion later.

The problem is finding out what it's appropriate.  Let's not forget
that some OpenSSL functions are called from other OpenSSL functions,
so this might be tricky.

Besides, I'm not sure I agree with that theory in any case.  Would
libc functions clear errno all the time?

-- 
Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken  \ S-168 35  BROMMA  \ T: +46-8-26 52 47
\  SWEDEN   \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/

Unsolicited commercial email is subject to an archival fee of $400.
See  for more info.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [openssl.org #359] Calling SSL_read and SSL_write withnon-empty error stack may cause an error

[Richard Levitte - VMS Whacker]

In message <[EMAIL PROTECTED]> on Fri, 31 Jan 2003 15:50:06 
+0100 (MET), "Bodo Moeller via RT" <[EMAIL PROTECTED]> said:

rt> A second theory is that OpenSSL should always clear the error queue by
rt> calling ERR_clear_error() if stuff left in the error queue might cause
rt> confusion later.

The problem is finding out what it's appropriate.  Let's not forget
that some OpenSSL functions are called from other OpenSSL functions,
so this might be tricky.

Besides, I'm not sure I agree with that theory in any case.  Would
libc functions clear errno all the time?

-- 
Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken  \ S-168 35  BROMMA  \ T: +46-8-26 52 47
\  SWEDEN   \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/

Unsolicited commercial email is subject to an archival fee of $400.
See  for more info.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [openssl.org #359] Calling SSL_read and SSL_write with non-empty error stack may cause an error

[Bodo Moeller via RT]

On Tue, Nov 26, 2002 at 10:44:15PM +0200, Arne Ansper wrote:

> I just checked. Seems that SSL_CTX_use_certificate_chain_file has a same
> problem. Other uses of ERR_peek_error seem to be immune to the old entries
> in error stack.

One theory is that applications should not call arbitrary OpenSSL
functions while there is stuff in the error queue.

A second theory is that OpenSSL should always clear the error queue by
calling ERR_clear_error() if stuff left in the error queue might cause
confusion later.

The second theory is nicer, but until someone has patched OpenSSL
appropriately, unfortunately the first theory remains true.


-- 
Bodo Möller <[EMAIL PROTECTED]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [openssl.org #328] DH_compute_key incompatable with PKCS #3

[Bodo Moeller via RT]

On Wed, Dec 04, 2002 at 10:16:37AM -0500, Jack Lloyd wrote:

> I asked Eric Rescorla, and he agreed the section of the TLS RFC was
> definitely unclear, but he wasn't totally sure which way it should go as
> far as stripping any leading 0s before using the shared secret to generate
> keys. It basically depends on what various implementations have decided to
> do.

A safe way for clients to work around this problem for ephemeral DH is
to try a new DH secret if the DH result has a leading zero byte.


-- 
Bodo Möller <[EMAIL PROTECTED]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [openssl.org #487] bug in BN_generate_prime for small n.

[Bodo Moeller via RT]

On Fri, Jan 31, 2003 at 08:12:41AM +0100, Cameron Gregory via RT wrote:

> for num < 15 .. always get the same result.. and it's larger than
> expected...

Reason: The internal OpenSSL function 'probable_prime' (in
crypto/bn/bn_prime.c) uses a built-in list of small primes for sieving
out candidate random numbers that cannot be prime.  But the test does
not correctly the handle the special case that the candidate *is* one
of small primes in the list -- they will be falsely rejected.

Generally the design cannot handle generation of *short* primes well,
the desired bit-length is actually treated as a lower limit: if a
candidate is rejected, some delta will be added to obtain a new
candidate.  For very short numbers, this addition is likely to
increase the bit-length of the candidate.

(Your code requests safe primes, so it is in general impossible to
exactly meet the requested bit-length -- there is a two-bit prime,
namely 3, but it is not a safe prime.)


-- 
Bodo Möller <[EMAIL PROTECTED]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #481] detect if running as service...

[[EMAIL PROTECTED] via RT]

I haven't had the time to go into it, but here's code from
the MSDN VC++6 samples "MAPIDBG.C" that is said
to do just this and seems reasonable.
I'll test this some other time if there's interest.

#if defined( _WINNT)

/*++

Routine Description:

This routine returns if the service specified is running interactively
(not invoked \by the service controller).

Arguments:

None

Return Value:

BOOL - TRUE if the service is an EXE.


Note:

--*/

BOOL WINAPI IsDBGServiceAnExe( VOID )
{
HANDLE hProcessToken = NULL;
DWORD groupLength = 50;

PTOKEN_GROUPS groupInfo = (PTOKEN_GROUPS)LocalAlloc(0, 
groupLength);

SID_IDENTIFIER_AUTHORITY siaNt = SECURITY_NT_AUTHORITY;
PSID InteractiveSid = NULL;
PSID ServiceSid = NULL;
DWORD i;

// Start with assumption that process is an EXE, not a Service.
BOOL fExe = TRUE;


if (!OpenProcessToken(GetCurrentProcess(), TOKEN_QUERY, 
&hProcessToken))
goto ret;

if (groupInfo == NULL)
goto ret;

if (!GetTokenInformation(hProcessToken, TokenGroups, groupInfo,
groupLength, &groupLength))
{
if (GetLastError() != ERROR_INSUFFICIENT_BUFFER)
goto ret;

LocalFree(groupInfo);
groupInfo = NULL;

groupInfo = (PTOKEN_GROUPS)LocalAlloc(0, groupLength);

if (groupInfo == NULL)
goto ret;

if (!GetTokenInformation(hProcessToken, TokenGroups, groupInfo,
groupLength, &groupLength))
{
goto ret;
}
}

//
//  We now know the groups associated with this token.  We want to look to 
see if
//  the interactive group is active in the token, and if so, we know that
//  this is an interactive process.
//
//  We also look for the "service" SID, and if it's present, we know we're a 
service.
//
//  The service SID will be present iff the service is running in a
//  user account (and was invoked by the service controller).
//


if (!AllocateAndInitializeSid(&siaNt, 1, SECURITY_INTERACTIVE_RID, 0, 
0,
0, 0, 0, 0, 0, &InteractiveSid))
{
goto ret;
}

if (!AllocateAndInitializeSid(&siaNt, 1, SECURITY_SERVICE_RID, 0, 0, 0,
0, 0, 0, 0, &ServiceSid))
{
goto ret;
}

for (i = 0; i < groupInfo->GroupCount ; i += 1)
{
SID_AND_ATTRIBUTES sanda = groupInfo->Groups[i];
PSID Sid = sanda.Sid;

//
//  Check to see if the group we're looking at is one of
//  the 2 groups we're interested in.
//

if (EqualSid(Sid, InteractiveSid))
{
//
//  This process has the Interactive SID in its
//  token.  This means that the process is running as
//  an EXE.
//
goto ret;
}
else if (EqualSid(Sid, ServiceSid))
{
//
//  This process has the Service SID in its
//  token.  This means that the process is running as
//  a service running in a user account.
//
fExe = FALSE;
goto ret;
}
}

//
//  Neither Interactive or Service was present in the current users token,
//  This implies that the process is running as a service, most likely
//  running as LocalSystem.
//
fExe = FALSE;

ret:

if (InteractiveSid)
FreeSid(InteractiveSid);

if (ServiceSid)
FreeSid(ServiceSid);

if (groupInfo)
LocalFree(groupInfo);

if (hProcessToken)
CloseHandle(hProcessToken);

return(fExe);
}

#endif

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #457] bug report: BIO_socket_nbio() can't set socket to non-blocking

[Richard Levitte via RT]

[levitte - Fri Jan 31 00:02:41 2003]:

> Hmm, BIO_socket_ioctl() should really take a void* instead of an
>unsigned long *.  Then, BIO_socket_nbio() should send a pointer to
>an int instead of a pointe to a long.  The latter can be done
>anyway and pushed through useing a cast (ugly), or we could change
>that last argument type to BIO_socket_ioctl(), but that breaks the
>API (at least at source level).

I ended up changing the type of the last argument to BIO_socket_ioctl().

This ticket is now resolved.

-- 
Richard Levitte
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RE: [openssl.org #457] bug report: BIO_socket_nbio() can't set so cket to non-blocking

[Magnus Lind via RT]

> From: Richard Levitte via RT [mailto:[EMAIL PROTECTED]]
> 
> Hmm, BIO_socket_ioctl() should really take a void* instead of 
> an unsigned long *.  Then, BIO_socket_nbio() should send a 
> pointer to an int instead of a pointe to a long.  The latter 
> can be done anyway and pushed through useing a cast (ugly), 
> or we could change that last argument type to 
> BIO_socket_ioctl(), but that breaks the API (at least at 
> source level).
> 
> *sigh*

I have now also confirmed this bug to exist on 64-bit Solaris too.
Both solutions are viable in my opinion. The ugly cast avoids breaking
the api and the api breakage is very benign since it won't generate
warings on a c-compiler.

/Regards

Magnus Lind

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #481] Rand()ing on Win32

[[EMAIL PROTECTED] via RT]

[[EMAIL PROTECTED] - Thu Jan 30 20:06:53 2003]:

First of all apologies for mixing several problems in one
post - i promise to do better next time, but i didn't consider
the Rand-problems bugs and really just wanted to mention them
on the side (having solved them for my purposes anyways)
as a hint for others.

> 
> That's a bit coarse.   It might be sufficient to allow the service to
>interact with the desktop [interactive user] (as admin user, right
>click on "My Computer", select Manage..., navigate to the services
>section, right click on the indicated service, choose the "Log On"
>tab, and under the radio button for "Local System account" there's
>a checkbox (off by default): "Allow service to interact with
>desktop".   This can also be enabled when the service registers
>itself at installation.
> 
> See MS Knowledge Base article number 115825 (formerly Q115825), as
>well as the documentation on ::CreateService() and search for
>SERVICE_INTERACTIVE_PROCESS.
> 

What's the use of allowing interaction with a pretty boring
desktop which always looks the same and has no "Mouse action"
for the purpose of generating randomness while introducing
a security risk ?

> 
> Of course some customer locations might be reticent about letting
>services interact with the desktop, this being a potential security
>hole.
> 
> But is there a bug here?  If it runs "okay" (with limited
>functionality) if the service doesn't have permissions to access
>the desktop, isn't that correct?  What would you have it do
>differently if it did detect that it was running as a service?  Is
>there some alternative source of randomness?  (Perhaps the number
>of patches applied to the system? :-).

That would at least give us a high number... :-)
The problem is the following:
I was just compiling stunnel for use as service and had to
get it running in a pretty short amount of time.
Both calls (Rand_poll and RAND_file_name without a specified file)
just had the effect that the service couldn't start up on
system startup.
You would only get a message that the system was unable to start
up the service (for a million seconds or so), before giving up.
I do not consider that a real bug, but it prevents usage
of openSSL within such a service "out of the box".
(It does not run "okay" then, otherwise i wouldn't have
mentioned it)

> 
> If so, it might be best to detect the problem at the specific API call
>that fails rather than decide based on running as a service --
>partly because it might work running as a service, partly because
>it might fail for other reasons when not running as a service.
> 

I did not have the time to really dive deep into problems,
so i was happy just being able to get everything running by
just modifying Rand_poll and skipping the Rand_file_name call
in stunnel.
For Rand_poll i found it sufficient to leave out all stuff
except for MS-randomness, epecially as the screen and user
stuff doesn't seem to make much sense under the aforementioned
circumstances anyways.
If the number of system patches is considered in the MS-algorithm
i can live with that randomness for the time being ;-)
Not giving a Rand_file_name and skipping the function was
o.k. for me too, as i don't have an "external" source of
randomness on the systems i use stunnel on.

If i have the time i'll try to come up with a good way to
determine if beeing run as service, while i for myself
can live with making that decision at compile-time at the
moment.
I'll also see if i can clarify the "rubbish" that comes up
in filename after usage of Rand_file_name without
filename and with no environment-variables set.
The only thing i can say so far is that it definitely
didn't even look slightly similar to something like ".rnd"
(more like the encrypted binary version of the word "rubbish")

I find it a bit tricky debugging a service at system startup
without a remote debugger and leaving conditions
realistic and original, but i'll see...

Thanks a lot,
best reagards,

Claudius Thomas

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]