[openssl-dev] use SIPhash for OPENSSL_LH_strhash?
Should we move to using SIPHash for the default string hashing function in OpenSSL? It's now in the kernel https://lkml.org/lkml/2017/1/9/619 Overview at https://131002.net/siphash/ -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richs...@jabber.at Twitter: RichSalz -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Enabling AES-192 ciphers, how to expose DHE-RSA-AES192-GCM-SHA384
> Doesn't the fact that AES-192 seems to be more resistant against related key > attacks than AES-256 "in a world of 2^50 keys" count as an argument for > inclusion? > > A related question, is the fact that AES-192 is more resistant to related key > attacks caused by the fact that it uses a key size that is not an exponent of > 2? Take it up with the IETF folks; I was just summarizing why. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Enabling AES-192 ciphers, how to expose DHE-RSA-AES192-GCM-SHA384
Hello Rich, On Mon, 2017-01-09 at 19:52 +, Salz, Rich wrote: > AES 192 has been discussed at various times in the IETF mailing lists > (see CFRG and TLS for most likely places). Here's one posting: > https://www.ietf.org/mail-archive/web/cfrg/current/msg04820.html > > My short summary is that if 128 isn't good enough for you, use 256. > 192 is a midpoint that only makes things more complicated by adding > more options (and potentially increases the size of the clienthello > message, which has had deployment problems with some platforms). Doesn't the fact that AES-192 seems to be more resistant against related key attacks than AES-256 "in a world of 2^50 keys" count as an argument for inclusion? A related question, is the fact that AES-192 is more resistant to related key attacks caused by the fact that it uses a key size that is not an exponent of 2? Regards, Leonard. -- mount -t life -o ro /dev/dna /genetic/research -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Enabling AES-192 ciphers, how to expose DHE-RSA-AES192-GCM-SHA384
> Has anyone ever attempted to get such ciphers included in that IANA list? It > seems AES-192 is being treated rather stepmotherly in the standards. AES 192 has been discussed at various times in the IETF mailing lists (see CFRG and TLS for most likely places). Here's one posting: https://www.ietf.org/mail-archive/web/cfrg/current/msg04820.html My short summary is that if 128 isn't good enough for you, use 256. 192 is a midpoint that only makes things more complicated by adding more options (and potentially increases the size of the clienthello message, which has had deployment problems with some platforms). -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Enabling AES-192 ciphers, how to expose DHE-RSA-AES192-GCM-SHA384
Hello Viktor, On Mon, 2017-01-09 at 19:25 +, Viktor Dukhovni wrote: > There are no AES-192 ciphersuites in the IANA TLS registry: > > > http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4 > > so these cannot (interoperably) be used with TLS. Right. I thought these reference IDs were only for internal use, but of course that is not the case... Thanks for clearing that up. Has anyone ever attempted to get such ciphers included in that IANA list? It seems AES-192 is being treated rather stepmotherly in the standards. Regards, Leonard. -- mount -t life -o ro /dev/dna /genetic/research -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Enabling AES-192 ciphers, how to expose DHE-RSA-AES192-GCM-SHA384
On Mon, Jan 09, 2017 at 07:57:43PM +0100, Leonard den Ottolander wrote:
> Considering that AES-192 seems to be very resistant against related key
> attacks (http://eprint.iacr.org/2009/317) and the algorithm is already
> available in the openssl code I am trying to expose the AES-192
> ciphers.
There are no AES-192 ciphersuites in the IANA TLS registry:
http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4
so these cannot (interoperably) be used with TLS.
> +/* AES-192 */
> +/* Cipher A8 */
> +{
> + 0, /* not implemented (non-ephemeral DH) */
> + TLS1_TXT_DH_DSS_WITH_AES_192_SHA256,
> + TLS1_CK_DH_DSS_WITH_AES_192_SHA256,
That codepoint is: TLS_PSK_WITH_AES_128_GCM_SHA256
> +/* Cipher A9 */
> +{
> + 0, /* not implemented (non-ephemeral DH) */
> + TLS1_TXT_DH_RSA_WITH_AES_192_SHA256,
> + TLS1_CK_DH_RSA_WITH_AES_192_SHA256,
That codepoint is: TLS_PSK_WITH_AES_256_GCM_SHA384
> +/* Cipher AA */
> +{
> + 1,
> + TLS1_TXT_DHE_DSS_WITH_AES_192_SHA256,
> + TLS1_CK_DHE_DSS_WITH_AES_192_SHA256,
Another conflict.
> +/* Cipher AB */
> +{
> + 1,
> + TLS1_TXT_DHE_RSA_WITH_AES_192_SHA256,
> + TLS1_CK_DHE_RSA_WITH_AES_192_SHA256,
Another conflict...
--
Viktor.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] Enabling AES-192 ciphers, how to expose DHE-RSA-AES192-GCM-SHA384
Hello,
Considering that AES-192 seems to be very resistant against related key
attacks (http://eprint.iacr.org/2009/317) and the algorithm is already
available in the openssl code I am trying to expose the AES-192
ciphers.
Attached is a patch against 1.0.1u (adapted from the version I created
against RHEL "1.0.1e hobbled") that tries to accomplish this for plain
and EDH ciphers. Once I get this to work I will continue by adding the
EECDH ciphers.
The patch seems to work for most parts, except from exposing the
AES192-GCM ciphers. When the self test is run (make -C test apps tests)
it chokes with a client error:
ERROR in CLIENT
140069906728640:error:140740B5:SSL routines:SSL23_CLIENT_HELLO:no ciphers
available:s23_clnt.c:502:
TLSv1.2, cipher (NONE) (NONE)
1 handshakes of 256 bytes done
Failed DHE-RSA-AES192-GCM-SHA384
make: *** [test_ssl] Error 1
The error occurs in ssl23_client_hello();
Note that the last hunk disables the testing of AES-192-GCM ciphers.
This is a hack to get the adapted RHEL srpm to build that should
eventually be removed. Time stamps on the files are also garbled as I
have not normalized the patch against a fresh tree yet. This is no
problem when applying it.
So my question is, could someone point me in the right direction on how
to expose the AES-192-GCM ciphers, i.e. what am I doing wrong that is
causing the client error?
Would the development team consider adding a patch exposing AES-192
ciphers in openssl once it's complete?
Thanks for your help.
Regards,
Leonard.
--
mount -t life -o ro /dev/dna /genetic/research
diff -pur openssl-1.0.1u.000/ssl/s3_lib.c openssl-1.0.1u/ssl/s3_lib.c
--- openssl-1.0.1u.000/ssl/s3_lib.c 2016-09-22 12:29:27.0 +0200
+++ openssl-1.0.1u/ssl/s3_lib.c 2017-01-09 01:25:22.608967809 +0100
@@ -948,7 +948,7 @@ OPENSSL_GLOBAL SSL_CIPHER ssl3_ciphers[]
},
/* Cipher 30 */
{
- 0,
+ 0, /* not implemented (non-ephemeral DH) */
TLS1_TXT_DH_DSS_WITH_AES_128_SHA,
TLS1_CK_DH_DSS_WITH_AES_128_SHA,
SSL_kDHd,
@@ -963,7 +963,7 @@ OPENSSL_GLOBAL SSL_CIPHER ssl3_ciphers[]
},
/* Cipher 31 */
{
- 0,
+ 0, /* not implemented (non-ephemeral DH) */
TLS1_TXT_DH_RSA_WITH_AES_128_SHA,
TLS1_CK_DH_RSA_WITH_AES_128_SHA,
SSL_kDHr,
@@ -1039,7 +1039,7 @@ OPENSSL_GLOBAL SSL_CIPHER ssl3_ciphers[]
},
/* Cipher 36 */
{
- 0,
+ 0, /* not implemented (non-ephemeral DH) */
TLS1_TXT_DH_DSS_WITH_AES_256_SHA,
TLS1_CK_DH_DSS_WITH_AES_256_SHA,
SSL_kDHd,
@@ -1314,6 +1314,117 @@ OPENSSL_GLOBAL SSL_CIPHER ssl3_ciphers[]
},
#endif /* OPENSSL_NO_CAMELLIA */
+/* AES-192 */
+/* Cipher 47 */
+{
+ 1,
+ TLS1_TXT_RSA_WITH_AES_192_SHA,
+ TLS1_CK_RSA_WITH_AES_192_SHA,
+ SSL_kRSA,
+ SSL_aRSA,
+ SSL_AES192,
+ SSL_SHA1,
+ SSL_TLSV1,
+ SSL_NOT_EXP|SSL_HIGH|SSL_FIPS,
+ SSL_HANDSHAKE_MAC_DEFAULT|TLS1_PRF,
+ 192,
+ 192,
+ },
+/* Cipher 48 */
+{
+ 0, /* not implemented (non-ephemeral DH) */
+ TLS1_TXT_DH_DSS_WITH_AES_192_SHA,
+ TLS1_CK_DH_DSS_WITH_AES_192_SHA,
+ SSL_kDHd,
+ SSL_aDH,
+ SSL_AES192,
+ SSL_SHA1,
+ SSL_TLSV1,
+ SSL_NOT_EXP|SSL_HIGH|SSL_FIPS,
+ SSL_HANDSHAKE_MAC_DEFAULT|TLS1_PRF,
+ 192,
+ 192,
+ },
+
+/* Cipher 49 */
+{
+ 0, /* not implemented (non-ephemeral DH) */
+ TLS1_TXT_DH_RSA_WITH_AES_192_SHA,
+ TLS1_CK_DH_RSA_WITH_AES_192_SHA,
+ SSL_kDHr,
+ SSL_aDH,
+ SSL_AES192,
+ SSL_SHA1,
+ SSL_TLSV1,
+ SSL_NOT_EXP|SSL_HIGH|SSL_FIPS,
+ SSL_HANDSHAKE_MAC_DEFAULT|TLS1_PRF,
+ 192,
+ 192,
+ },
+
+/* Cipher 4A */
+{
+ 1,
+ TLS1_TXT_DHE_DSS_WITH_AES_192_SHA,
+ TLS1_CK_DHE_DSS_WITH_AES_192_SHA,
+ SSL_kEDH,
+ SSL_aDSS,
+ SSL_AES192,
+ SSL_SHA1,
+ SSL_TLSV1,
+ SSL_NOT_EXP|SSL_HIGH|SSL_FIPS,
+ SSL_HANDSHAKE_MAC_DEFAULT|TLS1_PRF,
+ 192,
+ 192,
+ },
+
+/* Cipher 4B */
+{
+ 1,
+ TLS1_TXT_DHE_RSA_WITH_AES_192_SHA,
+ TLS1_CK_DHE_RSA_WITH_AES_192_SHA,
+ SSL_kEDH,
+ SSL_aRSA,
+ SSL_AES192,
+ SSL_SHA1,
+ SSL_TLSV1,
+ SSL_NOT_EXP|SSL_HIGH|SSL_FIPS,
+ SSL_HANDSHAKE_MAC_DEFAULT|TLS1_PRF,
+ 192,
+ 192,
+ },
+
+/* Cipher 4C */
+{
+ 1,
+ TLS1_TXT_ADH_WITH_AES_192_SHA,
+ TLS1_CK_ADH_WITH_AES_192_SHA,
+ SSL_kEDH,
+ SSL_aNULL,
+ SSL_AES192,
+ SSL_SHA1,
+ SSL_TLSV1,
+ SSL_NOT_EXP|SSL_HIGH|SSL_FIPS,
+ SSL_HANDSHAKE_MAC_DEFAULT|TLS1_PRF,
+ 192,
+ 192,
+ },
+/* Cipher 4D */
+{
+ 1,
+ TLS1_TXT_RSA_WITH_AES_192_SHA256,
+ TLS1_CK_RSA_WITH_AES_192_SHA256,
+ SSL_kRSA,
+ SSL_aRSA,
+ SSL_AES192,
+ SSL_SHA256,
+ SSL_TLSV1_2,
+ SSL_NOT_EXP|SSL_HIGH|SSL_FIPS,
+ SSL_HANDSHAKE_MAC_DEFAULT|TLS1_PRF,
+ 192,
+ 192,
+ },
+
Re: [openssl-dev] Revert commit 10621ef white space nightmare
Hello Matt, On Mon, 2017-01-09 at 18:06 +, Matt Caswell wrote: > That particular commit was the result of a lot work and discussion on > this list and in other places. This is the code reformat commit and > changes the format of the source to be consistent with the OpenSSL > coding style: > > https://www.openssl.org/policies/codingstyle.html Yeah I sort of guessed that but wasn't around when that discussion took place. I'll have a look at that guide and will learn to live with it ;) . With some hand editing I got my patch fixed as you can see from my previous post. Regards, Leonard. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Revert commit 10621ef white space nightmare
On 01/09/2017 10:46 AM, Leonard den Ottolander wrote: > I don't remember ever seeing directives being indented by adding > white space between the hash sign and the directive. In my world, that is quite common. > If one wants to indent directives space is normally inserted before > the hash sign. No, that is not normal. It is not even permitted by traditional versions of the preprocessor. I quote from https://gcc.gnu.org/onlinedocs/gcc-3.1/cpp/Traditional-Mode.html >> Preprocessing directives are recognized in traditional C only when >> their leading # appears in the first column. There can be no >> whitespace between the beginning of the line and the #. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Revert commit 10621ef white space nightmare
On Mon, Jan 09, 2017, Leonard den Ottolander wrote: > If one wants to indent directives space is normally inserted before the > hash sign. I don't remember ever seeing directives being indented by > adding white space between the hash sign and the directive. Then you didn't look at source code for sendmail, libesmtp, deliver, mutt, nail, afl, flex, bison, make, (just some stuff I have available for grep '^# *[dei]') and many others... BTW: the reason the spaces are after '#' is because some (old?) pre-preprocessors handle '#' only in the first column. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Revert commit 10621ef white space nightmare
On 09/01/17 17:46, Leonard den Ottolander wrote: > Hello, > > https://github.com/openssl/openssl/commit/10621efd3296a92f489f6ab26a88e88d9790930e#diff-4b59eddb1c722b1dc3d17b5f64149e12 > > is a white space nightmare. The replacement of "#define"s by "# define"s > etc. is just silly and makes it unnecessarily hard to port patches > between different releases (working with RHEL 7.3 "hobbled 1.0.1e" vs. > 1.0.1u). Sadly patch -l chokes on this kind of white space nonsense and > who can blame it? > > If one wants to indent directives space is normally inserted before the > hash sign. I don't remember ever seeing directives being indented by > adding white space between the hash sign and the directive. > > Please revert this commit (in all branches), even though it has been a > while. Thank you. That particular commit was the result of a lot work and discussion on this list and in other places. This is the code reformat commit and changes the format of the source to be consistent with the OpenSSL coding style: https://www.openssl.org/policies/codingstyle.html Like I said there was a lot of discussion at the time with arguments in favour and against the reformat - although the on the whole most people were in favour. The coding style as a whole was based heavily on the Linux Kernel coding style. I don't recall the provenance of the pre-processor indentation style. Needless to say though everyone has their particular thoughts about what makes "good" style - and no matter what you come up with no one is going to be pleased with all of it. Personally I believe the reformat has done nothing but good for us. It has made maintaining the source code *far* easier. Whatever your thoughts on it a lot of water has gone under the bridge since then and there have been a lot of commits to all the branches. Reverting this patch is just not an option at this stage even if we wanted to (which we don't) - you would disappear into conflict hell never to return. Of course 1.0.1 is now out of support anyway so we won't be making any more commits to that particular branch! Matt -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Revert commit 10621ef white space nightmare
Sorry you feel this way, but the patch is not being reverted. First of all, 1.0.1 is now end of life and gets no updates :) As for the specific pre-processor, there are systems out there that only recognized the poundsign if it was in the first column (silly but true). Also, we prefer the whitespace on CPP lines the way we have it. You can find some details about the code reformat at two blog entries: https://www.openssl.org/blog/blog/2015/01/05/source-code-reformat/ and https://www.openssl.org/blog/blog/2015/02/11/code-reformat-finished/ The best way to address your issue is to start using 1.0.2 or later. If you cannot do that, then a perl script like this can help: perl -pi.bak -e 's/^\s*#\s*/#/' files... -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] Revert commit 10621ef white space nightmare
Hello, https://github.com/openssl/openssl/commit/10621efd3296a92f489f6ab26a88e88d9790930e#diff-4b59eddb1c722b1dc3d17b5f64149e12 is a white space nightmare. The replacement of "#define"s by "# define"s etc. is just silly and makes it unnecessarily hard to port patches between different releases (working with RHEL 7.3 "hobbled 1.0.1e" vs. 1.0.1u). Sadly patch -l chokes on this kind of white space nonsense and who can blame it? If one wants to indent directives space is normally inserted before the hash sign. I don't remember ever seeing directives being indented by adding white space between the hash sign and the directive. Please revert this commit (in all branches), even though it has been a while. Thank you. Regards, Leonard. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] x509 extension support
Hello, Can anyone help me in discerning which version of openssl supports sbgp-autonomousSysNum and sbgp-ipAddrBlock? If it has been deprecated then providing the alternative would be greatly appreciated. A sample openssl.cnf is provided below. When I perform a request for req it fails because of the objects described above. The version of openssl I am using when attempting this req generation is version OpenSSL 1.0.2g 1 Mar 2016 [req]default_bits= 2048default_md = sha256distinguished_name = req_dnprompt = noencrypt_key = no [req_dn]CN = Testbed RPKI root certificate [x509v3_extensions]basicConstraints= critical,CA:truesubjectKeyIdentifier= hashkeyUsage = critical,keyCertSign,cRLSignsubjectInfoAccess = @siacertificatePolicies = critical,1.3.6.1.5.5.7.14.2sbgp-autonomousSysNum = critical,@rfc3779_asnssbgp-ipAddrBlock= critical,@rfc3997_addrs [sia]1.3.6.1.5.5.7.48.5;URI = rsync://example.org/rpki/root/1.3.6.1.5.5.7.48.10;URI = rsync://example.org/rpki/root/root.mft [rfc3779_asns]AS.0 = 64496-64511AS.1 = 65536-65551 [rfc3997_addrs]IPv4.0 = 192.0.2.0/24IPv4.1 = 198.51.100.0/24IPv4.2 = 203.0.113.0/24 IPv6.0 = 2001:0DB8::/32 Cheers, Freemon -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
