understanding openssl entropy

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

understanding openssl entropy

Edward Ned Harvey (openssl)

If this subject varies based on context, then I'm specifically focusing on generating private keys / certs via "openssl" command-line tools on linux (rhel/centos) for use in https, etc.

 

My question is, assuming servers are generated from VM snapshots or clones, or restored from backups, or otherwise relatively free of entropy when they're young, how can you ensure you have good entropy at the time of generating your keys?

 

I guess I'm trying to either learn trust in /dev/urandom, or find a good way to get better randomness due to distrusting /dev/urandom.

 

Based on my understanding of the FAQ and manual, I think the RANDFILE ~/.rnd is used as the seed, for the openssl internal prng, and ~/.rnd will be overwritten upon each use, to be the new seed for next time.  Right?  Apparently not...

 

I did an md5sum on ~/.rnd.  Then I generated some key, and checked the md5sum again.  It changed.  This verifies I'm looking at the right RANDFILE.  So far so good...

 

I tried copying .rnd, then generating some keys, then restoring .rnd, and re-generating the keys.  Just to see if my understanding was right.  But the keys came out different, which suggests my understanding is wrong.  What am I missing?  Does openssl use a combination of the .rnd file and urandom together?

 

Naturally, this question implies distrust for /dev/urandom.  But according to the FAQ & manual, it seems openssl trusts urandom to be sufficiently random.  Why?  Doesn't this defy conventional logic?  That's the point of differentiating random from urandom, isn't it?  Because /dev/urandom only appears random upon cursory inspection, which is good enough to create some variability in video games, but /dev/random should appear random no matter how much you dig into it, which is important for cryptography, isn't it?

 

Does it increase entropy if you overwrite the .rnd file with 1024 bytes from /dev/random?

 

Thanks...

Reply | Threaded
Open this post in threaded view
|

Re: understanding openssl entropy

Jason Gerfen-3
On Fri, Feb 17, 2012 at 9:23 AM, Edward Ned Harvey
<[hidden email]> wrote:

> If this subject varies based on context, then I'm specifically focusing on
> generating private keys / certs via "openssl" command-line tools on linux
> (rhel/centos) for use in https, etc.
>
>
>
> My question is, assuming servers are generated from VM snapshots or clones,
> or restored from backups, or otherwise relatively free of entropy when
> they're young, how can you ensure you have good entropy at the time of
> generating your keys?
>
>
>
> I guess I'm trying to either learn trust in /dev/urandom, or find a good way
> to get better randomness due to distrusting /dev/urandom.
>
>
>
> Based on my understanding of the FAQ and manual, I think the RANDFILE ~/.rnd
> is used as the seed, for the openssl internal prng, and ~/.rnd will be
> overwritten upon each use, to be the new seed for next time.  Right?
> Apparently not...
>
>
>
> I did an md5sum on ~/.rnd.  Then I generated some key, and checked the
> md5sum again.  It changed.  This verifies I'm looking at the right
> RANDFILE.  So far so good...
>
>
>
> I tried copying .rnd, then generating some keys, then restoring .rnd, and
> re-generating the keys.  Just to see if my understanding was right.  But the
> keys came out different, which suggests my understanding is wrong.  What am
> I missing?  Does openssl use a combination of the .rnd file and urandom
> together?
>
>
>
> Naturally, this question implies distrust for /dev/urandom.  But according
> to the FAQ & manual, it seems openssl trusts urandom to be sufficiently
> random.  Why?  Doesn't this defy conventional logic?  That's the point of
> differentiating random from urandom, isn't it?  Because /dev/urandom only
> appears random upon cursory inspection, which is good enough to create some
> variability in video games, but /dev/random should appear random no matter
> how much you dig into it, which is important for cryptography, isn't it?
>
>
>
> Does it increase entropy if you overwrite the .rnd file with 1024 bytes from
> /dev/random?
>
>
>
> Thanks...

