Re: [Openvpn-devel] [PATCH 1/6] Added support for new PolarSSL 1.1 RNG

2012-04-28 Thread Gert Doering 
Hi,

On Sat, Apr 28, 2012 at 12:20:45AM +0200, David Sommerseth wrote:
> This is a summary of all the 6 applied patches.  All patches were applied to
> the master branch and pushed out to -stable and -testing trees.

JFTR, the FreeBSD 9.0 buildslave now has PolarSSL 1.1.2 installed, and 
building with it worked fine.  So thanks for that :-)

Right now I'm installing PolarSSL on the other *BSD buildslaves, and then
we should be back to "all green" regarding the buildbot setup \o/

Next thing: add client tests with both OpenSSL and PolarSSL...

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


pgp2AlSCfQyL_.pgp
Description: PGP signature

Re: [Openvpn-devel] [PATCH 1/6] Added support for new PolarSSL 1.1 RNG

2012-04-27 Thread David Sommerseth 

This is a summary of all the 6 applied patches.  All patches were applied to
the master branch and pushed out to -stable and -testing trees.


commit 4b87c868333e6aca5cb78bc345059e61c72b9423
Author: Adriaan de Jong 
List-Post: openvpn-devel@lists.sourceforge.net
Date:   Mon Apr 2 09:28:06 2012 +0200

Removed stray "Fox-IT hardening" string.

Signed-off-by: Adriaan de Jong 
Acked-by: David Sommerseth 
Message-Id: 151687-3732-5-git-send-email-dej...@fox-it.com
URL: http://article.gmane.org/gmane.network.openvpn.devel/6212
Signed-off-by: David Sommerseth 

commit 34091048af1ba94e8bf2049354610d16f8bb3d4c
Author: Adriaan de Jong 
List-Post: openvpn-devel@lists.sourceforge.net
Date:   Mon Apr 2 09:28:07 2012 +0200

Updated README.polarssl with build system changes.

Signed-off-by: Adriaan de Jong 
Acked-by: David Sommerseth 
Message-Id: 151687-3732-6-git-send-email-dej...@fox-it.com
URL: http://article.gmane.org/gmane.network.openvpn.devel/6209
Signed-off-by: David Sommerseth 

 README.polarssl |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

commit 1d92d06dca5ac38990261cb546a766b91fc53f9b
Author: Adriaan de Jong 
List-Post: openvpn-devel@lists.sourceforge.net
Date:   Mon Apr 2 09:28:05 2012 +0200

Removed support for PolarSSL < 1.1

PolarSSL 1.0 and earlier use only the Havege RNG. Havege is based on timing
certain operations, using the RDTSC instruction. Although this is fine on
bare metal PCs, the RDTSC instruction is virtualised on some virtual
machine implementations. This can result in issues on those virtual
machines. PolarSSL fixes this potential issue by also using platform
entropy.

To ensure that OpenVPN is always built against a decent RNG, PolarSSL <1.1
is therefore no longer supported.

Signed-off-by: Adriaan de Jong 
Acked-by: David Sommerseth 
Message-Id: 151687-3732-4-git-send-email-dej...@fox-it.com
URL: http://article.gmane.org/gmane.network.openvpn.devel/6211
Signed-off-by: David Sommerseth 

 src/openvpn/crypto_polarssl.c |   34 --
 src/openvpn/crypto_polarssl.h |   13 +
 src/openvpn/ssl_polarssl.c|6 --
 src/openvpn/syshead.h |3 ---
 4 files changed, 1 insertions(+), 55 deletions(-)

commit 21fdfb73d5d18038872da15cd15026f40666b4d5
Author: Adriaan de Jong 
List-Post: openvpn-devel@lists.sourceforge.net
Date:   Mon Apr 2 09:28:04 2012 +0200

Use POLARSSL_CFLAGS instead of POLARSSL_CRYPTO_CFLAGS in configure.ac

Ensured that the used variable name actually matches the one advertised by 
configure.

Signed-off-by: Adriaan de Jong 
Acked-by: Alon Bar-Lev 
Message-Id: 151687-3732-3-git-send-email-dej...@fox-it.com
URL: http://article.gmane.org/gmane.network.openvpn.devel/6208
Signed-off-by: David Sommerseth 

 configure.ac |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

commit 0f25d2969f09ba4263dc37944e1f10405a2df461
Author: Adriaan de Jong 
List-Post: openvpn-devel@lists.sourceforge.net
Date:   Mon Apr 2 09:28:03 2012 +0200

Added a configuration option to enable prediction resistance in the 
PolarSSL random number generator.

Signed-off-by: Eelse-jan Stutvoet 
Signed-off-by: Adriaan de Jong 
Acked-by: James Yonan 
Message-Id: 151687-3732-2-git-send-email-dej...@fox-it.com
URL: http://article.gmane.org/gmane.network.openvpn.devel/6213
Signed-off-by: David Sommerseth 

Notes:
This patch was ACKed by James Yonan in an IRC meeting March 29, 2012.

Currently, the meeting minutes have not been made public.

(David Sommerseth, Fri Apr 27 21:36:04 UTC 2012)

 doc/openvpn.8 |   14 ++
 src/openvpn/crypto_polarssl.c |9 +
 src/openvpn/crypto_polarssl.h |7 +++
 src/openvpn/init.c|6 ++
 src/openvpn/options.c |   22 ++
 src/openvpn/options.h |3 +++
 src/openvpn/syshead.h |8 
 7 files changed, 69 insertions(+), 0 deletions(-)

commit 6efeaa2e4462bc10f395d8aceed363c3e77b35a3
Author: Adriaan de Jong 
List-Post: openvpn-devel@lists.sourceforge.net
Date:   Mon Apr 2 09:28:02 2012 +0200

Added support for new PolarSSL 1.1 RNG

This patch, while retaining PolarSSL 1.0 support, introduces the PolarSSL 
1.1 DRBG.
This RNG adds a number of features, including support for personalisation 
strings
and multiple entropy sources.

Re: [Openvpn-devel] [PATCH 1/6] Added support for new PolarSSL 1.1 RNG

2012-04-10 Thread Seth Mos 

Op 6-4-2012 19:55, Gert Doering schreef:

Hi,

