Added support for new PolarSSL 1.1 RNG

Signed-off-by Eelse-jan Stutvoet <[email protected]...>

Signed-off-by Adriaan de Jong <[email protected]...>

---
 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(-)

doc/openvpn.8 +0 -0

index 53d6bdb..ee46de6 100644
@@ -3846,6 +3846,20 @@ space-saving optimization that uses the unique identifier for

 datagram replay protection as the IV. .\"********************************************************* .TP
+.B \-\-use-prediction-resistance

doc/openvpn.8 +13 -0

+Enable prediction resistance on PolarSSL's RNG.
+
+Enabling prediction resistance causes the RNG to reseed in each
+call for random. Reseeding this often can quickly deplete the kernel
+entropy pool.
+
+If you need this option, please consider running a daemon that adds
+entropy to the kernel pool.
+
+Note that this option only works with PolarSSL versions greater
+than 1.1.
+.\"*********************************************************
+.TP

 .B \-\-test-crypto
 Do a self-test of OpenVPN's crypto options by encrypting and decrypting test packets using the data channel encryption options

src/openvpn/crypto_polarssl.c +9 -0

index 158ccfc..96d41b7 100644
@@ -219,6 +219,15 @@ havege_state * rand_ctx_get()
 
  #endif /* (POLARSSL_VERSION_NUMBER >= 0x01010000) */
 
+#ifdef ENABLE_PREDICTION_RESISTANCE
+void rand_ctx_enable_prediction_resistance()
+{
+  ctr_drbg_context *cd_ctx = rand_ctx_get();
+
+  ctr_drbg_set_prediction_resistance(cd_ctx, 1);
+}
+#endif /* ENABLE_PREDICTION_RESISTANCE */
+

 int
 rand_bytes (uint8_t *output, int len)
 {

src/openvpn/crypto_polarssl.h +7 -0

index 2f303db..6152878 100644
@@ -96,4 +96,11 @@ ctr_drbg_context * rand_ctx_get();
  havege_state * rand_ctx_get();
  #endif
 
+#ifdef ENABLE_PREDICTION_RESISTANCE
+/**
+ * Enable prediction resistance on the random number generator.
+ */
+void rand_ctx_enable_prediction_resistance();
+#endif
+
  #endif /* CRYPTO_POLARSSL_H_ */

src/openvpn/init.c +6 -0

index bc7718e..05a07fa 100644
@@ -2008,6 +2008,12 @@ init_crypto_pre (struct context *c, const unsigned int flags)
 
   if (c->options.mute_replay_warnings)
     c->c2.crypto_options.flags |= CO_MUTE_REPLAY_WARNINGS;
+
+#ifdef ENABLE_PREDICTION_RESISTANCE
+  if (c->options.use_prediction_resistance)
+    rand_ctx_enable_prediction_resistance();
+#endif
+
  }
 
  /*

src/openvpn/options.c +0 -0

index bd83843..5b52ed0 100644
@@ -545,6 +545,10 @@ static const char usage_message[] =

  "                  using file.\n"
  "--test-crypto   : Run a self-test of crypto features enabled.\n" "                  For debugging only.\n"

src/openvpn/options.c +4 -0

+#ifdef ENABLE_PREDICTION_RESISTANCE
+  "--use-prediction-resistance: Enable prediction resistance on the random\n"
+  "                             number generator.\n"
+#endif

 #ifdef ENABLE_SSL
  "\n"
  "TLS Key Negotiation Options:\n"

src/openvpn/options.c +18 -0

@@ -837,6 +841,9 @@ init_options (struct options *o, const bool init_gc)
   o->replay_time = DEFAULT_TIME_BACKTRACK;
   o->use_iv = true;
   o->key_direction = KEY_DIRECTION_BIDIRECTIONAL;
+#ifdef ENABLE_PREDICTION_RESISTANCE
+  o->use_prediction_resistance = false;
+#endif
  #ifdef ENABLE_SSL
   o->key_method = 2;
   o->tls_timeout = 2;

@@ -1581,6 +1588,9 @@ show_settings (const struct options *o)
   SHOW_STR (packet_id_file);
   SHOW_BOOL (use_iv);
   SHOW_BOOL (test_crypto);
+#ifdef ENABLE_PREDICTION_RESISTANCE
+  SHOW_BOOL (use_prediction_resistance);
+#endif
 
  #ifdef ENABLE_SSL
   SHOW_BOOL (tls_server);

@@ -3018,6 +3028,11 @@ options_string (const struct options *o,
          buf_printf (&out, ",no-replay");
        if (!o->use_iv)
          buf_printf (&out, ",no-iv");
+
+#ifdef ENABLE_PREDICTION_RESISTANCE
+        if (o->use_prediction_resistance)
+          buf_printf (&out, ",use-prediction-resistance");
+#endif
       }
 
  #ifdef ENABLE_SSL

@@ -6416,6 +6431,13 @@ add_option (struct options *options,
       options->keysize = keysize;
     }
  #endif
+#ifdef ENABLE_PREDICTION_RESISTANCE
+  else if (streq (p[0], "use-prediction-resistance"))
+    {
+      VERIFY_PERMISSION (OPT_P_GENERAL);
+      options->use_prediction_resistance = true;
+    }
+#endif
  #ifdef ENABLE_SSL
   else if (streq (p[0], "show-tls"))
     {

src/openvpn/options.h +3 -0

index 9e78d00..1be3dfa 100644
@@ -520,6 +520,9 @@ struct options
   const char *packet_id_file;
   bool use_iv;
   bool test_crypto;
+#ifdef ENABLE_PREDICTION_RESISTANCE
+  bool use_prediction_resistance;
+#endif
 
  #ifdef ENABLE_SSL
   /* TLS (control channel) parms */

