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,
+ },
+