On Mon, Apr 02, 2012 at 07:31:56PM +0200, Adriaan de Jong wrote:

I don't see the need to further delay 2.3 for this, as it is not
a bug fix. Others might disagree here, and the topic is open for
debate :). In general, it might be a good idea to freeze development
of 2.3 at some point to prevent endless alpha syndrome.


I'm with Adriaan on this.  I want 2.3 *out*, and *soon* - people are
waiting for an OpenVPN release with IPv6 support.


*Seth from the pfSense project raises his hand.

We currently ship pfSense 2.0 and 2.1 with a one off patched install 
that is basically 2.2 with patches from Gert and jjo.


If all goes well we hope to have pfSense 2.1 in Beta next month in time 
for World IPv6 day. Really hoping we can ship with something newer then 
2.2+patches. Although it does appear to be holding up so far.


The release of OpenVPN 2.3 is critical, because the state of the clients 
so far has been poor. Only the native clients works, and neither 
Viscosity or Tunnelblick currently works. (in tun mode).


Regards,

Seth

Re: [Openvpn-devel] [PATCH 1/6] Added support for new PolarSSL 1.1 RNG

2012-04-06 Thread Gert Doering 
Hi,

On Mon, Apr 02, 2012 at 11:22:47PM +0200, David Sommerseth wrote:
> It would be good to have a beta release out before the summer and an
> RC release during the autumn.  Aiming for a 2.3 release towards the
> end of the year.  

Uh.  Just to point out that I thought that was the plan, but with 
"end of 2011" as "end of the year", and we postponed that to "release
at fosdem", or so.

So this would make me highly unhappy.  Aiming for "2.3 release in summer"
would be good.  People are *waiting* for the IPv6 stuff.

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


pgpm7CF7RcIdG.pgp
Description: PGP signature

Re: [Openvpn-devel] [PATCH 1/6] Added support for new PolarSSL 1.1 RNG

2012-04-06 Thread Gert Doering 
Hi,

On Mon, Apr 02, 2012 at 09:50:55PM +0300, Alon Bar-Lev wrote:
> Well, I don't care about version numbers... they are just snapshots in time.

"Release Version" is what end-users will see and use, and if we care at
all for the nice things we've added to OpenVPN, it's important to get them
released.

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


pgpzZGFspD6mR.pgp
Description: PGP signature

Re: [Openvpn-devel] [PATCH 1/6] Added support for new PolarSSL 1.1 RNG

2012-04-06 Thread Gert Doering 
Hi,

On Mon, Apr 02, 2012 at 07:31:56PM +0200, Adriaan de Jong wrote:
> I don't see the need to further delay 2.3 for this, as it is not
> a bug fix. Others might disagree here, and the topic is open for
> debate :). In general, it might be a good idea to freeze development
> of 2.3 at some point to prevent endless alpha syndrome.

I'm with Adriaan on this.  I want 2.3 *out*, and *soon* - people are 
waiting for an OpenVPN release with IPv6 support.

(There *is* lots of more work to be done, but there will always be a release
after 2.3 - and with more reasonable release cycles, 2.4 will be here
before we could otherwise reach a "everything in!" 2.3...)

I'm not commenting on the PolarSSL patches, because I don't feel confident
in ACKing or NACKing crypto stuff - "it looks reasonable to me", but that's
more a half-feature-ACK than anything else.  But besides this, I think it's
time to tag -alpha2, give this a good beating, and then figure out what
we think is missing *and can be achieved in reasonable time* for 2.3-beta1.

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


pgpn2u7DepE8N.pgp
Description: PGP signature

Re: [Openvpn-devel] [PATCH 1/6] Added support for new PolarSSL 1.1 RNG

2012-04-05 Thread Samuli Seppänen 
Il 03.04.2012 00:22, David Sommerseth ha scritto:
> On 02/04/12 20:50, Alon Bar-Lev wrote:
> > On Mon, Apr 2, 2012 at 8:31 PM, Adriaan de Jong <dej...@fox-it.com>
> > wrote:
> >>> -Original Message- From: Alon Bar-Lev
> >>> [mailto:alon.bar...@gmail.com] Sent: maandag 2 april 2012
> >>> 12:42 To: David Sommerseth Cc:
> >>> openvpn-devel@lists.sourceforge.net Subject: Re:
> >>> [Openvpn-devel] [PATCH 1/6] Added support for new PolarSSL 1.1
> >>> RNG
> >>>
> >>> On Mon, Apr 2, 2012 at 1:39 PM, David Sommerseth
> >>> <openvpn.l...@topphemmelig.net> wrote:
> >>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
> >>>>
> >>>> On 02/04/12 12:25, Alon Bar-Lev wrote:
> >>>>> No no no I did not imply that this will be dynamic
> >>>>> interface. Nor that there is a use case.
> >>>>>
> >>>>> The current state of the code (even before the merge of
> >>>>> polarssl)
> >>> was
> >>>>> very complex. Now it is even more complex, with none
> >>>>> clean/strict separation between the common crypto code and
> >>>>> the library specific crypto code... Yes, I know these
> >>>>> resides in different sources, but
> >>> it
> >>>>> is more similar to what we call "spaghetti" programming.
> >>>>>
> >>>>> What I suggest of doing is to create static callback
> >>>>> structure which is the interface of crypto library used by
> >>>>> openvpn. This is *STATIC* linkage.
> >>>>>
> >>>>> For example: typedef struct { result_t (*x509_get_username)
> >>>>> (char *cn, int cn_len, char *x509_username_field, x509_cert
> >>>>> *cert) ... } openvpn_crypto_enigne_t;
> >>>>>
> >>>>> I guess you understand how this struct will look like.
> >>>>>
> >>>>> Now, a nice side effect would be the ability to have both
> >>>>> libraries linked against openvpn, while choosing the engine
> >>>>> at
> >>> configuration...
> >>>>> Of course there is no real world use for this, except for
> >>>>> build (one build checks both libraries) and test (we can
> >>>>> use test one build for both).
> >>>>>
> >>>>> The main mission is to clean up the code, reducing the
> >>>>> complexity, making sure we can follow each crypto call to
> >>>>> either common, crypto-library-atom, or openvpn specific.
> >>>>>
> >>>>> Is that more clear?
> >>>>
> >>>> Ahh, yeah!  That makes more sense.
> >>>>
> >>>> But I just need to be sure we're having the right focus.  Are
> >>>> we getting done with the autotools clean-up?  If not, what's
> >>>> missing?  I see more and more clean-up patches touching the C
> >>>> code now, so I just want to be sure we're basically done with
> >>>> autotools.  Otherwise, getting rid of syshead.h is probably
> >>>> one of the next bigger steps.
> >>>
> >>> Right. Next stage is getting rid of syshead.h... The following
> >>> is to cleanup the crypto, I though that if someone can work on
> >>> this in parallel we will do this twice as fast :)
> >>>
> >>> But before we continue we need to stabilize the project again,
> >>> creating the missing repositories, deciding about the
> >>> github/sourceforge is needed. Deciding about the way to review
> >>> and merge large changes.
> >>>
> >>
> >> I'd prefer to leave further modularisation for 2.4. We could even
> >> make that a more general goal for 2.4, modularising not just
> >> crypto/SSL, but also authentication, and maybe even some of the
> >> network stuff. It would be nice to leave a few targets for 2.4
> >> :).
> >>
> >> I don't see the need to further delay 2.3 for this, as it is not
> >> a bug fix. Others might disagree here, and the topic is open for
> >> debate :). In general, it might be a good idea to freeze
> >> development of 2.3 at some point to prevent endless alpha
> >> syndrome.
> >>
> >> Adriaan
> >>
>
> > Well, I don't care about version numbers... they are just snapshots
> > in time.