This post might serve as a good primer and provide the necessary
information you are looking to obtain although it is titled
differently and addresses all aspects of true randomness per OS
http://marc.info/?l=openssl-dev&m=132733475012928&w=2

--
Jas
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: understanding openssl entropy

David Jacobson-3
In reply to this post by Edward Ned Harvey (openssl)
Here is how /dev/urandom works on the systems I've looked at.  (More specifically, I'm looking at Ubuntu, but I've also looked at Solaris.)

/dev/urandom has some pool of information (commonly called entropy).  At shutdown, the system reads a 4K byte block from /dev/urandom and stores it in /var/lilb/urandom/random-seed.  Think of this as saving the state of /dev/urandom, but really is a random block that is derived from the state. 

On boot, the system reads the contents of /var/lilb/urandom/random-seed and writes it to /dev/urandom.  Assuming /var/lilb/urandom/random-seed was kept secret and not tampered with, the internal state of /dev/urandom now has information carried over from the shutdown.

Internally, some "system entropy" is pushed in every so often.  I don't know what this system entropy is, but I'm pretty sure it includes time-of-day.  (Time-of-day might get pushed in on every call.)  This explains why when you restore the /var/lilb/urandom/random-seed you don't get the same stream out of /dev/urandom.

VMs cause problems here.  When a VM is cloned, the /var/lib/urandom/random-seed file will be cloned, and hence the clones will have the same information pushed in at start up.  In a VM environment, I suspect the "system entropy" can be pretty minimal.  And the time-of-day is known to the attacker.

I'm not a VM expert.  But if you had some other source of entropy (maybe some other server than is not a VM) you could run a program right after the VM clone starts running that gets a block of random data from the other server and writes it to /dev/urandom in the VM.  That data must be kept from the attacker.

    --David Jacobson

On 2/17/2012 8:23 AM, Edward Ned Harvey wrote:

If this subject varies based on context, then I'm specifically focusing on generating private keys / certs via "openssl" command-line tools on linux (rhel/centos) for use in https, etc.

 

My question is, assuming servers are generated from VM snapshots or clones, or restored from backups, or otherwise relatively free of entropy when they're young, how can you ensure you have good entropy at the time of generating your keys?

 

I guess I'm trying to either learn trust in /dev/urandom, or find a good way to get better randomness due to distrusting /dev/urandom.

 

Based on my understanding of the FAQ and manual, I think the RANDFILE ~/.rnd is used as the seed, for the openssl internal prng, and ~/.rnd will be overwritten upon each use, to be the new seed for next time.  Right?  Apparently not...

 

I did an md5sum on ~/.rnd.  Then I generated some key, and checked the md5sum again.  It changed.  This verifies I'm looking at the right RANDFILE.  So far so good...

 

I tried copying .rnd, then generating some keys, then restoring .rnd, and re-generating the keys.  Just to see if my understanding was right.  But the keys came out different, which suggests my understanding is wrong.  What am I missing?  Does openssl use a combination of the .rnd file and urandom together?

 

Naturally, this question implies distrust for /dev/urandom.  But according to the FAQ & manual, it seems openssl trusts urandom to be sufficiently random.  Why?  Doesn't this defy conventional logic?  That's the point of differentiating random from urandom, isn't it?  Because /dev/urandom only appears random upon cursory inspection, which is good enough to create some variability in video games, but /dev/random should appear random no matter how much you dig into it, which is important for cryptography, isn't it?

 

Does it increase entropy if you overwrite the .rnd file with 1024 bytes from /dev/random?

 

Thanks...

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.1913 / Virus Database: 2112/4815 - Release Date: 02/17/12


Reply | Threaded
Open this post in threaded view
|

RE: understanding openssl entropy

Edward Ned Harvey (openssl)
> From: David Jacobson [mailto:[hidden email]]
> Sent: Friday, February 17, 2012 3:33 PM
>
> Here is how /dev/urandom works on the systems I've looked at.  (More
> specifically, I'm looking at Ubuntu, but I've also looked at Solaris.)
>
> /dev/urandom has some pool of information (commonly called entropy).  At