src/openvpn/syshead.h +8 -1

index e60dc44..b14d50d 100644
@@ -534,6 +534,14 @@ socket_defined (const socket_descriptor_t sd)
  #define MANAGMENT_EXTERNAL_KEY
  #endif
 
+/* Enable PolarSSL RNG prediction resistance support */
+#ifdef ENABLE_CRYPTO_POLARSSL
+#include <polarssl/version.h>
+#if POLARSSL_VERSION_NUMBER >= 0x01010000
+#define ENABLE_PREDICTION_RESISTANCE
+#endif
+#endif /* ENABLE_CRYPTO_POLARSSL */
+
  /*
  * MANAGEMENT_IN_EXTRA allows the management interface to
  * read multi-line inputs from clients.
--

1.7.5.4

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Openvpn-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

-----Original Message-----
From: Alon Bar-Lev [mailto:[email protected]...]
Sent: maandag 2 april 2012 11:19
To: Adriaan de Jong
Cc: [email protected]
Subject: Re: [Openvpn-devel] [PATCH 2/6] Added a configuration option to enable prediction resistance in the PolarSSL random number generator.

Hello,
I think that we should not have these options specific to one crypto library.
Alon.

Quoted 96 lines · Adriaan de Jong

Signed-off-by Eelse-jan Stutvoet <[email protected]...>

Signed-off-by Adriaan de Jong <[email protected]...>

---
 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(-)

doc/openvpn.8 index 53d6bdb..ee46de6 renamed from doc/openvpn.8 +0 -0

100644

doc/openvpn.8 +0 -0

@@ -3846,6 +3846,20 @@ space-saving optimization that uses the unique

identifier for
 datagram replay protection as the IV. .\"********************************************************* .TP
+.B \-\-use-prediction-resistance

doc/openvpn.8 +13 -0

+Enable prediction resistance on PolarSSL's RNG.
+
+Enabling prediction resistance causes the RNG to reseed in each call
+for random. Reseeding this often can quickly deplete the kernel
+entropy pool.
+
+If you need this option, please consider running a daemon that adds
+entropy to the kernel pool.
+
+Note that this option only works with PolarSSL versions greater than
+1.1.
+.\"*********************************************************
+.TP

 .B \-\-test-crypto
 Do a self-test of OpenVPN's crypto options by encrypting and decrypting test packets using the data channel encryption options

(quoted diff) +0 -0

b/src/openvpn/crypto_polarssl.c index 158ccfc..96d41b7 100644

src/openvpn/crypto_polarssl.c +8 -0

@@ -219,6 +219,15 @@ havege_state * rand_ctx_get()
 
  #endif /* (POLARSSL_VERSION_NUMBER >= 0x01010000) */
 
+#ifdef ENABLE_PREDICTION_RESISTANCE
+void rand_ctx_enable_prediction_resistance()
+{
+  ctr_drbg_context *cd_ctx = rand_ctx_get();
+
+  ctr_drbg_set_prediction_resistance(cd_ctx, 1); } #endif /*
+ENABLE_PREDICTION_RESISTANCE */
+

 int
 rand_bytes (uint8_t *output, int len)
 {

(quoted diff) +0 -0

b/src/openvpn/crypto_polarssl.h index 2f303db..6152878 100644

src/openvpn/crypto_polarssl.h +7 -0

@@ -96,4 +96,11 @@ ctr_drbg_context * rand_ctx_get();
  havege_state * rand_ctx_get();
  #endif
 
+#ifdef ENABLE_PREDICTION_RESISTANCE
+/**
+ * Enable prediction resistance on the random number generator.
+ */
+void rand_ctx_enable_prediction_resistance();
+#endif
+
  #endif /* CRYPTO_POLARSSL_H_ */

src/openvpn/init.c index renamed from src/openvpn/init.c +0 -0

bc7718e..05a07fa 100644

src/openvpn/init.c +6 -0

@@ -2008,6 +2008,12 @@ init_crypto_pre (struct context *c, const
 unsigned int flags)
 
   if (c->options.mute_replay_warnings)
     c->c2.crypto_options.flags |= CO_MUTE_REPLAY_WARNINGS;
+
+#ifdef ENABLE_PREDICTION_RESISTANCE
+  if (c->options.use_prediction_resistance)
+    rand_ctx_enable_prediction_resistance();
+#endif
+
  }
 

 /*

src/openvpn/options.c index renamed from src/openvpn/options.c +0 -0

bd83843..5b52ed0 100644

src/openvpn/options.c +0 -0

@@ -545,6 +545,10 @@ static const char usage_message[] =

Quoted 5 lines

  "                  using file.\n"
  "--test-crypto   : Run a self-test of crypto features enabled.\n" "                  For debugging only.\n"
+#ifdef ENABLE_PREDICTION_RESISTANCE
+  "--use-prediction-resistance: Enable prediction resistance on the

random\n"

Quoted 84 lines

+  "                             number generator.\n" +#endif
 #ifdef ENABLE_SSL
  "\n"
  "TLS Key Negotiation Options:\n"

src/openvpn/options.c +2 -0

@@ -837,6 +841,9 @@ init_options (struct options *o, const bool
 init_gc)
   o->replay_time = DEFAULT_TIME_BACKTRACK;
   o->use_iv = true;
   o->key_direction = KEY_DIRECTION_BIDIRECTIONAL;
+#ifdef ENABLE_PREDICTION_RESISTANCE
+  o->use_prediction_resistance = false; #endif
  #ifdef ENABLE_SSL
   o->key_method = 2;

  o->tls_timeout = 2;

src/openvpn/options.c +13 -0

@@ -1581,6 +1588,9 @@ show_settings (const struct options *o)
   SHOW_STR (packet_id_file);
   SHOW_BOOL (use_iv);
   SHOW_BOOL (test_crypto);
+#ifdef ENABLE_PREDICTION_RESISTANCE
+  SHOW_BOOL (use_prediction_resistance); #endif
 
  #ifdef ENABLE_SSL
   SHOW_BOOL (tls_server);

@@ -3018,6 +3028,11 @@ options_string (const struct options *o,
          buf_printf (&out, ",no-replay");
        if (!o->use_iv)
          buf_printf (&out, ",no-iv");
+
+#ifdef ENABLE_PREDICTION_RESISTANCE
+        if (o->use_prediction_resistance)
+          buf_printf (&out, ",use-prediction-resistance"); #endif
       }
 
  #ifdef ENABLE_SSL

@@ -6416,6 +6431,13 @@ add_option (struct options *options,
       options->keysize = keysize;
     }
  #endif
+#ifdef ENABLE_PREDICTION_RESISTANCE
+  else if (streq (p[0], "use-prediction-resistance"))
+    {
+      VERIFY_PERMISSION (OPT_P_GENERAL);
+      options->use_prediction_resistance = true;
+    }
+#endif
  #ifdef ENABLE_SSL
   else if (streq (p[0], "show-tls"))
     {

src/openvpn/options.h index renamed from src/openvpn/options.h +0 -0

9e78d00..1be3dfa 100644

src/openvpn/options.h +3 -0

@@ -520,6 +520,9 @@ struct options
   const char *packet_id_file;
   bool use_iv;
   bool test_crypto;
+#ifdef ENABLE_PREDICTION_RESISTANCE
+  bool use_prediction_resistance;
+#endif
 
  #ifdef ENABLE_SSL
   /* TLS (control channel) parms */