Re: [Openvpn-devel] [PATCH 1/6] Added support for new PolarSSL 1.1 RNG

2012-04-03 Thread Adriaan de Jong 


> -Original Message-
> From: David Sommerseth [mailto:openvpn.l...@topphemmelig.net]
> On 02/04/12 20:50, Alon Bar-Lev wrote:
> > On Mon, Apr 2, 2012 at 8:31 PM, Adriaan de Jong 
> > wrote:
> >>> -Original Message- From: Alon Bar-Lev
> >>> [mailto:alon.bar...@gmail.com] Sent: maandag 2 april 2012
> >>> 12:42 To: David Sommerseth Cc:

...

> >>>
> >>> Right. Next stage is getting rid of syshead.h... The following is
> to
> >>> cleanup the crypto, I though that if someone can work on this in
> >>> parallel we will do this twice as fast :)
> >>>
> >>> But before we continue we need to stabilize the project again,
> >>> creating the missing repositories, deciding about the
> >>> github/sourceforge is needed. Deciding about the way to review and
> >>> merge large changes.
> >>>
> >>
> >> I'd prefer to leave further modularisation for 2.4. We could even
> >> make that a more general goal for 2.4, modularising not just
> >> crypto/SSL, but also authentication, and maybe even some of the
> >> network stuff. It would be nice to leave a few targets for 2.4 :).
> >>
> >> I don't see the need to further delay 2.3 for this, as it is not a
> >> bug fix. Others might disagree here, and the topic is open for
> debate
> >> :). In general, it might be a good idea to freeze development of 2.3
> >> at some point to prevent endless alpha syndrome.
> >>
> >> Adriaan
> >>
> >
> > Well, I don't care about version numbers... they are just snapshots
> in
> > time. We need a branch with this one way or the other... If that
> > branch is good, it can enter the next version whatever it may be...
> 
> Adriaan got a good point, and we've kind of settled on the features
> we've kicked into the coming 2.3 release.  I hope that we can push out
> an alpha-2 release when things have begun to stabilise on master again.
> 
> It would be good to have a beta release out before the summer and an RC
> release during the autumn.  Aiming for a 2.3 release towards the end of
> the year.  This is not a plan carved into stone, and if we're able to
> move faster; I'd appreciate that very much.  But this is the general
> idea which has been discussed/suggested a couple of times on IRC.
> However, I'm trying to be realistic as well.  So there's room for 2-3
> releases in each stage before the final release.  And we'll see how
> many we end up with in the end.
> 
> But I agree that additional features we don't want into 2.3 could go
> into the experimental branch in openvpn-testing.git.  That's mostly a
> copy of 'master' (I've been lazy to update it lately, but pushed out an
> update again now), that's the purpose of this branch.
> 

Perhaps it's time to determine a freezing point for OpenVPN 2.3? Let's say 
after the new build system is in, but before any further modularisation?

Adriaan

Re: [Openvpn-devel] [PATCH 1/6] Added support for new PolarSSL 1.1 RNG