Entropy is the degree of unpredictability.  A single fair coinflip
represents one bit of entropy.  According to the manpage (4) random, there
is not necessarily any entropy in /dev/urandom, and it should not be used
for generating keys.  This is a pseudo random number generator, based on
hashes or ciphers or whatever, which are deterministic given a known initial
state, and which will eventually generate patterns.  By comparison,
/dev/random comes from environmental noise and random sources, such as the
TPM entropy generator, unpredictable delays in hard drive seeks, system
interrupts, keyboard & mouse strokes, microphone noise, ethernet traffic,
etc.  So /dev/random is a highly random source, but it's slow by comparison.
Should be used for key generation.

This whole issue recently in the news about RSA keys being broken is because
so many people out there generated keys without sufficient entropy.  They
"randomly" picked the same keys or key factors.  The whole basis of RSA
depends on the fundamental difficulty of prime factorization, but if two
different public keys are generated with a single shared factor, then it no
longer is the prime factor problem, it's the GCD problem which is easy to
break.  

So these studies went out and scoured the internet, collecting public keys
from every service they could find, which amounts to something like 1-2
million servers, and they scanned them all for identical keys and/or shared
factors.  They found approx 1 in every 250 internet-facing servers
"randomly" chose the same keys or key factors, thus completely broken
cryptography, and the owners are unaware because they thought they chose
random keys.

It causes you to think deeper.  Granted, most of those faulty keys are
probably generated on appliances that have no good entropy source, and most
of the problems *probably* are not relevant to openssl or people using
openssl to generate their keys.  But "probably" is a relative term, and it's
unknown.

The thing everyone's bosses want to know right now:  "Ok, I accept the term
'probably' is sufficient when we're talking on the order of 2^-256
probability of failure or collision, but 1/256 is also 'improbable,' but not
sufficiently improbable.  Please tell me what you're doing to ensure we're
on the order of 2^-256 and not on the order of 1/256."  

End result:  We all need to have a reliable way of estimating how much
entropy went into our key generation.

I'm trying to find a way to ensure sufficient entropy at the time of key
generation.

The openssl documentation says they use urandom.  But the kernel man page
says you shouldn't use urandom for this key generation.  But the openssl man
page also says it uses ~/.rnd (or whatever is specified by RANDFILE).  So
far, the best idea I have is to "cat /dev/random > ~/.rnd" and wait...
Until it is 1k long or longer.  This seems to me like it would satisfy a
really thorough random seeding of the openssl random number generator,
but...

When I make a backup copy of ~/.rnd, and generate some keys, and then
restore ~/.rnd and re-generate the keys...  My keys come out different.
Which suggests either (a) It's not actually using my ~/.rnd file as the
random seed, or (b) It's using ~/.rnd in conjunction with something else
such as urandom.  If the behavior is the former - then I have no grasp on
the entropy.  If the behavior is the latter - then there's no problem, I can
use this technique to ensure strong entropy.

So I'm here talking about this stuff because I'm trying to get a better
understanding of how openssl uses entropy, so I can be assured (and assure
my boss and shareholders) that I have truly random generated keys when I
generate them using openssl.

Jason replied yesterday, referencing another thread on this subject.  It's
long and I haven't read it yet, but I will soon.

Thank you all for reading and writing.  ;-)

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: understanding openssl entropy

Stanislav Meduna
On 18.02.2012 17:02, Edward Ned Harvey wrote:

> So these studies went out and scoured the internet, collecting public keys
> from every service they could find, which amounts to something like 1-2
> million servers, and they scanned them all for identical keys and/or shared
> factors.  They found approx 1 in every 250 internet-facing servers
> "randomly" chose the same keys or key factors, thus completely broken
> cryptography, and the owners are unaware because they thought they chose
> random keys.

Any link to the studies? - I was not able to find anything relevant.
Is this related to the 2008 Debian OpenSSL snafu?