src/openvpn/syshead.h index renamed from src/openvpn/syshead.h +0 -0

e60dc44..b14d50d 100644

src/openvpn/syshead.h +6 -1

@@ -534,6 +534,14 @@ socket_defined (const socket_descriptor_t sd)
  #define MANAGMENT_EXTERNAL_KEY
  #endif
 
+/* Enable PolarSSL RNG prediction resistance support */ #ifdef
+ENABLE_CRYPTO_POLARSSL #include <polarssl/version.h> #if
+POLARSSL_VERSION_NUMBER >= 0x01010000 #define
+ENABLE_PREDICTION_RESISTANCE #endif #endif /* ENABLE_CRYPTO_POLARSSL
+*/
+
  /*
  * MANAGEMENT_IN_EXTRA allows the management interface to
  * read multi-line inputs from clients.
--

1.7.5.4

Quoted 1 line

---------------------------------------------------------------------

-

Quoted 8 lines

--------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Openvpn-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Prediction resistance is a useful feature to have in some circles. It's definitely an option that's useful for OpenVPN-NL, which is why I ported it to the mainline. If there is no interest, could we include it in a contrib directory or something along those lines?

Adriaan

Quoted 212 lines

-----Original Message-----
From: Alon Bar-Lev [mailto:[email protected]...]
Sent: maandag 2 april 2012 11:19
To: Adriaan de Jong
Cc: [email protected]
Subject: Re: [Openvpn-devel] [PATCH 2/6] Added a configuration option to enable prediction resistance in the PolarSSL random number generator.

Hello,
I think that we should not have these options specific to one crypto library.
Alon.

Quoted 96 lines · Adriaan de Jong

Signed-off-by Eelse-jan Stutvoet <[email protected]...>

Signed-off-by Adriaan de Jong <[email protected]...>

---
 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(-)

doc/openvpn.8 index 53d6bdb..ee46de6 renamed from doc/openvpn.8 +0 -0

100644

doc/openvpn.8 +0 -0

@@ -3846,6 +3846,20 @@ space-saving optimization that uses the unique

identifier for
 datagram replay protection as the IV. .\"********************************************************* .TP
+.B \-\-use-prediction-resistance

doc/openvpn.8 +13 -0

+Enable prediction resistance on PolarSSL's RNG.
+
+Enabling prediction resistance causes the RNG to reseed in each call
+for random. Reseeding this often can quickly deplete the kernel
+entropy pool.
+
+If you need this option, please consider running a daemon that adds
+entropy to the kernel pool.
+
+Note that this option only works with PolarSSL versions greater than
+1.1.
+.\"*********************************************************
+.TP

 .B \-\-test-crypto
 Do a self-test of OpenVPN's crypto options by encrypting and decrypting test packets using the data channel encryption options

(quoted diff) +0 -0

b/src/openvpn/crypto_polarssl.c index 158ccfc..96d41b7 100644

src/openvpn/crypto_polarssl.c +8 -0

@@ -219,6 +219,15 @@ havege_state * rand_ctx_get()
 
  #endif /* (POLARSSL_VERSION_NUMBER >= 0x01010000) */
 