2012-04-02 Thread David Sommerseth 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/04/12 20:50, Alon Bar-Lev wrote:
> On Mon, Apr 2, 2012 at 8:31 PM, Adriaan de Jong <dej...@fox-it.com>
> wrote:
>>> -Original Message- From: Alon Bar-Lev
>>> [mailto:alon.bar...@gmail.com] Sent: maandag 2 april 2012
>>> 12:42 To: David Sommerseth Cc:
>>> openvpn-devel@lists.sourceforge.net Subject: Re:
>>> [Openvpn-devel] [PATCH 1/6] Added support for new PolarSSL 1.1
>>> RNG
>>> 
>>> On Mon, Apr 2, 2012 at 1:39 PM, David Sommerseth 
>>> <openvpn.l...@topphemmelig.net> wrote:
>>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>>> 
>>>> On 02/04/12 12:25, Alon Bar-Lev wrote:
>>>>> No no no I did not imply that this will be dynamic
>>>>> interface. Nor that there is a use case.
>>>>> 
>>>>> The current state of the code (even before the merge of
>>>>> polarssl)
>>> was
>>>>> very complex. Now it is even more complex, with none
>>>>> clean/strict separation between the common crypto code and
>>>>> the library specific crypto code... Yes, I know these
>>>>> resides in different sources, but
>>> it
>>>>> is more similar to what we call "spaghetti" programming.
>>>>> 
>>>>> What I suggest of doing is to create static callback
>>>>> structure which is the interface of crypto library used by
>>>>> openvpn. This is *STATIC* linkage.
>>>>> 
>>>>> For example: typedef struct { result_t (*x509_get_username)
>>>>> (char *cn, int cn_len, char *x509_username_field, x509_cert
>>>>> *cert) ... } openvpn_crypto_enigne_t;
>>>>> 
>>>>> I guess you understand how this struct will look like.
>>>>> 
>>>>> Now, a nice side effect would be the ability to have both
>>>>> libraries linked against openvpn, while choosing the engine
>>>>> at
>>> configuration...
>>>>> Of course there is no real world use for this, except for
>>>>> build (one build checks both libraries) and test (we can
>>>>> use test one build for both).
>>>>> 
>>>>> The main mission is to clean up the code, reducing the
>>>>> complexity, making sure we can follow each crypto call to
>>>>> either common, crypto-library-atom, or openvpn specific.
>>>>> 
>>>>> Is that more clear?
>>>> 
>>>> Ahh, yeah!  That makes more sense.
>>>> 
>>>> But I just need to be sure we're having the right focus.  Are
>>>> we getting done with the autotools clean-up?  If not, what's
>>>> missing?  I see more and more clean-up patches touching the C
>>>> code now, so I just want to be sure we're basically done with
>>>> autotools.  Otherwise, getting rid of syshead.h is probably
>>>> one of the next bigger steps.
>>> 
>>> Right. Next stage is getting rid of syshead.h... The following
>>> is to cleanup the crypto, I though that if someone can work on
>>> this in parallel we will do this twice as fast :)
>>> 
>>> But before we continue we need to stabilize the project again,
>>> creating the missing repositories, deciding about the
>>> github/sourceforge is needed. Deciding about the way to review
>>> and merge large changes.
>>> 
>> 
>> I'd prefer to leave further modularisation for 2.4. We could even
>> make that a more general goal for 2.4, modularising not just
>> crypto/SSL, but also authentication, and maybe even some of the
>> network stuff. It would be nice to leave a few targets for 2.4
>> :).
>> 
>> I don't see the need to further delay 2.3 for this, as it is not
>> a bug fix. Others might disagree here, and the topic is open for
>> debate :). In general, it might be a good idea to freeze
>> development of 2.3 at some point to prevent endless alpha
>> syndrome.
>> 
>> Adriaan
>> 
> 
> Well, I don't care about version numbers... they are just snapshots
> in time. We need a branch with this one way or the other... If that
> branch is good, it can enter the next version whatever it may
> be...

Adriaan got a good point, and we've kind of settled on the features
we've kicked into the coming 2.3 release.  I hope that we can push out
an alpha-2 release when things have begun to stabilise on master again.

It would be good to have a beta release out

Re: [Openvpn-devel] [PATCH 1/6] Added support for new PolarSSL 1.1 RNG

2012-04-02 Thread Alon Bar-Lev 
On Mon, Apr 2, 2012 at 8:31 PM, Adriaan de Jong <dej...@fox-it.com> wrote:
>> -Original Message-
>> From: Alon Bar-Lev [mailto:alon.bar...@gmail.com]
>> Sent: maandag 2 april 2012 12:42
>> To: David Sommerseth
>> Cc: openvpn-devel@lists.sourceforge.net
>> Subject: Re: [Openvpn-devel] [PATCH 1/6] Added support for new PolarSSL
>> 1.1 RNG
>>
>> On Mon, Apr 2, 2012 at 1:39 PM, David Sommerseth
>> <openvpn.l...@topphemmelig.net> wrote:
>> > -BEGIN PGP SIGNED MESSAGE-
>> > Hash: SHA1
>> >
>> > On 02/04/12 12:25, Alon Bar-Lev wrote:
>> >> No no no I did not imply that this will be dynamic interface.
>> >> Nor that there is a use case.
>> >>
>> >> The current state of the code (even before the merge of polarssl)
>> was
>> >> very complex. Now it is even more complex, with none clean/strict
>> >> separation between the common crypto code and the library specific
>> >> crypto code... Yes, I know these resides in different sources, but
>> it
>> >> is more similar to what we call "spaghetti" programming.
>> >>
>> >> What I suggest of doing is to create static callback structure which
>> >> is the interface of crypto library used by openvpn. This is
>> >> *STATIC* linkage.
>> >>
>> >> For example: typedef struct { result_t (*x509_get_username) (char
>> >> *cn, int cn_len, char *x509_username_field, x509_cert *cert) ... }
>> >> openvpn_crypto_enigne_t;
>> >>
>> >> I guess you understand how this struct will look like.
>> >>
>> >> Now, a nice side effect would be the ability to have both libraries
>> >> linked against openvpn, while choosing the engine at
>> configuration...
>> >> Of course there is no real world use for this, except for build (one
>> >> build checks both libraries) and test (we can use test one build for
>> >> both).
>> >>
>> >> The main mission is to clean up the code, reducing the complexity,
>> >> making sure we can follow each crypto call to either common,
>> >> crypto-library-atom, or openvpn specific.
>> >>
>> >> Is that more clear?
>> >
>> > Ahh, yeah!  That makes more sense.
>> >
>> > But I just need to be sure we're having the right focus.  Are we
>> > getting done with the autotools clean-up?  If not, what's missing?  I
>> > see more and more clean-up patches touching the C code now, so I just
>> > want to be sure we're basically done with autotools.  Otherwise,
>> > getting rid of syshead.h is probably one of the next bigger steps.
>>
>> Right.
>> Next stage is getting rid of syshead.h... The following is to cleanup
>> the crypto, I though that if someone can work on this in parallel we
>> will do this twice as fast :)
>>
>> But before we continue we need to stabilize the project again, creating
>> the missing repositories, deciding about the github/sourceforge is
>> needed. Deciding about the way to review and merge large changes.
>>
>
> I'd prefer to leave further modularisation for 2.4. We could even make that a 
> more general goal for 2.4, modularising not just crypto/SSL, but also 
> authentication, and maybe even some of the network stuff. It would be nice to 
> leave a few targets for 2.4 :).
>
> I don't see the need to further delay 2.3 for this, as it is not a bug fix. 
> Others might disagree here, and the topic is open for debate :). In general, 
> it might be a good idea to freeze development of 2.3 at some point to prevent 
> endless alpha syndrome.
>
> Adriaan
>

Well, I don't care about version numbers... they are just snapshots in time.
We need a branch with this one way or the other... If that branch is
good, it can enter the next version whatever it may be...

Alon.