Thanks
--
                                              Stano

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: understanding openssl entropy

Kurt Roeckx
On Sat, Feb 18, 2012 at 05:28:41PM +0100, Stanislav Meduna wrote:

> On 18.02.2012 17:02, Edward Ned Harvey wrote:
>
> > So these studies went out and scoured the internet, collecting public keys
> > from every service they could find, which amounts to something like 1-2
> > million servers, and they scanned them all for identical keys and/or shared
> > factors.  They found approx 1 in every 250 internet-facing servers
> > "randomly" chose the same keys or key factors, thus completely broken
> > cryptography, and the owners are unaware because they thought they chose
> > random keys.
>
> Any link to the studies? - I was not able to find anything relevant.

I believe he's talking about:
http://eprint.iacr.org/2012/064

Which at least the following people talking about it:
http://dankaminsky.com/2012/02/14/ronwhit/
https://freedom-to-tinker.com/blog/nadiah/new-research-theres-no-need-panic-over-factorable-keys-just-mind-your-ps-and-qs


Kurt

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: understanding openssl entropy

Ben Laurie-2
On Sat, Feb 18, 2012 at 5:37 PM, Kurt Roeckx <[hidden email]> wrote:

> On Sat, Feb 18, 2012 at 05:28:41PM +0100, Stanislav Meduna wrote:
>> On 18.02.2012 17:02, Edward Ned Harvey wrote:
>>
>> > So these studies went out and scoured the internet, collecting public keys
>> > from every service they could find, which amounts to something like 1-2
>> > million servers, and they scanned them all for identical keys and/or shared
>> > factors.  They found approx 1 in every 250 internet-facing servers
>> > "randomly" chose the same keys or key factors, thus completely broken
>> > cryptography, and the owners are unaware because they thought they chose
>> > random keys.
>>
>> Any link to the studies? - I was not able to find anything relevant.
>
> I believe he's talking about:
> http://eprint.iacr.org/2012/064
>
> Which at least the following people talking about it:
> http://dankaminsky.com/2012/02/14/ronwhit/
> https://freedom-to-tinker.com/blog/nadiah/new-research-theres-no-need-panic-over-factorable-keys-just-mind-your-ps-and-qs

To be fair, the second link isn't really talking about it, it is
independent (and, IMO, rather better) research.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: understanding openssl entropy

Edward Ned Harvey (openssl)
In reply to this post by Stanislav Meduna
> From: [hidden email] [mailto:owner-openssl-
> [hidden email]] On Behalf Of Stanislav Meduna
>
> On 18.02.2012 17:02, Edward Ned Harvey wrote:
>
> > So these studies went out and scoured the internet, collecting public
keys
> > from every service they could find, which amounts to something like 1-2
> > million servers, and they scanned them all for identical keys and/or
shared
> > factors.  They found approx 1 in every 250 internet-facing servers
> > "randomly" chose the same keys or key factors, thus completely broken
> > cryptography, and the owners are unaware because they thought they
> chose
> > random keys.
>
> Any link to the studies? - I was not able to find anything relevant.
> Is this related to the 2008 Debian OpenSSL snafu?

Not the debian thing.

http://arstechnica.com/business/news/2012/02/crypto-shocker-four-of-every-10
00-public-keys-provide-no-security.ars

There was also an article in the new york times (which I can't find now) and
various other news sources.  But I figure the arstechnica link is probably
sufficient.

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: understanding openssl entropy

David Jacobson-3
In reply to this post by Edward Ned Harvey (openssl)
See comments below.

On 2/18/2012 8:02 AM, Edward Ned Harvey wrote:

>> From: David Jacobson [mailto:[hidden email]]
>> Sent: Friday, February 17, 2012 3:33 PM
>>
>> Here is how /dev/urandom works on the systems I've looked at.  (More
>> specifically, I'm looking at Ubuntu, but I've also looked at Solaris.)
>>
>> /dev/urandom has some pool of information (commonly called entropy).  At
> [snip]
> I'm trying to find a way to ensure sufficient entropy at the time of key
> generation.
>
> The openssl documentation says they use urandom.  But the kernel man page
> says you shouldn't use urandom for this key generation.