+#ifdef ENABLE_PREDICTION_RESISTANCE
+void rand_ctx_enable_prediction_resistance()
+{
+  ctr_drbg_context *cd_ctx = rand_ctx_get();
+
+  ctr_drbg_set_prediction_resistance(cd_ctx, 1); } #endif /*
+ENABLE_PREDICTION_RESISTANCE */
+

 int
 rand_bytes (uint8_t *output, int len)
 {

(quoted diff) +0 -0

b/src/openvpn/crypto_polarssl.h index 2f303db..6152878 100644

src/openvpn/crypto_polarssl.h +7 -0

@@ -96,4 +96,11 @@ ctr_drbg_context * rand_ctx_get();
  havege_state * rand_ctx_get();
  #endif
 
+#ifdef ENABLE_PREDICTION_RESISTANCE
+/**
+ * Enable prediction resistance on the random number generator.
+ */
+void rand_ctx_enable_prediction_resistance();
+#endif
+
  #endif /* CRYPTO_POLARSSL_H_ */

src/openvpn/init.c index renamed from src/openvpn/init.c +0 -0

bc7718e..05a07fa 100644

src/openvpn/init.c +6 -0

@@ -2008,6 +2008,12 @@ init_crypto_pre (struct context *c, const
 unsigned int flags)
 
   if (c->options.mute_replay_warnings)
     c->c2.crypto_options.flags |= CO_MUTE_REPLAY_WARNINGS;
+
+#ifdef ENABLE_PREDICTION_RESISTANCE
+  if (c->options.use_prediction_resistance)
+    rand_ctx_enable_prediction_resistance();
+#endif
+
  }
 

 /*

src/openvpn/options.c index renamed from src/openvpn/options.c +0 -0

bd83843..5b52ed0 100644

src/openvpn/options.c +0 -0

@@ -545,6 +545,10 @@ static const char usage_message[] =

Quoted 5 lines

  "                  using file.\n"
  "--test-crypto   : Run a self-test of crypto features enabled.\n" "                  For debugging only.\n"
+#ifdef ENABLE_PREDICTION_RESISTANCE
+  "--use-prediction-resistance: Enable prediction resistance on the

random\n"

Quoted 84 lines

+  "                             number generator.\n" +#endif
 #ifdef ENABLE_SSL
  "\n"
  "TLS Key Negotiation Options:\n"

src/openvpn/options.c +2 -0

@@ -837,6 +841,9 @@ init_options (struct options *o, const bool
 init_gc)
   o->replay_time = DEFAULT_TIME_BACKTRACK;
   o->use_iv = true;
   o->key_direction = KEY_DIRECTION_BIDIRECTIONAL;
+#ifdef ENABLE_PREDICTION_RESISTANCE
+  o->use_prediction_resistance = false; #endif
  #ifdef ENABLE_SSL
   o->key_method = 2;

  o->tls_timeout = 2;

src/openvpn/options.c +13 -0

@@ -1581,6 +1588,9 @@ show_settings (const struct options *o)
   SHOW_STR (packet_id_file);
   SHOW_BOOL (use_iv);
   SHOW_BOOL (test_crypto);
+#ifdef ENABLE_PREDICTION_RESISTANCE
+  SHOW_BOOL (use_prediction_resistance); #endif
 
  #ifdef ENABLE_SSL
   SHOW_BOOL (tls_server);

@@ -3018,6 +3028,11 @@ options_string (const struct options *o,
          buf_printf (&out, ",no-replay");
        if (!o->use_iv)
          buf_printf (&out, ",no-iv");
+
+#ifdef ENABLE_PREDICTION_RESISTANCE
+        if (o->use_prediction_resistance)
+          buf_printf (&out, ",use-prediction-resistance"); #endif
       }
 
  #ifdef ENABLE_SSL

@@ -6416,6 +6431,13 @@ add_option (struct options *options,
       options->keysize = keysize;
     }
  #endif
+#ifdef ENABLE_PREDICTION_RESISTANCE
+  else if (streq (p[0], "use-prediction-resistance"))
+    {
+      VERIFY_PERMISSION (OPT_P_GENERAL);
+      options->use_prediction_resistance = true;
+    }
+#endif
  #ifdef ENABLE_SSL
   else if (streq (p[0], "show-tls"))
     {

src/openvpn/options.h index renamed from src/openvpn/options.h +0 -0

9e78d00..1be3dfa 100644

src/openvpn/options.h +3 -0

@@ -520,6 +520,9 @@ struct options
   const char *packet_id_file;
   bool use_iv;
   bool test_crypto;
+#ifdef ENABLE_PREDICTION_RESISTANCE
+  bool use_prediction_resistance;
+#endif
 
  #ifdef ENABLE_SSL
   /* TLS (control channel) parms */

src/openvpn/syshead.h index renamed from src/openvpn/syshead.h +0 -0

e60dc44..b14d50d 100644

src/openvpn/syshead.h +6 -1

@@ -534,6 +534,14 @@ socket_defined (const socket_descriptor_t sd)
  #define MANAGMENT_EXTERNAL_KEY
  #endif
 
+/* Enable PolarSSL RNG prediction resistance support */ #ifdef
+ENABLE_CRYPTO_POLARSSL #include <polarssl/version.h> #if
+POLARSSL_VERSION_NUMBER >= 0x01010000 #define
+ENABLE_PREDICTION_RESISTANCE #endif #endif /* ENABLE_CRYPTO_POLARSSL
+*/
+
  /*
  * MANAGEMENT_IN_EXTRA allows the management interface to
  * read multi-line inputs from clients.
--

1.7.5.4

Quoted 1 line

---------------------------------------------------------------------

-

Quoted 8 lines

--------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Openvpn-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

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

Signed-off-by Adriaan de Jong <[email protected]...>

---
 configure.ac |    2 +-

 1 files changed, 1 insertions(+), 1 deletions(-)

configure.ac +0 -0

index ef34697..70c51e7 100644
@@ -821,7 +821,7 @@ case "${with_crypto_library}" in
        polarssl)

               have_crypto_crypto="${have_polarssl_crypto}" have_crypto_ssl="${have_polarssl_ssl}"
-               CRYPTO_CRYPTO_CFLAGS="${POLARSSL_CRYPTO_CFLAGS}"
+               CRYPTO_CRYPTO_CFLAGS="${POLARSSL_CFLAGS}" CRYPTO_CRYPTO_LIBS="${POLARSSL_LIBS}" AC_DEFINE([ENABLE_CRYPTO_POLARSSL], [1], [Use PolarSSL library]) ;;
--
1.7.5.4

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Openvpn-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

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 <[email protected]...>

---
 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(-)

src/openvpn/crypto_polarssl.c +0 -22

index 96d41b7..3978a3c 100644
@@ -50,9 +50,7 @@
  #include <polarssl/cipher.h>
  #include <polarssl/havege.h>
 
-#if (POLARSSL_VERSION_NUMBER >= 0x01010000)
  #include <polarssl/entropy.h>
-#endif
 
  /*
  *

@@ -168,7 +166,6 @@ show_available_engines ()
  * Initialise the given ctr_drbg context, using a personalisation string and an
  * entropy gathering function.
  */