Re: [Openvpn-devel] [PATCH 1/6] Added support for new PolarSSL 1.1 RNG

2012-04-02 Thread Adriaan de Jong 
> -Original Message-
> From: Alon Bar-Lev [mailto:alon.bar...@gmail.com]
> Sent: maandag 2 april 2012 12:42
> To: David Sommerseth
> Cc: openvpn-devel@lists.sourceforge.net
> Subject: Re: [Openvpn-devel] [PATCH 1/6] Added support for new PolarSSL
> 1.1 RNG
> 
> On Mon, Apr 2, 2012 at 1:39 PM, David Sommerseth
> <openvpn.l...@topphemmelig.net> wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > On 02/04/12 12:25, Alon Bar-Lev wrote:
> >> No no no I did not imply that this will be dynamic interface.
> >> Nor that there is a use case.
> >>
> >> The current state of the code (even before the merge of polarssl)
> was
> >> very complex. Now it is even more complex, with none clean/strict
> >> separation between the common crypto code and the library specific
> >> crypto code... Yes, I know these resides in different sources, but
> it
> >> is more similar to what we call "spaghetti" programming.
> >>
> >> What I suggest of doing is to create static callback structure which
> >> is the interface of crypto library used by openvpn. This is
> >> *STATIC* linkage.
> >>
> >> For example: typedef struct { result_t (*x509_get_username) (char
> >> *cn, int cn_len, char *x509_username_field, x509_cert *cert) ... }
> >> openvpn_crypto_enigne_t;
> >>
> >> I guess you understand how this struct will look like.
> >>
> >> Now, a nice side effect would be the ability to have both libraries
> >> linked against openvpn, while choosing the engine at
> configuration...
> >> Of course there is no real world use for this, except for build (one
> >> build checks both libraries) and test (we can use test one build for
> >> both).
> >>
> >> The main mission is to clean up the code, reducing the complexity,
> >> making sure we can follow each crypto call to either common,
> >> crypto-library-atom, or openvpn specific.
> >>
> >> Is that more clear?
> >
> > Ahh, yeah!  That makes more sense.
> >
> > But I just need to be sure we're having the right focus.  Are we
> > getting done with the autotools clean-up?  If not, what's missing?  I
> > see more and more clean-up patches touching the C code now, so I just
> > want to be sure we're basically done with autotools.  Otherwise,
> > getting rid of syshead.h is probably one of the next bigger steps.
> 
> Right.
> Next stage is getting rid of syshead.h... The following is to cleanup
> the crypto, I though that if someone can work on this in parallel we
> will do this twice as fast :)
> 
> But before we continue we need to stabilize the project again, creating
> the missing repositories, deciding about the github/sourceforge is
> needed. Deciding about the way to review and merge large changes.
> 

I'd prefer to leave further modularisation for 2.4. We could even make that a 
more general goal for 2.4, modularising not just crypto/SSL, but also 
authentication, and maybe even some of the network stuff. It would be nice to 
leave a few targets for 2.4 :).

I don't see the need to further delay 2.3 for this, as it is not a bug fix. 
Others might disagree here, and the topic is open for debate :). In general, it 
might be a good idea to freeze development of 2.3 at some point to prevent 
endless alpha syndrome.

Adriaan

Re: [Openvpn-devel] [PATCH 1/6] Added support for new PolarSSL 1.1 RNG

2012-04-02 Thread David Sommerseth 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/04/12 12:25, Alon Bar-Lev wrote:
> No no no I did not imply that this will be dynamic interface. 
> Nor that there is a use case.
> 
> The current state of the code (even before the merge of polarssl)
> was very complex. Now it is even more complex, with none
> clean/strict separation between the common crypto code and the
> library specific crypto code... Yes, I know these resides in
> different sources, but it is more similar to what we call
> "spaghetti" programming.
> 
> What I suggest of doing is to create static callback structure
> which is the interface of crypto library used by openvpn. This is
> *STATIC* linkage.
> 
> For example: typedef struct { result_t (*x509_get_username) (char
> *cn, int cn_len, char *x509_username_field, x509_cert *cert) ... }
> openvpn_crypto_enigne_t;
> 
> I guess you understand how this struct will look like.
> 
> Now, a nice side effect would be the ability to have both
> libraries linked against openvpn, while choosing the engine at
> configuration... Of course there is no real world use for this,
> except for build (one build checks both libraries) and test (we can
> use test one build for both).
> 
> The main mission is to clean up the code, reducing the complexity, 
> making sure we can follow each crypto call to either common, 
> crypto-library-atom, or openvpn specific.
> 
> Is that more clear?

Ahh, yeah!  That makes more sense.

But I just need to be sure we're having the right focus.  Are we
getting done with the autotools clean-up?  If not, what's missing?  I
see more and more clean-up patches touching the C code now, so I just
want to be sure we're basically done with autotools.  Otherwise,
getting rid of syshead.h is probably one of the next bigger steps.


kind regards,

David Sommerseth



-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk95gcAACgkQDC186MBRfrqXTACfVmxUC2Yy0SLxxJnRadxSz2U6
h+8An1S6QRrDpH7oWB6zsqmFvzeBoAcJ
=u0Jh
-END PGP SIGNATURE-

Re: [Openvpn-devel] [PATCH 1/6] Added support for new PolarSSL 1.1 RNG

2012-04-02 Thread David Sommerseth 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/04/12 11:55, Fabian Knittel wrote:


The only advantage I see at runtime switching, is that it's easier for
distributors to support both SSL/crypto library platforms.  Except of
that, I don't see much benefits of it.

And f.ex. in the use case of OpenVPN-NL, I doubt this will be
considered interesting at all, as they do static linking against the
SSL/crypt libraries - to ensure that the libraries Fox-IT have
reviewed and certified for governmental usage are used, and not a
potentially compromised or weakened third-party library.

To be very honest, I don't think it's worth the effort of adding
dynamic loading of SSL/crypto libraries at run time.  Having it at
compile-time provides the needed flexibility.  Yes, distribution can
benefit from it, but is that burden so big we need to modify OpenVPN
for it?  Let's rather stay cool now and rather discuss and consider
such a move for OpenVPN 2.4.  Then we will know more what distributors
thing about it.


kind regards,