You can read a very good, but dated, paper on /dev/random and
/dev/urandom at
http://www.pinkas.net/PAPERS/gpr06.pdf

You will see that /dev/urandom does get real entropy, and, as I said,
entropy is saved across shutdown and reboot, so that even right after
boot (assuming that the file is secure), the entropy is good.

As I said in my previous posting, VMs have difficulties, particularly
right after cloning. The main problem with cloning is that, unless
special procedures are followed, all the clones will have the same
/var/lilb/urandom/random-seed  file.   Furthermore, in a VM many drivers
are virtualized, and the assumptions that went into using the associated
device as an entropy source may not be valid.

There are a few cases where you might want to use /dev/random, but they
are pretty few.  And I've heard that on some systems, /dev/random is
just a symbolic link to /dev/urandom.

Bottom line, I think /dev/urandom is fine as a source of entropy as long
as you are not on a virtual machine and the machine has not been
compromised.  (Well, this also assumes a good implementation.  We all
know about the Debian bug a few years ago.)

   --David Jacobson


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: understanding openssl entropy

Stanislav Meduna
In reply to this post by Edward Ned Harvey (openssl)
On 18.02.2012 22:47, Edward Ned Harvey wrote:

>> Any link to the studies? - I was not able to find anything relevant.
>> Is this related to the 2008 Debian OpenSSL snafu?
>
> Not the debian thing.
>
> http://arstechnica.com/business/news/2012/02/crypto-shocker-four-of-every-10
> 00-public-keys-provide-no-security.ars

Thank you and Kurt for the links, it is quite an interesting
reading.

The
https://freedom-to-tinker.com/blog/nadiah/new-research-theres-no-need-panic-over-factorable-keys-just-mind-your-ps-and-qs
link suggests that the majority come from embedded devices.
This is much too often just "generate a key on the first boot" -
enough said.


On 18.02.2012 17:02, Edward Ned Harvey wrote:

> When I make a backup copy of ~/.rnd, and generate some keys,
> and then restore ~/.rnd and re-generate the keys...  My keys
> come out different. Which suggests either (a) It's not
> actually using my ~/.rnd file as the random seed, or
> (b) It's using ~/.rnd in conjunction with something else
> such as urandom.

I interpret http://www.openssl.org/support/faq.cgi#USER1
such that the /dev/urandom is always used if present and
the RNG used is additionally seeded by RANDFILE. So your
keys are different, but if the available entropy in
/dev/urandom was insufficient, they will be not as random
as you'd wish.

This thread has some information
http://www.mail-archive.com/openssl-users@.../msg54172.html
and seems to back it:

   This internal PRNG is seeded from different sources. These
   external sources can be provided explicitly (as with the
   "-rand" option of genrsa) or via RAND_add() within
   an application. As on several occasions people were given
   bad advice to abuse "-rand" or RAND_add() with bad entropy
   sources we have decided to always add additional bytes
   from /dev/urandom if available on the system.

> so I can be assured (and assure my boss and shareholders) that
> I have truly random generated keys when I generate them using
> openssl.

Use a hardware based on true random physical process.
This one is quite low-cost: http://www.entropykey.co.uk/
(no experience, I just googled for what is available).

If not practical, seed your RANDFILE with /dev/random
data before generating keys.

--
                                          Stano
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: understanding openssl entropy

Edward Ned Harvey (openssl)
In reply to this post by David Jacobson-3
> From: David Jacobson [mailto:[hidden email]]
> Sent: Saturday, February 18, 2012 5:15 PM
>
> You will see that /dev/urandom does get real entropy, and, as I said,
> entropy is saved across shutdown and reboot, so that even right after
> boot (assuming that the file is secure), the entropy is good.