-#if (POLARSSL_VERSION_NUMBER >= 0x01010000)
  ctr_drbg_context * rand_ctx_get()
  {
   static entropy_context ec = {0};

@@ -200,25 +197,6 @@ ctr_drbg_context * rand_ctx_get()
   return &cd_ctx;
  }
 
-#else /* (POLARSSL_VERSION_NUMBER < 0x01010000) */
-
-havege_state * rand_ctx_get()
-{
-  static havege_state hs = {0};
-  static bool rand_initialised = false;
-
-  if (!rand_initialised)
-    {
-      /* Initialise PolarSSL RNG */
-      havege_init(&hs);
-      rand_initialised = true;
-    }
-
-  return &hs;
-}
-
-#endif /* (POLARSSL_VERSION_NUMBER >= 0x01010000) */
-
  #ifdef ENABLE_PREDICTION_RESISTANCE
  void rand_ctx_enable_prediction_resistance()
  {

@@ -231,26 +209,14 @@ void rand_ctx_enable_prediction_resistance()

 int
 rand_bytes (uint8_t *output, int len)
 {
-#if (POLARSSL_VERSION_NUMBER >= 0x01010000)
  ctr_drbg_context *rng_ctx = rand_ctx_get();

src/openvpn/crypto_polarssl.c +0 -3

-#else /* (POLARSSL_VERSION_NUMBER >= 0x01010000) */
-  havege_state *rng_ctx = rand_ctx_get();
-#endif /* (POLARSSL_VERSION_NUMBER >= 0x01010000) */

  while (len > 0)
    {
-#if (POLARSSL_VERSION_NUMBER >= 0x01010000)
      const size_t blen = min_int (len, CTR_DRBG_MAX_REQUEST); if (0 != ctr_drbg_random(rng_ctx, output, blen)) return 0;

src/openvpn/crypto_polarssl.c +0 -7

-#else /* (POLARSSL_VERSION_NUMBER >= 0x01010000) */
-      const size_t blen = min_int (len, sizeof(int));
-      const int rand_int = havege_rand(rng_ctx);
-      memcpy (output, &rand_int, blen);
-
-#endif /* (POLARSSL_VERSION_NUMBER >= 0x01010000) */
-

      output += blen;
      len -= blen;
    }

src/openvpn/crypto_polarssl.h +1 -12

index 6152878..bfabb91 100644
@@ -33,12 +33,7 @@
  #include <polarssl/version.h>
  #include <polarssl/cipher.h>
  #include <polarssl/md.h>
-
-#if (POLARSSL_VERSION_NUMBER >= 0x01010000)
-#  include <polarssl/ctr_drbg.h>
-#else
-#  include <polarssl/havege.h>
-#endif
+#include <polarssl/ctr_drbg.h>
 
  /** Generic cipher key type %context. */
  typedef cipher_info_t cipher_kt_t;

@@ -81,8 +76,6 @@ typedef md_context_t hmac_ctx_t;
  /**
  * Returns a singleton instance of the PolarSSL random number generator.
  *
- * For PolarSSL 1.0, this is the HAVEGE random number generator.
- *
  * For PolarSSL 1.1+, this is the CTR_DRBG random number generator. If it
  * hasn't been initialised yet, the RNG will be initialised using the default
  * entropy sources. Aside from the default platform entropy sources, an

@@ -90,11 +83,7 @@ typedef md_context_t hmac_ctx_t;
  * added. During initialisation, a personalisation string will be added based
  * on the time, the PID, and a pointer to the random context.
  */
-#if (POLARSSL_VERSION_NUMBER >= 0x01010000)
  ctr_drbg_context * rand_ctx_get();
-#else
-havege_state * rand_ctx_get();
-#endif
 
  #ifdef ENABLE_PREDICTION_RESISTANCE
  /**

src/openvpn/ssl_polarssl.c +0 -6

index 8f35608..fc8fa6e 100644
@@ -503,7 +503,6 @@ static void my_debug( void *ctx, int level, const char *str )
  */
  void tls_ctx_personalise_random(struct tls_root_ctx *ctx)
  {
-#if (POLARSSL_VERSION_NUMBER >= 0x01010000)
   static char old_sha256_hash[32] = {0};
   char sha256_hash[32] = {0};
   ctr_drbg_context *cd_ctx = rand_ctx_get();

@@ -519,7 +518,6 @@ void tls_ctx_personalise_random(struct tls_root_ctx *ctx)
          memcpy(old_sha256_hash, sha256_hash, sizeof(old_sha256_hash));
        }
     }
-#endif /* POLARSSL_VERSION_NUMBER >= 0x01010000 */
  }
 
  void key_state_ssl_init(struct key_state_ssl *ks_ssl,

@@ -536,11 +534,7 @@ void key_state_ssl_init(struct key_state_ssl *ks_ssl,
       ssl_set_dbg (ks_ssl->ctx, my_debug, NULL);
       ssl_set_endpoint (ks_ssl->ctx, ssl_ctx->endpoint);
 
-#if (POLARSSL_VERSION_NUMBER >= 0x01010000)
       ssl_set_rng (ks_ssl->ctx, ctr_drbg_random, rand_ctx_get());
-#else /* POLARSSL_VERSION_NUMBER >= 0x01010000 */
-      ssl_set_rng (ks_ssl->ctx, havege_rand, rand_ctx_get());
-#endif /* POLARSSL_VERSION_NUMBER >= 0x01010000 */
 
       ALLOC_OBJ_CLEAR (ks_ssl->ssn, ssl_session);
       ssl_set_session (ks_ssl->ctx, 0, 0, ks_ssl->ssn );

src/openvpn/syshead.h +0 -4

index b14d50d..79a401b 100644
@@ -536,10 +536,7 @@ socket_defined (const socket_descriptor_t sd)
 
  /* Enable PolarSSL RNG prediction resistance support */
  #ifdef ENABLE_CRYPTO_POLARSSL
-#include <polarssl/version.h>
-#if POLARSSL_VERSION_NUMBER >= 0x01010000
  #define ENABLE_PREDICTION_RESISTANCE
-#endif
  #endif /* ENABLE_CRYPTO_POLARSSL */
 
  /*
--

1.7.5.4

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Openvpn-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Signed-off-by Adriaan de Jong <[email protected]...>

---
 README.polarssl |    4 ++--

 1 files changed, 2 insertions(+), 2 deletions(-)

README.polarssl +1 -1

index 77a9575..ab7c2d7 100644
@@ -3,11 +3,11 @@ instructions:
 
  To Build and Install,
 
-       ./configure --with-ssl-type=polarssl
+       ./configure --with-crypto-library=polarssl

       make
       make install

README.polarssl +1 -1

-This version depends on at least PolarSSL v0.99.
+This version depends on at least PolarSSL v1.1.

 *************************************************************************

--
1.7.5.4

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Openvpn-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

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 <[email protected]...>

Signed-off-by Eelse-jan Stutvoet <[email protected]...>

---
 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(-)

src/openvpn/crypto_polarssl.c +8 -3

index 0e6728c..158ccfc 100644
@@ -42,12 +42,18 @@
  #include "buffer.h"
  #include "integer.h"
  #include "crypto_backend.h"
+#include "otime.h"
+#include "misc.h"
 
  #include <polarssl/des.h>
  #include <polarssl/md5.h>
  #include <polarssl/cipher.h>
  #include <polarssl/havege.h>
 
+#if (POLARSSL_VERSION_NUMBER >= 0x01010000)
+#include <polarssl/entropy.h>
+#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.
+ */

src/openvpn/crypto_polarssl.c +14 -0

+#if (POLARSSL_VERSION_NUMBER >= 0x01010000)
+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, &gc);
+
+      /*
+       * 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(&pers_string, "OpenVPN %0u %p %s", platform_getpid(), &cd_ctx, time_string(0, 0, 0, &gc));

src/openvpn/crypto_polarssl.c +5 -0

+
+      /* Initialise PolarSSL RNG, and built-in entropy sources */
+      entropy_init(&ec);
+
+      if (0 != ctr_drbg_init(&cd_ctx, entropy_func, &ec,

BPTR(&pers_string), BLEN(&pers_string)))
+        msg (M_FATAL, "Failed to initialize random generator");

src/openvpn/crypto_polarssl.c +11 -0

+
+      gc_free(&gc);
+      rand_initialised = true;
+  }
+
+  return &cd_ctx;
+}
+
+#else /* (POLARSSL_VERSION_NUMBER < 0x01010000) */
+
+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);
-      hs_initialised = true;
+      rand_initialised = true;
    }