David Sommerseth
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk95elcACgkQDC186MBRfrqJWQCgo1obHw0suslCzzJ0Yz74JyvG
EeIAnArJVfrE9eG4PozBxCfIYlkP3BDo
=bPiA
-END PGP SIGNATURE-

Re: [Openvpn-devel] [PATCH 1/6] Added support for new PolarSSL 1.1 RNG

2012-04-02 Thread David Sommerseth 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/04/12 11:55, Fabian Knittel wrote:
> Hi Alon,
> 
> 2012/4/2 Alon Bar-Lev :
>> I also intend to work and cleanup the whole PolarSSL/OpenSSL 
>> mess...
>> 
>> Design will be to introduce crypto engine callback structure, 
>> registering openssl and polarssl, in a way that code is using
>> the callback structure while using runtime configuration one can
>>  select which engine to use (if both are available).
> 
> What would be the use-case for switching crypto libraries at 
> runtime? Would this be an important step towards the OpenVPN 3.0 
> concept? (Otherwise this sounds like quite a bit of work and 
> potentially more processing overhead...)

The only advantage I see at runtime switching, is that it's easier for
distributors to support both SSL/crypto library platforms.  Except of
that, I don't see much benefits of it.

And f.ex. in the use case of OpenVPN-NL, I doubt this will be
considered interesting at all, as they do static linking against the
SSL/crypt libraries - to ensure that the libraries Fox-IT have
reviewed and certified for governmental usage are used, and not a
potentially compromised or weakened third-party library.

To be very honest, I don't think it's worth the effort of adding
dynamic loading of SSL/crypto libraries at run time.  Having it at
compile-time provides the needed flexibility.  Yes, distribution can
benefit from it, but is that burden so big we need to modify OpenVPN
for it?  Let's rather stay cool now and rather discuss and consider
such a move for OpenVPN 2.4.  Then we will know more what distributors
thing about it.


kind regards,

David Sommerseth
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk95emAACgkQDC186MBRfrqdJACdHeabhSc1PBWO4kgholprGneY
J70An1zG5DyOXWM3nRrkLh7FI72NNua/
=SJw7
-END PGP SIGNATURE-

Re: [Openvpn-devel] [PATCH 1/6] Added support for new PolarSSL 1.1 RNG

2012-04-02 Thread David Sommerseth 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/04/12 11:55, Fabian Knittel wrote:


The only advantage I see at runtime switching, is that it's easier for
distributors to support both SSL/crypto library platforms.  Except of
that, I don't see much benefits of it.

And f.ex. in the use case of OpenVPN-NL, I doubt this will be
considered interesting at all, as they do static linking against the
SSL/crypt libraries - to ensure that the libraries Fox-IT have
reviewed and certified for governmental usage are used, and not a
potentially compromised or weakened third-party library.

To be very honest, I don't think it's worth the effort of adding
dynamic loading of SSL/crypto libraries at run time.  Having it at
compile-time provides the needed flexibility.  Yes, distribution can
benefit from it, but is that burden so big we need to modify OpenVPN
for it?  Let's rather stay cool now and rather discuss and consider
such a move for OpenVPN 2.4.  Then we will know more what distributors
thing about it.


kind regards,

David Sommerseth
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk95emAACgkQDC186MBRfrrIxwCcCRTtF7rfmVnAnB3LwQQRImS/
o2IAn2dCvRMGXgakKqKlVCdZ4EedUNWB
=tUDJ
-END PGP SIGNATURE-

Re: [Openvpn-devel] [PATCH 1/6] Added support for new PolarSSL 1.1 RNG

2012-04-02 Thread David Sommerseth 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/04/12 11:55, Fabian Knittel wrote:


The only advantage I see at runtime switching, is that it's easier for
distributors to support both SSL/crypto library platforms.  Except of
that, I don't see much benefits of it.

And f.ex. in the use case of OpenVPN-NL, I doubt this will be
considered interesting at all, as they do static linking against the
SSL/crypt libraries - to ensure that the libraries Fox-IT have
reviewed and certified for governmental usage are used, and not a
potentially compromised or weakened third-party library.

To be very honest, I don't think it's worth the effort of adding
dynamic loading of SSL/crypto libraries at run time.  Having it at
compile-time provides the needed flexibility.  Yes, distribution can
benefit from it, but is that burden so big we need to modify OpenVPN
for it?  Let's rather stay cool now and rather discuss and consider
such a move for OpenVPN 2.4.  Then we will know more what distributors
thing about it.


kind regards,

David Sommerseth
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk95el4ACgkQDC186MBRfrq+FQCghLkCxKyMxiERcbYeChKmtmKu
WyIAn3t51ek+uM68tEPij5dO89GpRWHO
=HQCn
-END PGP SIGNATURE-

Re: [Openvpn-devel] [PATCH 1/6] Added support for new PolarSSL 1.1 RNG

2012-04-02 Thread David Sommerseth 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/04/12 11:55, Fabian Knittel wrote:


The only advantage I see at runtime switching, is that it's easier for
distributors to support both SSL/crypto library platforms.  Except of
that, I don't see much benefits of it.

And f.ex. in the use case of OpenVPN-NL, I doubt this will be
considered interesting at all, as they do static linking against the
SSL/crypt libraries - to ensure that the libraries Fox-IT have
reviewed and certified for governmental usage are used, and not a
potentially compromised or weakened third-party library.

To be very honest, I don't think it's worth the effort of adding
dynamic loading of SSL/crypto libraries at run time.  Having it at
compile-time provides the needed flexibility.  Yes, distribution can
benefit from it, but is that burden so big we need to modify OpenVPN
for it?  Let's rather stay cool now and rather discuss and consider
such a move for OpenVPN 2.4.  Then we will know more what distributors
thing about it.


kind regards,

David Sommerseth
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk95elsACgkQDC186MBRfrpVfACdEJgl6vYDeGH3DxL1foYET118
u5gAn2mA6Zy5TIhtqYnV8qCP2XTJiyyr
=K25q
-END PGP SIGNATURE-

Re: [Openvpn-devel] [PATCH 1/6] Added support for new PolarSSL 1.1 RNG

2012-04-02 Thread Fabian Knittel 
Hi Alon,