Yes, I know urandom has real entropy fed into it based on the availability
of real entropy.  Yes I know it saves state during reboots, so it is strong
even after reboots.  However...

The most obvious situation where it doesn't have sufficient entropy is
during *first* boot.  You know, when your system generated your ssh keys.
Fortunately that problem is easy to solve, and it is unrelated to openssl.
Fixed as follows:  export SSH_USE_STRONG_RNG=256 ; sudo ssh-keygen -q -C ""
-N "" -t dsa -f /etc/ssh/ssh_host_dsa_key ; sudo ssh-keygen -q -C "" -N ""
-t rsa -f /etc/ssh/ssh_host_rsa_key ; sudo ssh-keygen -q -C "" -N "" -t rsa1
-f /etc/ssh/ssh_host_key

The second most obvious situation is as you said, VM's starting from the
same initial state.

Granted, when most people use openssl to generate keys, the system has
generally been on a long time and generally has accumulated plenty of
entropy.  But how do you know when your system has been on long enough to
safely generate your keys?  It's probably within the first few minutes after
first boot, but how do you know?  And of course it's going to be different
from OS to OS.  People want to know *at least* one way they can be assured
they have sufficient entropy to generate their keys safely.  And after
answering this question a single time, it is worth extending to other OSes,
such as windows.  (I know I have certainly used openssl inside of cygwin to
generate keys, and I have absolutely no idea what cygwin randomness is based
on.)

Based on what's happening out there now, there are a lot of people scared
that they've not been diligent enough to ensure sufficient entropy.  This is
easy to fix.

I am not interested in debating the pros/cons of urandom versus random.  I
am interested in coming up with a simple easy-to-follow solution that people
can use to systematically ensure they have sufficient entropy.

My best idea so far is cat /dev/random > ~/.rnd  (and wait until it's 1k
long).  This takes about 8 minutes on my system, and after that, you are
assured you always have strong entropy.  But as described in my previous
email, there is some reason for me to doubt whether this is achieving the
end result I'm trying to achieve.

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: understanding openssl entropy

Edward Ned Harvey (openssl)
In reply to this post by Stanislav Meduna
> From: [hidden email] [mailto:owner-openssl-
> [hidden email]] On Behalf Of Stanislav Meduna
>
> I interpret http://www.openssl.org/support/faq.cgi#USER1
> such that the /dev/urandom is always used if present and
> the RNG used is additionally seeded by RANDFILE. So your
> keys are different, but if the available entropy in
> /dev/urandom was insufficient, they will be not as random
> as you'd wish.

I would be ok with urandom, as long as I know I've got a really random seed.


>    This internal PRNG is seeded from different sources. These
>    external sources can be provided explicitly (as with the
>    "-rand" option of genrsa) or via RAND_add() within
>    an application. As on several occasions people were given
>    bad advice to abuse "-rand" or RAND_add() with bad entropy
>    sources we have decided to always add additional bytes
>    from /dev/urandom if available on the system.

YES!
I think that counts as an answer.  Thank you.  :-)
So here is what I'm taking to be the final answer:
* First, md5sum your ~/.rnd file (or read your config file to see what's
specified by RANDFILE).
* Then generate a key, and md5sum your ~/.rnd again.  Ensure it's changed.
This ensures you know where your entropy seed is stored, and you haven't
accidentally set the wrong RANDFILE or read the wrong config file or
anything like that.
* cat /dev/random > ~/.rnd   (and wait for it to reach 1k or longer)  This
takes 8-10 minutes on a system with low entropy.

From now on, you may safely assume you have sufficient entropy.  Although
the "random" numbers are coming from /dev/urandom, you have a really random
seed, which makes it sufficiently random.


> Use a hardware based on true random physical process.
> This one is quite low-cost: http://www.entropykey.co.uk/
> (no experience, I just googled for what is available).

Most systems nowadays have a TPM built-in, which can be used as a hardware
entropy source.  Unfortunately, not available in most VM's.

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]