+  return &hs;

src/openvpn/crypto_polarssl.c +13 -0

+}
+
+#endif /* (POLARSSL_VERSION_NUMBER >= 0x01010000) */
+
+int
+rand_bytes (uint8_t *output, int len)
+{
+#if (POLARSSL_VERSION_NUMBER >= 0x01010000)
+  ctr_drbg_context *rng_ctx = rand_ctx_get();
+#else /* (POLARSSL_VERSION_NUMBER >= 0x01010000) */
+  havege_state *rng_ctx = rand_ctx_get();
+#endif /* (POLARSSL_VERSION_NUMBER >= 0x01010000) */
+

  while (len > 0)
    {
-      const int blen   = min_int (len, int_size);
-      const int rand_int       = havege_rand(&hs);

src/openvpn/crypto_polarssl.c +8 -1

-
+#if (POLARSSL_VERSION_NUMBER >= 0x01010000)
+      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 >= 0x01010000) */
+      const size_t blen = min_int (len, sizeof(int));
+      const int rand_int = havege_rand(rng_ctx);

      memcpy (output, &rand_int, blen);

src/openvpn/crypto_polarssl.c +3 -0

+
+#endif /* (POLARSSL_VERSION_NUMBER >= 0x01010000) */
+

      output += blen;
      len -= blen;
    }
+
  return 1;
 }

src/openvpn/crypto_polarssl.h +14 -0

index 358483a..2f303db 100644
@@ -30,9 +30,16 @@
  #ifndef CRYPTO_POLARSSL_H_
  #define CRYPTO_POLARSSL_H_
 
+#include <polarssl/version.h>
  #include <polarssl/cipher.h>
  #include <polarssl/md.h>
 