2012/4/2 Alon Bar-Lev :
> I also intend to work and cleanup the whole PolarSSL/OpenSSL mess...
>
> Design will be to introduce crypto engine callback structure,
> registering openssl and polarssl, in a way that code is using the
> callback structure while using runtime configuration one can select
> which engine to use (if both are available).

What would be the use-case for switching crypto libraries at runtime?
Would this be an important step towards the OpenVPN 3.0 concept?
(Otherwise this sounds like quite a bit of work and potentially more
processing overhead...)

Cheers
Fabian

Re: [Openvpn-devel] [PATCH 1/6] Added support for new PolarSSL 1.1 RNG

2012-04-02 Thread Alon Bar-Lev 
Hello Adriaan,

I don't think that PolarSSL is so popular that we need to support
complex backward compatibility.

Supporting PolarSSL-1.1 should be sufficient, we can make the
configure script verify this minimum.

I also intend to work and cleanup the whole PolarSSL/OpenSSL mess...

Design will be to introduce crypto engine callback structure,
registering openssl and polarssl, in a way that code is using the
callback structure while using runtime configuration one can select
which engine to use (if both are available).

Are you interested in helping me? I have other major cleanups to do as well.

Alon.

On Mon, Apr 2, 2012 at 10:28 AM, Adriaan de Jong  wrote:
>
> This patch, while retaining PolarSSL 1.0 support, introduces the PolarSSL
> 1.1 DRBG. This RNG adds a number of features, including support for
> personalisation strings and multiple entropy sources.
>
> Personalisation strings have been implemented, based on PID, program name,
> place within memory, and a hash of the user's certificate.
>
> The entropy sources used are the platform default ones. Which ones these
> are depends on how PolarSSL was built, but usually this includes:
>
>  - /dev/urandom or the Windows CryptoAPI RNG
>  - the HAVEGE RNG
>  - the output of PolarSSL's hardclock() call (usually RDTSC)
>
> Finally, this patch moves to only one instance of the RNG  per OpenVPN
> instance, instead of one per keystate
>
> Signed-off-by: Adriaan de Jong 
> Signed-off-by: Eelse-jan Stutvoet 
> ---
>  src/openvpn/crypto_polarssl.c |   84
> -
>  src/openvpn/crypto_polarssl.h |   25 
>  src/openvpn/ssl.c             |    5 ++
>  src/openvpn/ssl_backend.h     |   10 +
>  src/openvpn/ssl_polarssl.c    |   44 -
>  src/openvpn/ssl_polarssl.h    |    2 -
>  6 files changed, 148 insertions(+), 22 deletions(-)
>
> diff --git a/src/openvpn/crypto_polarssl.c b/src/openvpn/crypto_polarssl.c
> index 0e6728c..158ccfc 100644
> --- a/src/openvpn/crypto_polarssl.c
> +++ b/src/openvpn/crypto_polarssl.c
> @@ -42,12 +42,18 @@
>  #include "buffer.h"
>  #include "integer.h"
>  #include "crypto_backend.h"
> +#include "otime.h"
> +#include "misc.h"
>
>  #include 
>  #include 
>  #include 
>  #include 
>
> +#if (POLARSSL_VERSION_NUMBER >= 0x0101)
> +#include 
> +#endif
> +
>  /*
>  *
>  * Hardware engine support. Allows loading/unloading of engines.
> @@ -149,7 +155,6 @@ show_available_engines ()
>       "available\n");
>  }
>
> -
>  /*
>  *
>  * Random number functions, used in cases where we want
> @@ -159,29 +164,88 @@ show_available_engines ()
>  *
>  */
>
> -int
> -rand_bytes (uint8_t *output, int len)
> +/*
> + * Initialise the given ctr_drbg context, using a personalisation string
> and an
> + * entropy gathering function.
> + */
> +#if (POLARSSL_VERSION_NUMBER >= 0x0101)
> +ctr_drbg_context * rand_ctx_get()
> +{
> +  static entropy_context ec = {0};
> +  static ctr_drbg_context cd_ctx = {0};
> +  static bool rand_initialised = false;
> +
> +  if (!rand_initialised)
> +    {
> +      struct gc_arena gc = gc_new();
> +      struct buffer pers_string = alloc_buf_gc(100, );
> +
> +      /*
> +       * Personalisation string, should be as unique as possible (see
> NIST
> +       * 800-90 section 8.7.1). We have very little information at this
> stage.
> +       * Include Program Name, memory address of the context and PID.
> +       */
> +      buf_printf(_string, "OpenVPN %0u %p %s", platform_getpid(),
> _ctx, time_string(0, 0, 0, ));
> +
> +      /* Initialise PolarSSL RNG, and built-in entropy sources */
> +      entropy_init();
> +
> +      if (0 != ctr_drbg_init(_ctx, entropy_func, ,
> BPTR(_string), BLEN(_string)))
> +        msg (M_FATAL, "Failed to initialize random generator");
> +
> +      gc_free();
> +      rand_initialised = true;
> +  }
> +
> +  return _ctx;
> +}
> +
> +#else /* (POLARSSL_VERSION_NUMBER < 0x0101) */
> +
> +havege_state * rand_ctx_get()
>  {
>   static havege_state hs = {0};
> -  static bool hs_initialised = false;
> -  const int int_size = sizeof(int);
> +  static bool rand_initialised = false;
>
> -  if (!hs_initialised)
> +  if (!rand_initialised)
>     {
>       /* Initialise PolarSSL RNG */
>       havege_init();
> -      hs_initialised = true;
> +      rand_initialised = true;
>     }
>
> +  return 
> +}
> +
> +#endif /* (POLARSSL_VERSION_NUMBER >= 0x0101) */
> +
> +int
> +rand_bytes (uint8_t *output, int len)
> +{
> +#if (POLARSSL_VERSION_NUMBER >= 0x0101)
> +  ctr_drbg_context *rng_ctx = rand_ctx_get();
> +#else /* (POLARSSL_VERSION_NUMBER >= 0x0101) */
> +  havege_state *rng_ctx = rand_ctx_get();
> +#endif /* (POLARSSL_VERSION_NUMBER >= 0x0101) */
> +
>   while (len > 0)
>     {
> -      const int blen   = min_int (len, int_size);
> -      const int rand_int       = havege_rand();
> -
> +#if (POLARSSL_VERSION_NUMBER >= 0x0101)
> +      const size_t blen = min_int

[Openvpn-devel] [PATCH 1/6] Added support for new PolarSSL 1.1 RNG

2012-04-02 Thread Adriaan de Jong 
This patch, while retaining PolarSSL 1.0 support, introduces the PolarSSL 1.1 
DRBG. This RNG adds a number of features, including support for personalisation 
strings and multiple entropy sources.

Personalisation strings have been implemented, based on PID, program name, 
place within memory, and a hash of the user's certificate.

The entropy sources used are the platform default ones. Which ones these are 
depends on how PolarSSL was built, but usually this includes:

 - /dev/urandom or the Windows CryptoAPI RNG
 - the HAVEGE RNG
 - the output of PolarSSL's hardclock() call (usually RDTSC)

Finally, this patch moves to only one instance of the RNG  per OpenVPN 
instance, instead of one per keystate

Signed-off-by: Adriaan de Jong 
Signed-off-by: Eelse-jan Stutvoet 
---
 src/openvpn/crypto_polarssl.c |   84 -
 src/openvpn/crypto_polarssl.h |   25 
 src/openvpn/ssl.c |5 ++
 src/openvpn/ssl_backend.h |   10 +
 src/openvpn/ssl_polarssl.c|   44 -
 src/openvpn/ssl_polarssl.h|2 -
 6 files changed, 148 insertions(+), 22 deletions(-)

diff --git a/src/openvpn/crypto_polarssl.c b/src/openvpn/crypto_polarssl.c
index 0e6728c..158ccfc 100644
--- a/src/openvpn/crypto_polarssl.c
+++ b/src/openvpn/crypto_polarssl.c
@@ -42,12 +42,18 @@
 #include "buffer.h"
 #include "integer.h"
 #include "crypto_backend.h"
+#include "otime.h"
+#include "misc.h"

 #include 
 #include 
 #include 
 #include 

+#if (POLARSSL_VERSION_NUMBER >= 0x0101)
+#include 
+#endif
+
 /*
  *
  * Hardware engine support. Allows loading/unloading of engines.
@@ -149,7 +155,6 @@ show_available_engines ()
   "available\n");
 }

-
 /*
  *
  * Random number functions, used in cases where we want
@@ -159,29 +164,88 @@ show_available_engines ()
  *
  */

-int
-rand_bytes (uint8_t *output, int len)
+/*
+ * Initialise the given ctr_drbg context, using a personalisation string and an
+ * entropy gathering function.
+ */
+#if (POLARSSL_VERSION_NUMBER >= 0x0101)
+ctr_drbg_context * rand_ctx_get()
+{
+  static entropy_context ec = {0};
+  static ctr_drbg_context cd_ctx = {0};
+  static bool rand_initialised = false;
+
+  if (!rand_initialised)
+{
+  struct gc_arena gc = gc_new();
+  struct buffer pers_string = alloc_buf_gc(100, );
+
+  /*
+   * Personalisation string, should be as unique as possible (see NIST
+   * 800-90 section 8.7.1). We have very little information at this stage.
+   * Include Program Name, memory address of the context and PID.
+   */
+  buf_printf(_string, "OpenVPN %0u %p %s", platform_getpid(), 
_ctx, time_string(0, 0, 0, ));
+
+  /* Initialise PolarSSL RNG, and built-in entropy sources */
+  entropy_init();
+
+  if (0 != ctr_drbg_init(_ctx, entropy_func, , BPTR(_string), 
BLEN(_string)))
+msg (M_FATAL, "Failed to initialize random generator");
+
+  gc_free();
+  rand_initialised = true;
+  }
+
+  return _ctx;
+}
+
+#else /* (POLARSSL_VERSION_NUMBER < 0x0101) */
+
+havege_state * rand_ctx_get()
 {
   static havege_state hs = {0};
-  static bool hs_initialised = false;
-  const int int_size = sizeof(int);
+  static bool rand_initialised = false;

-  if (!hs_initialised)
+  if (!rand_initialised)
 {
   /* Initialise PolarSSL RNG */
   havege_init();
-  hs_initialised = true;
+  rand_initialised = true;
 }

+  return 
+}
+
+#endif /* (POLARSSL_VERSION_NUMBER >= 0x0101) */
+
+int
+rand_bytes (uint8_t *output, int len)
+{
+#if (POLARSSL_VERSION_NUMBER >= 0x0101)
+  ctr_drbg_context *rng_ctx = rand_ctx_get();
+#else /* (POLARSSL_VERSION_NUMBER >= 0x0101) */
+  havege_state *rng_ctx = rand_ctx_get();
+#endif /* (POLARSSL_VERSION_NUMBER >= 0x0101) */
+
   while (len > 0)
 {
-  const int blen   = min_int (len, int_size);
-  const int rand_int   = havege_rand();
-
+#if (POLARSSL_VERSION_NUMBER >= 0x0101)
+  const size_t blen = min_int (len, CTR_DRBG_MAX_REQUEST);
+  if (0 != ctr_drbg_random(rng_ctx, output, blen))
+   return 0;
+
+#else /* (POLARSSL_VERSION_NUMBER >= 0x0101) */
+  const size_t blen = min_int (len, sizeof(int));
+  const int rand_int = havege_rand(rng_ctx);
   memcpy (output, _int, blen);
+
+#endif /* (POLARSSL_VERSION_NUMBER >= 0x0101) */
+
   output += blen;
   len -= blen;
 }
+
   return 1;
 }

diff --git a/src/openvpn/crypto_polarssl.h b/src/openvpn/crypto_polarssl.h
index 358483a..2f303db 100644
--- a/src/openvpn/crypto_polarssl.h
+++ b/src/openvpn/crypto_polarssl.h
@@ -30,9 +30,16 @@
 #ifndef CRYPTO_POLARSSL_H_
 #define CRYPTO_POLARSSL_H_

+#include 
 #include 
 #include 

+#if (POLARSSL_VERSION_NUMBER >= 0x0101)
+#  include 
+#else
+#  include 
+#endif
+
 /** Generic cipher key type %context. */
 typedef cipher_info_t cipher_kt_t;

@@ -71,4 +78,22 @@ typedef md_context_t hmac_ctx_t;
 #define