+#if (POLARSSL_VERSION_NUMBER >= 0x01010000)
+#  include <polarssl/ctr_drbg.h>
+#else
+#  include <polarssl/havege.h>
+#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 SHA_DIGEST_LENGTH      20
  #define DES_KEY_LENGTH 8
 
+/**
+ * Returns a singleton instance of the PolarSSL random number generator.
+ *
+ * For PolarSSL 1.0, this is the HAVEGE random number generator.
+ *
+ * For PolarSSL 1.1+, this is the CTR_DRBG random number generator. If it
+ * hasn't been initialised yet, the RNG will be initialised using the

default
+ * entropy sources. Aside from the default platform entropy sources, an
+ * additional entropy source, the HAVEGE random number generator will also be
+ * added. During initialisation, a personalisation string will be added based
+ * on the time, the PID, and a pointer to the random context.
+ */

src/openvpn/crypto_polarssl.h +6 -0

+#if (POLARSSL_VERSION_NUMBER >= 0x01010000)
+ctr_drbg_context * rand_ctx_get();
+#else
+havege_state * rand_ctx_get();
+#endif
+

 #endif /* CRYPTO_POLARSSL_H_ */

src/openvpn/ssl.c +2 -0

index 251f8ed..767bc8e 100644
@@ -391,6 +391,11 @@ init_ssl (const struct options *options, struct
 tls_root_ctx *new_ctx)
       tls_ctx_restrict_ciphers(new_ctx, options->cipher_list);
     }
 
+#ifdef ENABLE_CRYPTO_POLARSSL
+  /* Fox-IT hardening: Personalise the random by mixing in the

certificate */
+  tls_ctx_personalise_random (new_ctx);

src/openvpn/ssl.c +2 -0

+#endif
+

  tls_clear_error ();
  return;

src/openvpn/ssl_backend.h +3 -0

index 5ea6a06..f3e69dd 100644
@@ -272,6 +272,16 @@ void tls_ctx_load_extra_certs (struct tls_root_ctx
 *ctx, const char *extra_certs
  #endif
     );
 
+#ifdef ENABLE_CRYPTO_POLARSSL
+/**
+ * Add a personalisation string to the PolarSSL RNG, based on the

certificate
+ * loaded into the given context.
+ *
+ * @param ctx                  TLS context to use
+ */

src/openvpn/ssl_backend.h +3 -0

+void tls_ctx_personalise_random(struct tls_root_ctx *ctx);
+#endif
+

 /* **************************************
 *
 * Key-state specific functions

src/openvpn/ssl_polarssl.c +27 -9

index d4d85c8..8f35608 100644
@@ -44,6 +44,9 @@
  #include "manage.h"
  #include "ssl_common.h"
 
+#include <polarssl/sha2.h>
+#include <polarssl/havege.h>
+
  #include "ssl_verify_polarssl.h"
  #include <polarssl/pem.h>
 

@@ -85,9 +88,6 @@ tls_ctx_server_new(struct tls_root_ctx *ctx)
   ASSERT(NULL != ctx);
   CLEAR(*ctx);
 
-  ALLOC_OBJ_CLEAR(ctx->hs, havege_state);
-  havege_init(ctx->hs);
-
   ALLOC_OBJ_CLEAR(ctx->dhm_ctx, dhm_context);
   ALLOC_OBJ_CLEAR(ctx->priv_key, rsa_context);
 

@@ -103,12 +103,8 @@ void
  tls_ctx_client_new(struct tls_root_ctx *ctx)
  {
   ASSERT(NULL != ctx);
-
   CLEAR(*ctx);
 
-  ALLOC_OBJ_CLEAR(ctx->hs, havege_state);
-  havege_init(ctx->hs);
-
   ALLOC_OBJ_CLEAR(ctx->dhm_ctx, dhm_context);
   ALLOC_OBJ_CLEAR(ctx->priv_key, rsa_context);
 

@@ -143,8 +139,6 @@ tls_ctx_free(struct tls_root_ctx *ctx)
       }
  #endif
 
-      free(ctx->hs);
-
       if (ctx->allowed_ciphers)
        free(ctx->allowed_ciphers);
 

@@ -504,6 +498,30 @@ static void my_debug( void *ctx, int level, const
 char *str )
     }
  }
 
+/*
+ * Further personalise the RNG using a hash of the public key
+ */
+void tls_ctx_personalise_random(struct tls_root_ctx *ctx)
+{
+#if (POLARSSL_VERSION_NUMBER >= 0x01010000)
+  static char old_sha256_hash[32] = {0};
+  char sha256_hash[32] = {0};
+  ctr_drbg_context *cd_ctx = rand_ctx_get();
+
+  if (NULL != ctx->crt_chain)
+    {
+      x509_cert *cert = ctx->crt_chain;
+
+      sha2(cert->tbs.p, cert->tbs.len, sha256_hash, false);
+      if ( 0 != memcmp(old_sha256_hash, sha256_hash,
 sizeof(sha256_hash)))
+       {
+         ctr_drbg_update(cd_ctx, sha256_hash, 32);
+         memcpy(old_sha256_hash, sha256_hash, sizeof(old_sha256_hash));
+       }
+    }
+#endif /* POLARSSL_VERSION_NUMBER >= 0x01010000 */
+}
+
  void key_state_ssl_init(struct key_state_ssl *ks_ssl,

    const struct tls_root_ctx *ssl_ctx, bool is_server, void *session) {

src/openvpn/ssl_polarssl.c +7 -1

@@ -517,7 +535,13 @@ void key_state_ssl_init(struct key_state_ssl *ks_ssl,
       /* Initialise SSL context */
       ssl_set_dbg (ks_ssl->ctx, my_debug, NULL);
       ssl_set_endpoint (ks_ssl->ctx, ssl_ctx->endpoint);
-      ssl_set_rng (ks_ssl->ctx, havege_rand, ssl_ctx->hs);
+
+#if (POLARSSL_VERSION_NUMBER >= 0x01010000)
+      ssl_set_rng (ks_ssl->ctx, ctr_drbg_random, rand_ctx_get());
+#else /* POLARSSL_VERSION_NUMBER >= 0x01010000 */
+      ssl_set_rng (ks_ssl->ctx, havege_rand, rand_ctx_get());
+#endif /* POLARSSL_VERSION_NUMBER >= 0x01010000 */
+
       ALLOC_OBJ_CLEAR (ks_ssl->ssn, ssl_session);
       ssl_set_session (ks_ssl->ctx, 0, 0, ks_ssl->ssn );
       if (ssl_ctx->allowed_ciphers)

src/openvpn/ssl_polarssl.h +0 -1

index e6149b6..2b02a6f 100644
@@ -30,7 +30,6 @@
  #ifndef SSL_POLARSSL_H_
  #define SSL_POLARSSL_H_
 
-#include <polarssl/havege.h>
  #include <polarssl/ssl.h>
  #include "config.h"
 

@@ -63,7 +62,6 @@ struct tls_root_ctx {
 

    int endpoint;              /**< Whether or not this is a server or a client */

-    havege_state *hs;          /**< HAVEGE random number state */ dhm_context *dhm_ctx;      /**< Diffie-Helmann-Merkle context */ x509_cert *crt_chain;      /**< Local Certificate chain */ x509_cert *ca_chain;       /**< CA chain for remote verification */ --
1.7.5.4

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Openvpn-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

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).

-----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-----

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?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 26 lines · Alon Bar-Lev

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).

Quoted 5 lines

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.

-----Original Message-----
From: Alon Bar-Lev [mailto:[email protected]...]
Sent: maandag 2 april 2012 12:42
To: David Sommerseth
Cc: [email protected]
Subject: Re: [Openvpn-devel] [PATCH 1/6] Added support for new PolarSSL 1.1 RNG

Quoted 8 lines · David Sommerseth

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 4 lines · Alon Bar-Lev

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

Quoted 3 lines

Quoted 3 lines

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

Quoted 6 lines

Quoted 6 lines

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.

Quoted 8 lines

Quoted 8 lines

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...

Quoted 10 lines

Quoted 9 lines

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?

Quoted 7 lines

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.

Quoted 56 lines

-----Original Message-----
From: Alon Bar-Lev [mailto:[email protected]...]
Sent: maandag 2 april 2012 12:42
To: David Sommerseth
Cc: [email protected]
Subject: Re: [Openvpn-devel] [PATCH 1/6] Added support for new PolarSSL 1.1 RNG

Quoted 8 lines · David Sommerseth

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 4 lines · Alon Bar-Lev

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

Quoted 3 lines

Quoted 3 lines

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

Quoted 6 lines

Quoted 6 lines

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.

Quoted 8 lines

Quoted 8 lines

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...

Quoted 10 lines

Quoted 9 lines

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?

Quoted 7 lines

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.

Quoted 9 lines

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

Quoted 80 lines · Adriaan de Jong

Quoted 58 lines

-----Original Message----- From: Alon Bar-Lev [mailto:[email protected]...] Sent: maandag 2 april 2012 12:42 To: David Sommerseth Cc:
[email protected] Subject: Re:
[Openvpn-devel] [PATCH 1/6] Added support for new PolarSSL 1.1 RNG

Quoted 8 lines · David Sommerseth

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Quoted 5 lines · Alon Bar-Lev

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

Quoted 4 lines

Quoted 4 lines

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

Quoted 10 lines

Quoted 10 lines

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;

Quoted 5 lines

Quoted 5 lines

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...

Quoted 10 lines

Quoted 9 lines

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?

Quoted 8 lines

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.

Quoted 9 lines

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.

Quoted 2 lines

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...

-----Original Message-----
From: David Sommerseth [mailto:[email protected]...]

Quoted 5 lines · Alon Bar-Lev

Quoted 3 lines · Adriaan de Jong

Quoted 3 lines

-----Original Message----- From: Alon Bar-Lev [mailto:[email protected]...] Sent: maandag 2 april 2012 12:42 To: David Sommerseth Cc:

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Right. Next stage is getting rid of syshead.h... The following is

to

Quoted 9 lines

Quoted 9 lines

Quoted 8 lines

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.

Quoted 7 lines

Quoted 7 lines

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

Quoted 7 lines

Quoted 5 lines

:). 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

Quoted 2 lines

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.

Quoted 84 lines

Quoted 82 lines · Adriaan de Jong

Quoted 58 lines

-----Original Message----- From: Alon Bar-Lev [mailto:[email protected]...] Sent: maandag 2 april 2012 12:42 To: David Sommerseth Cc:
[email protected] Subject: Re:
[Openvpn-devel] [PATCH 1/6] Added support for new PolarSSL 1.1 RNG

Quoted 8 lines · David Sommerseth

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Quoted 5 lines · Alon Bar-Lev

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

Quoted 4 lines

Quoted 4 lines

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

Quoted 10 lines

Quoted 10 lines

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;

Quoted 5 lines

Quoted 5 lines

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...

Quoted 10 lines

Quoted 9 lines

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?

Quoted 8 lines

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.

Quoted 9 lines

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

Quoted 4 lines

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.

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.

Well, I don't care about version numbers... they are just snapshots in time.

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.

Hi,

Quoted 4 lines · Adriaan de Jong

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.

Hi Alon,

2012/4/2 Alon Bar-Lev <[email protected]...>:

Quoted 7 lines

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...)

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.