Mark recommended ciphers/algorithms
| Message ID | 5665B543.1040304@web.de |
|---|---|
| State | Dropped |
| Headers |
Return-Path: <development-bounces@lists.ipfire.org> Received: from mail01.ipfire.org (mail01.tremer.info [172.28.1.200]) by septima.ipfire.org (Postfix) with ESMTP id E64EB6038E for <patchwork@ipfire.org>; Mon, 7 Dec 2015 17:35:32 +0100 (CET) Received: from hedwig.ipfire.org (localhost [IPv6:::1]) by mail01.ipfire.org (Postfix) with ESMTP id 7E464D51; Mon, 7 Dec 2015 17:35:32 +0100 (CET) Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=212.227.15.4; helo=mout.web.de; envelope-from=itsuperhack@web.de; receiver=michael.tremer@ipfire.org Received: from mout.web.de (mout.web.de [212.227.15.4]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPS id 7CDE9D23; Mon, 7 Dec 2015 17:35:29 +0100 (CET) Received: from 127.0.0.1 ([77.247.181.163]) by smtp.web.de (mrweb001) with ESMTPSA (Nemesis) id 0MV4xx-1ZkpFV0v6b-00YSm0; Mon, 07 Dec 2015 17:35:28 +0100 Subject: [PATCH] Mark recommended ciphers/algorithms To: Michael Tremer <michael.tremer@ipfire.org>, development@lists.ipfire.org References: <5653202F.1050604@web.de> <F75A6F36-AC7A-416E-9700-8842F5C460CE@ipfire.org> <1449010720.31655.42.camel@ipfire.org> <565EB4C7.30900@web.de> <1449053222.31655.59.camel@ipfire.org> From: IT Superhack <itsuperhack@web.de> Message-ID: <5665B543.1040304@web.de> Date: Mon, 7 Dec 2015 17:35:15 +0100 MIME-Version: 1.0 In-Reply-To: <1449053222.31655.59.camel@ipfire.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="KNCIqRSDkjgHx7hHGxKUIVnFheGBCwxNM" X-Provags-ID: V03:K0:C/lfTLIjuaR1yYuXkxGhcn6wLJYs0Pe3E2FdsDAC77TPXxYyANj eIfSb0u6P+farFh5DEx0E3Yh6hnI1swig5ooPTvCvflFNRTuD5rLBKCTZIeI6sU58X2/WXl Kcbb+o5yHBaa0+7kVxdps8urRN15CDM5FHEGkVkkC2HyrhdguV3HEs0z3/nHVs9sgNcEhif jhvaMg/l+RJ3zX//AJ7EA== X-UI-Out-Filterresults: notjunk:1; V01:K0:hWdS7Nw3Q1w=:eNENgGOUMF1zGr+3K04dtl STvRnhFH8VtKRwUv+2BIkuxdtGzHTRfIxUpDbP1z5DEIQaFMpoxHOgVgncWEu4jSCcJKAGluy h91q8q4MV7e9dZpEBTeO8qnZLoZ2+Zu2FB1qXzEzMmc9AAo5JA+wxd0ACIQXjFRvWHssSJkWH t2abTORJdcxyGAAWMaA9j6KVmTaduHC25LoJozmH0Y5P4tHx74+ng8hbCk4wB/L/f8ivYqij8 3YWRFqiqoCPYpE0j8S+i2NbWBS76QE5wIiJk4WBUjWl6GgqVE9hoQK26Mlibh9KxqXDgtIDJ/ X9ZlcG/U6r6EhjJXY5SE8XoGj310BIdar2rZ3bl9YcvE18cXmFVTogxozpud0sMWQM9N46hWK dJc8CnpOvy4iIXJyIERbp5jygqyXj6sW5hYU75Dq8FwdsIIcJg6B/bTGXQ4Jc/wNNmy8vOl7s JQsKid5i6Mtkux/MM3D7f2syzE8r46GV6b9TB2iXVLH6rUJnCzMA7FcwBRfE3j4Lopg5tiZKH 1CVsvxpPE5NlFf6A1LZfrqXaqmFcbjgjg1uoTDFet7jsz+0NZIYnlWUfuzo8g2dSVgLzHh1Ph NNqxJQxmmuFbXTdGRlhklReU/fZD+Hk9iAARbyBoi4tT65T38QYClgPTgZ0XrqOF4YlX7KjVz XNLfwWQ+sE4oLuM1ehDFKMf5FITJyQ6Qnj9bCGNE9CN1JJeL0WJr93W1POL3jgedqbQY6SoUj poXZgLqDYN4LbDSJOJUDXTgm0KVW62vfUgTfSVYuqDDclQEA94ReP1QTP1DobGkT0JHhtIL6+ NTRJHjo X-BeenThere: development@lists.ipfire.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IPFire development talk <development.lists.ipfire.org> List-Unsubscribe: <http://lists.ipfire.org/mailman/options/development>, <mailto:development-request@lists.ipfire.org?subject=unsubscribe> List-Archive: <http://lists.ipfire.org/pipermail/development/> List-Post: <mailto:development@lists.ipfire.org> List-Help: <mailto:development-request@lists.ipfire.org?subject=help> List-Subscribe: <http://lists.ipfire.org/mailman/listinfo/development>, <mailto:development-request@lists.ipfire.org?subject=subscribe> Errors-To: development-bounces@lists.ipfire.org Sender: "Development" <development-bounces@lists.ipfire.org> |
Message
IT Superhack
Dec. 8, 2015, 3:35 a.m. UTC
Signed-off-by: Timmothy Wilson <itsuperhack@web.de>
---
Comments
Hello, this patch was line-wrapped and cannot be merged, but nevertheless, here are my thoughts: On Mon, 2015-12-07 at 17:35 +0100, IT Superhack wrote: > Signed-off-by: Timmothy Wilson <itsuperhack@web.de> > --- > diff --git a/html/cgi-bin/ovpnmain.cgi b/html/cgi-bin/ovpnmain.cgi > index 62af54e..15385f1 100644 > --- a/html/cgi-bin/ovpnmain.cgi > +++ b/html/cgi-bin/ovpnmain.cgi > @@ -1316,7 +1316,7 @@ END > <option value='1024' > $selected{'DHLENGHT'}{'1024'}>1024 > $Lang::tr{'bit'}</option> > <option value='2048' > $selected{'DHLENGHT'}{'2048'}>2048 > $Lang::tr{'bit'}</option> > <option value='3072' > $selected{'DHLENGHT'}{'3072'}>3072 > $Lang::tr{'bit'}</option> > - <option value='4096' > $selected{'DHLENGHT'}{'4096'}>4096 > $Lang::tr{'bit'}</option> > + <option value='4096' > $selected{'DHLENGHT'}{'4096'}>4096 > $Lang::tr{'bit'} ($Lang::tr{'recommended'})</option> > </select> > </td> > </tr> I agree, that it is desirable to use longer keys. However, I am not sure if it is a good idea to go all the way for 4096 bit and not only for e.g. 2048 bit. Why not 8192 even? I would like to read some justification for the values that are picked. Furthermore, I think that we the upper bound should be something that the average IPFire box is able to handle. > @@ -4687,7 +4687,7 @@ if ($cgiparams{'TYPE'} eq 'net') { > <option value='CAMELLIA-256-CBC' > $selected{'DCIPHER'}{'CAMELLIA-256-CBC'}>CAMELLIA-CBC (256 > $Lang::tr{'bit'})</option> > <option value='CAMELLIA-192-CBC' > $selected{'DCIPHER'}{'CAMELLIA-192-CBC'}>CAMELLIA-CBC (192 > $Lang::tr{'bit'})</option> > <option value='CAMELLIA-128-CBC' > $selected{'DCIPHER'}{'CAMELLIA-128-CBC'}>CAMELLIA-CBC (128 > $Lang::tr{'bit'})</option> > - <option value='AES-256-CBC' > $selected{'DCIPHER'}{'AES-256-CBC'}>AES-CBC (256 $Lang::tr{'bit'}, > $Lang::tr{'default'})</option> > + <option value='AES-256-CBC' > $selected{'DCIPHER'}{'AES-256-CBC'}>AES-CBC (256 $Lang::tr{'bit'}, > $Lang::tr{'default'}, $Lang::tr{'recommended'})</option> > <option value='AES-192-CBC' > $selected{'DCIPHER'}{'AES-192-CBC'}>AES-CBC (192 > $Lang::tr{'bit'})</option> > <option value='AES-128-CBC' > $selected{'DCIPHER'}{'AES-128-CBC'}>AES-CBC (128 > $Lang::tr{'bit'})</option> > <option value='DES-EDE3-CBC' > $selected{'DCIPHER'}{'DES-EDE3-CBC'}>DES-EDE3-CBC (192 > $Lang::tr{'bit'})</option> I can agree with that since it is already selected by default. This makes it just more explicit. I would have merged this if this was an independent patch in a patch set. > @@ -4702,7 +4702,7 @@ if ($cgiparams{'TYPE'} eq 'net') { > <td class='boldbase'>$Lang::tr{'ovpn ha'}:</td> > <td><select name='DAUTH'> > <option value='whirlpool' > $selected{'DAUTH'}{'whirlpool'}>Whirlpool (512 > $Lang::tr{'bit'})</option> > - <option value='SHA512' > $selected{'DAUTH'}{'SHA512'}>SHA2 (512 > $Lang::tr{'bit'})</option> > + <option value='SHA512' > $selected{'DAUTH'}{'SHA512'}>SHA2 (512 > $Lang::tr{'bit'}, $Lang::tr{'recommended'})</option> > <option value='SHA384' > $selected{'DAUTH'}{'SHA384'}>SHA2 (384 > $Lang::tr{'bit'})</option> > <option value='SHA256' > $selected{'DAUTH'}{'SHA256'}>SHA2 (256 > $Lang::tr{'bit'})</option> > <option value='SHA1' > $selected{'DAUTH'}{'SHA1'}>SHA1 (160 > $Lang::tr{'bit'} Default)</option> Same as above. SHA2 is considered to be "secure enough for now". Why is 256 bit not enough? This has also a rather huge performance impact. Things like these should also be mentioned in the commit message. > diff --git a/html/cgi-bin/vpnmain.cgi b/html/cgi-bin/vpnmain.cgi > index f1cffb8..9aa50f5 100644 > --- a/html/cgi-bin/vpnmain.cgi > +++ b/html/cgi-bin/vpnmain.cgi > @@ -2424,7 +2424,7 @@ if(($cgiparams{'ACTION'} eq > $Lang::tr{'advanced'}) || > <td>$Lang::tr{'vpn keyexchange'}:</td> > <td> > <select name='IKE_VERSION'> > - <option value='ikev2' > $selected{'IKE_VERSION'}{'ikev2'}>IKEv2</option> > + <option value='ikev2' > $selected{'IKE_VERSION'}{'ikev2'}>IKEv2 > ($Lang::tr{'recommended'})</option> > <option value='ikev1' > $selected{'IKE_VERSION'}{'ikev1'}>IKEv1</option> > </select> > </td> Why should IKEv2 be recommended? AFAIK there are no known design issues with IKEv1. Some algorithms might not be available, but this is not an issue for now since AES, SHA2, (AKA the strong ones) are supported. > @@ -2434,7 +2434,7 @@ if(($cgiparams{'ACTION'} eq > $Lang::tr{'advanced'}) || > <td class='boldbase' > width="15%">$Lang::tr{'encryption'}</td> > <td class='boldbase'> > <select name='IKE_ENCRYPTION' > multiple='multiple' size='6' > style='width: 100%'> > - <option value='aes256gcm128' > $checked{'IKE_ENCRYPTION'}{'aes256gcm128'}>256 bit AES-GCM/128 bit > ICV</option> > + <option value='aes256gcm128' > $checked{'IKE_ENCRYPTION'}{'aes256gcm128'}>256 bit AES-GCM/128 bit > ICV > ($Lang::tr{'recommended'})</option> > <option value='aes256gcm96' > $checked{'IKE_ENCRYPTION'}{'aes256gcm96'}>256 bit AES-GCM/96 bit > ICV</option> > <option value='aes256gcm64' > $checked{'IKE_ENCRYPTION'}{'aes256gcm64'}>256 bit AES-GCM/64 bit > ICV</option> > <option value='aes256' > $checked{'IKE_ENCRYPTION'}{'aes256'}>256 > bit AES-CBC</option> > @@ -2454,7 +2454,7 @@ if(($cgiparams{'ACTION'} eq > $Lang::tr{'advanced'}) || > </td> > <td class='boldbase'> > <select name='ESP_ENCRYPTION' > multiple='multiple' size='6' > style='width: 100%'> > - <option value='aes256gcm128' > $checked{'ESP_ENCRYPTION'}{'aes256gcm128'}>256 bit AES-GCM/128 bit > ICV</option> > + <option value='aes256gcm128' > $checked{'ESP_ENCRYPTION'}{'aes256gcm128'}>256 bit AES-GCM/128 bit > ICV > ($Lang::tr{'recommended'})</option> > <option value='aes256gcm96' > $checked{'ESP_ENCRYPTION'}{'aes256gcm96'}>256 bit AES-GCM/96 bit > ICV</option> > <option value='aes256gcm64' > $checked{'ESP_ENCRYPTION'}{'aes256gcm64'}>256 bit AES-GCM/64 bit > ICV</option> > <option value='aes256' > $checked{'ESP_ENCRYPTION'}{'aes256'}>256 > bit AES-CBC</option> Why are the AES-GCM cipher suites with smaller IVs not recommended? > @@ -2478,7 +2478,7 @@ if(($cgiparams{'ACTION'} eq > $Lang::tr{'advanced'}) || > <td class='boldbase' > width="15%">$Lang::tr{'integrity'}</td> > <td class='boldbase'> > <select name='IKE_INTEGRITY' > multiple='multiple' size='6' > style='width: 100%'> > - <option value='sha2_512' > $checked{'IKE_INTEGRITY'}{'sha2_512'}>SHA2 512 bit</option> > + <option value='sha2_512' > $checked{'IKE_INTEGRITY'}{'sha2_512'}>SHA2 512 bit > ($Lang::tr{'recommended'})</option> > <option value='sha2_384' > $checked{'IKE_INTEGRITY'}{'sha2_384'}>SHA2 384 bit</option> > <option value='sha2_256' > $checked{'IKE_INTEGRITY'}{'sha2_256'}>SHA2 256 bit</option> > <option value='aesxcbc' > $checked{'IKE_INTEGRITY'}{'aesxcbc'}>AES > XCBC</option> Same as above. > @@ -2488,7 +2488,7 @@ if(($cgiparams{'ACTION'} eq > $Lang::tr{'advanced'}) || > </td> > <td class='boldbase'> > <select name='ESP_INTEGRITY' > multiple='multiple' size='6' > style='width: 100%'> > - <option value='sha2_512' > $checked{'ESP_INTEGRITY'}{'sha2_512'}>SHA2 512 bit</option> > + <option value='sha2_512' > $checked{'ESP_INTEGRITY'}{'sha2_512'}>SHA2 512 bit > ($Lang::tr{'recommended'})</option> > <option value='sha2_384' > $checked{'ESP_INTEGRITY'}{'sha2_384'}>SHA2 384 bit</option> > <option value='sha2_256' > $checked{'ESP_INTEGRITY'}{'sha2_256'}>SHA2 256 bit</option> > <option value='aesxcbc' > $checked{'ESP_INTEGRITY'}{'aesxcbc'}>AES > XCBC</option> Same again. > diff --git a/langs/de/cgi-bin/de.pl b/langs/de/cgi-bin/de.pl > index 2bca854..b18cace 100644 > --- a/langs/de/cgi-bin/de.pl > +++ b/langs/de/cgi-bin/de.pl > @@ -1914,6 +1914,7 @@ > 'rebooting ipfire' => 'Starte IPFire neu', > 'reconnect' => 'Neu Verbinden', > 'reconnection' => 'Wiederverbindung', > +'recommended' => 'empfohlen', > 'red' => 'Internet', > 'red1' => 'ROT', > 'references' => 'Referenzen', > > The English translation is missing. Best, -Michael
Hello Michael, Michael Tremer: > Hello, > > this patch was line-wrapped and cannot be merged, but nevertheless, > here are my thoughts: I am unable to submit patches at the moment, since git send-email keeps crashing on every machine I own - sometimes starttls issues, sometimes segfault - and TB seems to line-wrap. > > On Mon, 2015-12-07 at 17:35 +0100, IT Superhack wrote: >> Signed-off-by: Timmothy Wilson <itsuperhack@web.de> >> --- >> diff --git a/html/cgi-bin/ovpnmain.cgi b/html/cgi-bin/ovpnmain.cgi >> index 62af54e..15385f1 100644 >> --- a/html/cgi-bin/ovpnmain.cgi >> +++ b/html/cgi-bin/ovpnmain.cgi >> @@ -1316,7 +1316,7 @@ END >> <option value='1024' >> $selected{'DHLENGHT'}{'1024'}>1024 >> $Lang::tr{'bit'}</option> >> <option value='2048' >> $selected{'DHLENGHT'}{'2048'}>2048 >> $Lang::tr{'bit'}</option> >> <option value='3072' >> $selected{'DHLENGHT'}{'3072'}>3072 >> $Lang::tr{'bit'}</option> >> - <option value='4096' >> $selected{'DHLENGHT'}{'4096'}>4096 >> $Lang::tr{'bit'}</option> >> + <option value='4096' >> $selected{'DHLENGHT'}{'4096'}>4096 >> $Lang::tr{'bit'} ($Lang::tr{'recommended'})</option> >> </select> >> </td> >> </tr> > > I agree, that it is desirable to use longer keys. However, I am not > sure if it is a good idea to go all the way for 4096 bit and not only > for e.g. 2048 bit. Why not 8192 even? > Since the SSLTest server page treats 2048 DH primes as "weak", I guess 3072 or better is suitable here. > I would like to read some justification for the values that are picked. Here is one, for example: https://netzpolitik.org/2015/kryptographie-open-source-und-gesellschaft/ (german, please see "8."). In this article is also mentioned that 512 bit hash algorithms should be used. > > Furthermore, I think that we the upper bound should be something that > the average IPFire box is able to handle. I agree with that. Maybe 3072 bits is a good deal between speed and security, what do you think? > >> @@ -4687,7 +4687,7 @@ if ($cgiparams{'TYPE'} eq 'net') { >> <option value='CAMELLIA-256-CBC' >> $selected{'DCIPHER'}{'CAMELLIA-256-CBC'}>CAMELLIA-CBC (256 >> $Lang::tr{'bit'})</option> >> <option value='CAMELLIA-192-CBC' >> $selected{'DCIPHER'}{'CAMELLIA-192-CBC'}>CAMELLIA-CBC (192 >> $Lang::tr{'bit'})</option> >> <option value='CAMELLIA-128-CBC' >> $selected{'DCIPHER'}{'CAMELLIA-128-CBC'}>CAMELLIA-CBC (128 >> $Lang::tr{'bit'})</option> >> - <option value='AES-256-CBC' >> $selected{'DCIPHER'}{'AES-256-CBC'}>AES-CBC (256 $Lang::tr{'bit'}, >> $Lang::tr{'default'})</option> >> + <option value='AES-256-CBC' >> $selected{'DCIPHER'}{'AES-256-CBC'}>AES-CBC (256 $Lang::tr{'bit'}, >> $Lang::tr{'default'}, $Lang::tr{'recommended'})</option> >> <option value='AES-192-CBC' >> $selected{'DCIPHER'}{'AES-192-CBC'}>AES-CBC (192 >> $Lang::tr{'bit'})</option> >> <option value='AES-128-CBC' >> $selected{'DCIPHER'}{'AES-128-CBC'}>AES-CBC (128 >> $Lang::tr{'bit'})</option> >> <option value='DES-EDE3-CBC' >> $selected{'DCIPHER'}{'DES-EDE3-CBC'}>DES-EDE3-CBC (192 >> $Lang::tr{'bit'})</option> > > I can agree with that since it is already selected by default. This > makes it just more explicit. > > I would have merged this if this was an independent patch in a patch > set. Thanks, but at the moment, i cannot hand in a patch without wrapped lines. > >> @@ -4702,7 +4702,7 @@ if ($cgiparams{'TYPE'} eq 'net') { >> <td class='boldbase'>$Lang::tr{'ovpn ha'}:</td> >> <td><select name='DAUTH'> >> <option value='whirlpool' >> $selected{'DAUTH'}{'whirlpool'}>Whirlpool (512 >> $Lang::tr{'bit'})</option> >> - <option value='SHA512' >> $selected{'DAUTH'}{'SHA512'}>SHA2 (512 >> $Lang::tr{'bit'})</option> >> + <option value='SHA512' >> $selected{'DAUTH'}{'SHA512'}>SHA2 (512 >> $Lang::tr{'bit'}, $Lang::tr{'recommended'})</option> >> <option value='SHA384' >> $selected{'DAUTH'}{'SHA384'}>SHA2 (384 >> $Lang::tr{'bit'})</option> >> <option value='SHA256' >> $selected{'DAUTH'}{'SHA256'}>SHA2 (256 >> $Lang::tr{'bit'})</option> >> <option value='SHA1' >> $selected{'DAUTH'}{'SHA1'}>SHA1 (160 >> $Lang::tr{'bit'} Default)</option> > > Same as above. SHA2 is considered to be "secure enough for now". Why is > 256 bit not enough? This has also a rather huge performance impact. > Things like these should also be mentioned in the commit message. > >> diff --git a/html/cgi-bin/vpnmain.cgi b/html/cgi-bin/vpnmain.cgi >> index f1cffb8..9aa50f5 100644 >> --- a/html/cgi-bin/vpnmain.cgi >> +++ b/html/cgi-bin/vpnmain.cgi >> @@ -2424,7 +2424,7 @@ if(($cgiparams{'ACTION'} eq >> $Lang::tr{'advanced'}) || >> <td>$Lang::tr{'vpn keyexchange'}:</td> >> <td> >> <select name='IKE_VERSION'> >> - <option value='ikev2' >> $selected{'IKE_VERSION'}{'ikev2'}>IKEv2</option> >> + <option value='ikev2' >> $selected{'IKE_VERSION'}{'ikev2'}>IKEv2 >> ($Lang::tr{'recommended'})</option> >> <option value='ikev1' >> $selected{'IKE_VERSION'}{'ikev1'}>IKEv1</option> >> </select> >> </td> > > Why should IKEv2 be recommended? AFAIK there are no known design issues > with IKEv1. Some algorithms might not be available, but this is not an > issue for now since AES, SHA2, (AKA the strong ones) are supported. > >> @@ -2434,7 +2434,7 @@ if(($cgiparams{'ACTION'} eq >> $Lang::tr{'advanced'}) || >> <td class='boldbase' >> width="15%">$Lang::tr{'encryption'}</td> >> <td class='boldbase'> >> <select name='IKE_ENCRYPTION' >> multiple='multiple' size='6' >> style='width: 100%'> >> - <option value='aes256gcm128' >> $checked{'IKE_ENCRYPTION'}{'aes256gcm128'}>256 bit AES-GCM/128 bit >> ICV</option> >> + <option value='aes256gcm128' >> $checked{'IKE_ENCRYPTION'}{'aes256gcm128'}>256 bit AES-GCM/128 bit >> ICV >> ($Lang::tr{'recommended'})</option> >> <option value='aes256gcm96' >> $checked{'IKE_ENCRYPTION'}{'aes256gcm96'}>256 bit AES-GCM/96 bit >> ICV</option> >> <option value='aes256gcm64' >> $checked{'IKE_ENCRYPTION'}{'aes256gcm64'}>256 bit AES-GCM/64 bit >> ICV</option> >> <option value='aes256' >> $checked{'IKE_ENCRYPTION'}{'aes256'}>256 >> bit AES-CBC</option> >> @@ -2454,7 +2454,7 @@ if(($cgiparams{'ACTION'} eq >> $Lang::tr{'advanced'}) || >> </td> >> <td class='boldbase'> >> <select name='ESP_ENCRYPTION' >> multiple='multiple' size='6' >> style='width: 100%'> >> - <option value='aes256gcm128' >> $checked{'ESP_ENCRYPTION'}{'aes256gcm128'}>256 bit AES-GCM/128 bit >> ICV</option> >> + <option value='aes256gcm128' >> $checked{'ESP_ENCRYPTION'}{'aes256gcm128'}>256 bit AES-GCM/128 bit >> ICV >> ($Lang::tr{'recommended'})</option> >> <option value='aes256gcm96' >> $checked{'ESP_ENCRYPTION'}{'aes256gcm96'}>256 bit AES-GCM/96 bit >> ICV</option> >> <option value='aes256gcm64' >> $checked{'ESP_ENCRYPTION'}{'aes256gcm64'}>256 bit AES-GCM/64 bit >> ICV</option> >> <option value='aes256' >> $checked{'ESP_ENCRYPTION'}{'aes256'}>256 >> bit AES-CBC</option> > > Why are the AES-GCM cipher suites with smaller IVs not recommended? > >> @@ -2478,7 +2478,7 @@ if(($cgiparams{'ACTION'} eq >> $Lang::tr{'advanced'}) || >> <td class='boldbase' >> width="15%">$Lang::tr{'integrity'}</td> >> <td class='boldbase'> >> <select name='IKE_INTEGRITY' >> multiple='multiple' size='6' >> style='width: 100%'> >> - <option value='sha2_512' >> $checked{'IKE_INTEGRITY'}{'sha2_512'}>SHA2 512 bit</option> >> + <option value='sha2_512' >> $checked{'IKE_INTEGRITY'}{'sha2_512'}>SHA2 512 bit >> ($Lang::tr{'recommended'})</option> >> <option value='sha2_384' >> $checked{'IKE_INTEGRITY'}{'sha2_384'}>SHA2 384 bit</option> >> <option value='sha2_256' >> $checked{'IKE_INTEGRITY'}{'sha2_256'}>SHA2 256 bit</option> >> <option value='aesxcbc' >> $checked{'IKE_INTEGRITY'}{'aesxcbc'}>AES >> XCBC</option> > > Same as above. > >> @@ -2488,7 +2488,7 @@ if(($cgiparams{'ACTION'} eq >> $Lang::tr{'advanced'}) || >> </td> >> <td class='boldbase'> >> <select name='ESP_INTEGRITY' >> multiple='multiple' size='6' >> style='width: 100%'> >> - <option value='sha2_512' >> $checked{'ESP_INTEGRITY'}{'sha2_512'}>SHA2 512 bit</option> >> + <option value='sha2_512' >> $checked{'ESP_INTEGRITY'}{'sha2_512'}>SHA2 512 bit >> ($Lang::tr{'recommended'})</option> >> <option value='sha2_384' >> $checked{'ESP_INTEGRITY'}{'sha2_384'}>SHA2 384 bit</option> >> <option value='sha2_256' >> $checked{'ESP_INTEGRITY'}{'sha2_256'}>SHA2 256 bit</option> >> <option value='aesxcbc' >> $checked{'ESP_INTEGRITY'}{'aesxcbc'}>AES >> XCBC</option> > > Same again. There seems to be a problem with the word "recommended". In the patches submitted, I recommended always the most strongest cipher. However, as you said, some of them are simply one step too much. Should then both be recommended? In my opinion, this has to be clarified, but since it is a very subjective thing, it might be difficult. > >> diff --git a/langs/de/cgi-bin/de.pl b/langs/de/cgi-bin/de.pl >> index 2bca854..b18cace 100644 >> --- a/langs/de/cgi-bin/de.pl >> +++ b/langs/de/cgi-bin/de.pl >> @@ -1914,6 +1914,7 @@ >> 'rebooting ipfire' => 'Starte IPFire neu', >> 'reconnect' => 'Neu Verbinden', >> 'reconnection' => 'Wiederverbindung', >> +'recommended' => 'empfohlen', >> 'red' => 'Internet', >> 'red1' => 'ROT', >> 'references' => 'Referenzen', >> >> > > The English translation is missing. Oh, sorry, I forgot. > > Best, > -Michael > Best regards, Timmothy Wilson
On Sun, 13 Dec 2015 16:10:13 +0100, IT Superhack <itsuperhack@web.de> wrote: > I am unable to submit patches at the moment, since git send-email keeps > crashing on every machine I own - sometimes starttls issues, sometimes > segfault - and TB seems to line-wrap. https://addons.mozilla.org/en-US/thunderbird/addon/toggle-word-wrap/ hth, Lars
On Sun, 2015-12-13 at 16:10 +0100, IT Superhack wrote: > Hello Michael, > > Michael Tremer: > > Hello, > > > > this patch was line-wrapped and cannot be merged, but nevertheless, > > here are my thoughts: > I am unable to submit patches at the moment, since git send-email > keeps > crashing on every machine I own - sometimes starttls issues, > sometimes > segfault - and TB seems to line-wrap. Weird that that happens. If you are using git on IPFire and experiencing these issues, please open a bug report. > > > > On Mon, 2015-12-07 at 17:35 +0100, IT Superhack wrote: > > > Signed-off-by: Timmothy Wilson <itsuperhack@web.de> > > > --- > > > diff --git a/html/cgi-bin/ovpnmain.cgi b/html/cgi > > > -bin/ovpnmain.cgi > > > index 62af54e..15385f1 100644 > > > --- a/html/cgi-bin/ovpnmain.cgi > > > +++ b/html/cgi-bin/ovpnmain.cgi > > > @@ -1316,7 +1316,7 @@ END > > > <option value='1024' > > > $selected{'DHLENGHT'}{'1024'}>1024 > > > $Lang::tr{'bit'}</option> > > > <option value='2048' > > > $selected{'DHLENGHT'}{'2048'}>2048 > > > $Lang::tr{'bit'}</option> > > > <option value='3072' > > > $selected{'DHLENGHT'}{'3072'}>3072 > > > $Lang::tr{'bit'}</option> > > > - <option value='4096' > > > $selected{'DHLENGHT'}{'4096'}>4096 > > > $Lang::tr{'bit'}</option> > > > + <option value='4096' > > > $selected{'DHLENGHT'}{'4096'}>4096 > > > $Lang::tr{'bit'} ($Lang::tr{'recommended'})</option> > > > </select> > > > </td> > > > </tr> > > > > I agree, that it is desirable to use longer keys. However, I am not > > sure if it is a good idea to go all the way for 4096 bit and not > > only > > for e.g. 2048 bit. Why not 8192 even? > > > Since the SSLTest server page treats 2048 DH primes as "weak", I > guess > 3072 or better is suitable here. > > I would like to read some justification for the values that are > > picked. > Here is one, for example: > https://netzpolitik.org/2015/kryptographie-open-source-und-gesellscha > ft/ > (german, please see "8."). In this article is also mentioned that 512 > bit hash algorithms should be used. > > > > Furthermore, I think that we the upper bound should be something > > that > > the average IPFire box is able to handle. > I agree with that. Maybe 3072 bits is a good deal between speed and > security, what do you think? That depends entirely on the hardware. We cannot know what people are using. That makes it rather complicated to decide. > > > > > @@ -4687,7 +4687,7 @@ if ($cgiparams{'TYPE'} eq 'net') { > > > <option value='CAMELLIA-256-CBC' > > > $selected{'DCIPHER'}{'CAMELLIA-256-CBC'}>CAMELLIA-CBC (256 > > > $Lang::tr{'bit'})</option> > > > <option value='CAMELLIA-192-CBC' > > > $selected{'DCIPHER'}{'CAMELLIA-192-CBC'}>CAMELLIA-CBC (192 > > > $Lang::tr{'bit'})</option> > > > <option value='CAMELLIA-128-CBC' > > > $selected{'DCIPHER'}{'CAMELLIA-128-CBC'}>CAMELLIA-CBC (128 > > > $Lang::tr{'bit'})</option> > > > - <option value='AES-256-CBC' > > > $selected{'DCIPHER'}{'AES-256-CBC'}>AES-CBC (256 > > > $Lang::tr{'bit'}, > > > $Lang::tr{'default'})</option> > > > + <option value='AES-256-CBC' > > > $selected{'DCIPHER'}{'AES-256-CBC'}>AES-CBC (256 > > > $Lang::tr{'bit'}, > > > $Lang::tr{'default'}, $Lang::tr{'recommended'})</option> > > > <option value='AES-192-CBC' > > > $selected{'DCIPHER'}{'AES-192-CBC'}>AES-CBC (192 > > > $Lang::tr{'bit'})</option> > > > <option value='AES-128-CBC' > > > $selected{'DCIPHER'}{'AES-128-CBC'}>AES-CBC (128 > > > $Lang::tr{'bit'})</option> > > > <option value='DES-EDE3-CBC' > > > $selected{'DCIPHER'}{'DES-EDE3-CBC'}>DES-EDE3-CBC (192 > > > $Lang::tr{'bit'})</option> > > > > I can agree with that since it is already selected by default. This > > makes it just more explicit. > > > > I would have merged this if this was an independent patch in a > > patch > > set. > Thanks, but at the moment, i cannot hand in a patch without wrapped > lines. For now you could push the git branch somewhere and I can pull that. Sending comments is difficult though, hence we do this on this list with patches. > > > > > @@ -4702,7 +4702,7 @@ if ($cgiparams{'TYPE'} eq 'net') { > > > <td class='boldbase'>$Lang::tr{'ovpn ha'}:</td> > > > <td><select name='DAUTH'> > > > <option value='whirlpool' > > > $selected{'DAUTH'}{'whirlpool'}>Whirlpool (512 > > > $Lang::tr{'bit'})</option> > > > - <option value='SHA512' > > > $selected{'DAUTH'}{'SHA512'}>SHA2 (512 > > > $Lang::tr{'bit'})</option> > > > + <option value='SHA512' > > > $selected{'DAUTH'}{'SHA512'}>SHA2 (512 > > > $Lang::tr{'bit'}, $Lang::tr{'recommended'})</option> > > > <option value='SHA384' > > > $selected{'DAUTH'}{'SHA384'}>SHA2 (384 > > > $Lang::tr{'bit'})</option> > > > <option value='SHA256' > > > $selected{'DAUTH'}{'SHA256'}>SHA2 (256 > > > $Lang::tr{'bit'})</option> > > > <option value='SHA1' > > > > > > $selected{'DAUTH'}{'SHA1'}>SHA1 (160 > > > $Lang::tr{'bit'} Default)</option> > > > > Same as above. SHA2 is considered to be "secure enough for now". > > Why is > > 256 bit not enough? This has also a rather huge performance impact. > > Things like these should also be mentioned in the commit message. > > > > > diff --git a/html/cgi-bin/vpnmain.cgi b/html/cgi-bin/vpnmain.cgi > > > index f1cffb8..9aa50f5 100644 > > > --- a/html/cgi-bin/vpnmain.cgi > > > +++ b/html/cgi-bin/vpnmain.cgi > > > @@ -2424,7 +2424,7 @@ if(($cgiparams{'ACTION'} eq > > > $Lang::tr{'advanced'}) || > > > <td>$Lang::tr{'vpn keyexchange'}:</td> > > > <td> > > > <select name='IKE_VERSION'> > > > - <option value='ikev2' > > > $selected{'IKE_VERSION'}{'ikev2'}>IKEv2</option> > > > + <option value='ikev2' > > > $selected{'IKE_VERSION'}{'ikev2'}>IKEv2 > > > ($Lang::tr{'recommended'})</option> > > > <option value='ikev1' > > > $selected{'IKE_VERSION'}{'ikev1'}>IKEv1</option> > > > </select> > > > </td> > > > > Why should IKEv2 be recommended? AFAIK there are no known design > > issues > > with IKEv1. Some algorithms might not be available, but this is not > > an > > issue for now since AES, SHA2, (AKA the strong ones) are supported. > > > > > @@ -2434,7 +2434,7 @@ if(($cgiparams{'ACTION'} eq > > > $Lang::tr{'advanced'}) || > > > <td class='boldbase' > > > width="15%">$Lang::tr{'encryption'}</td> > > > <td class='boldbase'> > > > <select name='IKE_ENCRYPTION' > > > multiple='multiple' size='6' > > > style='width: 100%'> > > > - <option > > > value='aes256gcm128' > > > $checked{'IKE_ENCRYPTION'}{'aes256gcm128'}>256 bit AES-GCM/128 > > > bit > > > ICV</option> > > > + <option > > > value='aes256gcm128' > > > $checked{'IKE_ENCRYPTION'}{'aes256gcm128'}>256 bit AES-GCM/128 > > > bit > > > ICV > > > ($Lang::tr{'recommended'})</option> > > > <option > > > value='aes256gcm96' > > > $checked{'IKE_ENCRYPTION'}{'aes256gcm96'}>256 bit AES-GCM/96 bit > > > ICV</option> > > > <option > > > value='aes256gcm64' > > > $checked{'IKE_ENCRYPTION'}{'aes256gcm64'}>256 bit AES-GCM/64 bit > > > ICV</option> > > > <option value='aes256' > > > $checked{'IKE_ENCRYPTION'}{'aes256'}>256 > > > bit AES-CBC</option> > > > @@ -2454,7 +2454,7 @@ if(($cgiparams{'ACTION'} eq > > > $Lang::tr{'advanced'}) || > > > </td> > > > <td class='boldbase'> > > > <select name='ESP_ENCRYPTION' > > > multiple='multiple' size='6' > > > style='width: 100%'> > > > - <option > > > value='aes256gcm128' > > > $checked{'ESP_ENCRYPTION'}{'aes256gcm128'}>256 bit AES-GCM/128 > > > bit > > > ICV</option> > > > + <option > > > value='aes256gcm128' > > > $checked{'ESP_ENCRYPTION'}{'aes256gcm128'}>256 bit AES-GCM/128 > > > bit > > > ICV > > > ($Lang::tr{'recommended'})</option> > > > <option > > > value='aes256gcm96' > > > $checked{'ESP_ENCRYPTION'}{'aes256gcm96'}>256 bit AES-GCM/96 bit > > > ICV</option> > > > <option > > > value='aes256gcm64' > > > $checked{'ESP_ENCRYPTION'}{'aes256gcm64'}>256 bit AES-GCM/64 bit > > > ICV</option> > > > <option value='aes256' > > > $checked{'ESP_ENCRYPTION'}{'aes256'}>256 > > > bit AES-CBC</option> > > > > Why are the AES-GCM cipher suites with smaller IVs not recommended? > > > > > @@ -2478,7 +2478,7 @@ if(($cgiparams{'ACTION'} eq > > > $Lang::tr{'advanced'}) || > > > <td class='boldbase' > > > width="15%">$Lang::tr{'integrity'}</td> > > > <td class='boldbase'> > > > <select name='IKE_INTEGRITY' > > > multiple='multiple' size='6' > > > style='width: 100%'> > > > - <option value='sha2_512' > > > $checked{'IKE_INTEGRITY'}{'sha2_512'}>SHA2 512 bit</option> > > > + <option value='sha2_512' > > > $checked{'IKE_INTEGRITY'}{'sha2_512'}>SHA2 512 bit > > > ($Lang::tr{'recommended'})</option> > > > <option value='sha2_384' > > > $checked{'IKE_INTEGRITY'}{'sha2_384'}>SHA2 384 bit</option> > > > <option value='sha2_256' > > > $checked{'IKE_INTEGRITY'}{'sha2_256'}>SHA2 256 bit</option> > > > <option value='aesxcbc' > > > $checked{'IKE_INTEGRITY'}{'aesxcbc'}>AES > > > XCBC</option> > > > > Same as above. > > > > > @@ -2488,7 +2488,7 @@ if(($cgiparams{'ACTION'} eq > > > $Lang::tr{'advanced'}) || > > > </td> > > > <td class='boldbase'> > > > <select name='ESP_INTEGRITY' > > > multiple='multiple' size='6' > > > style='width: 100%'> > > > - <option value='sha2_512' > > > $checked{'ESP_INTEGRITY'}{'sha2_512'}>SHA2 512 bit</option> > > > + <option value='sha2_512' > > > $checked{'ESP_INTEGRITY'}{'sha2_512'}>SHA2 512 bit > > > ($Lang::tr{'recommended'})</option> > > > <option value='sha2_384' > > > $checked{'ESP_INTEGRITY'}{'sha2_384'}>SHA2 384 bit</option> > > > <option value='sha2_256' > > > $checked{'ESP_INTEGRITY'}{'sha2_256'}>SHA2 256 bit</option> > > > <option value='aesxcbc' > > > $checked{'ESP_INTEGRITY'}{'aesxcbc'}>AES > > > XCBC</option> > > > > Same again. > There seems to be a problem with the word "recommended". In the > patches > submitted, I recommended always the most strongest cipher. However, > as > you said, some of them are simply one step too much. Should then both > be > recommended? I am not sure. Can anyone come up with a more fitting expression? If we mark everything as "recommended" that is strong enough for now after our consideration, we will have most of them tagged with that word. In that case it would make more sense to mark the weak stuff as such to keep readability. Maybe that is the way to go. But does the average Joe know what is meant by "weak"? > In my opinion, this has to be clarified, but since it is a very > subjective thing, it might be difficult. It is not really just subjective. We can say for sure that some ciphers and hashes are broken. We can also say that some are weak and will be considered broken soon. That is pretty much objective since we have sources for that. If only enough people agree that X is broken or weak, that is pretty much a fact. The recommendation though is more complicated because I would like to take into account how feasible it is to use a certain cipher/hash/etc. RSA with 8192 bits long keys is quite nice. We can assume that it is more secure than RSA with a 4096 bits long key if it was generated from true random numbers. However handshakes will take longer. Generating the key will take weeks on some systems. I want this to be reflected by this change. Please feel free to disagree with me on this :) Can we get more people to send their thoughts on this? > > > > > diff --git a/langs/de/cgi-bin/de.pl b/langs/de/cgi-bin/de.pl > > > index 2bca854..b18cace 100644 > > > --- a/langs/de/cgi-bin/de.pl > > > +++ b/langs/de/cgi-bin/de.pl > > > @@ -1914,6 +1914,7 @@ > > > 'rebooting ipfire' => 'Starte IPFire neu', > > > 'reconnect' => 'Neu Verbinden', > > > 'reconnection' => 'Wiederverbindung', > > > +'recommended' => 'empfohlen', > > > 'red' => 'Internet', > > > 'red1' => 'ROT', > > > 'references' => 'Referenzen', > > > > > > > > > > The English translation is missing. > Oh, sorry, I forgot. > > > > Best, > > -Michael > > > Best regards, > Timmothy Wilson > -Michael
>> > Furthermore, I think that we the upper bound should be something >> > that >> > the average IPFire box is able to handle. >> I agree with that. Maybe 3072 bits is a good deal between speed and >> security, what do you think? > > That depends entirely on the hardware. We cannot know what people are > using. That makes it rather complicated to decide. Is there a way to present the users a message and let them decide which length they want to use? >> There seems to be a problem with the word "recommended". In the >> patches >> submitted, I recommended always the most strongest cipher. However, >> as >> you said, some of them are simply one step too much. Should then both >> be >> recommended? > > I am not sure. Can anyone come up with a more fitting expression? If we > mark everything as "recommended" that is strong enough for now after > our consideration, we will have most of them tagged with that word. In > that case it would make more sense to mark the weak stuff as such to > keep readability. Maybe that is the way to go. But does the average Joe > know what is meant by "weak"? Joe should know enough that "weak" is normally not what is wanted. Otherwise he should RTFM ;-) You could recommend the strongest cipher that would take an attacker millions of years to break, but on the other hand force the hardware to burn its CPU, while another "not as strong as the recommended one" cipher would also take an attacker thousands of years, but not consume that much CPU. Would have to differentiate between "recommended for high performance CPU" and "recommended for your small box". So, that doesn't sound good. Weak is weak for every kind of hardware. So +1 for "weak". Lars
On Tue, 2015-12-15 at 16:03 +0100, Larsen wrote: > > > > Furthermore, I think that we the upper bound should be > > > > something > > > > that > > > > the average IPFire box is able to handle. > > > I agree with that. Maybe 3072 bits is a good deal between speed > > > and > > > security, what do you think? > > > > That depends entirely on the hardware. We cannot know what people > > are > > using. That makes it rather complicated to decide. > > Is there a way to present the users a message and let them decide > which > length they want to use? Yes, the user has to decide this at some occasions. > > > > > > There seems to be a problem with the word "recommended". In the > > > patches > > > submitted, I recommended always the most strongest cipher. > > > However, > > > as > > > you said, some of them are simply one step too much. Should then > > > both > > > be > > > recommended? > > > > I am not sure. Can anyone come up with a more fitting expression? > > If we > > mark everything as "recommended" that is strong enough for now > > after > > our consideration, we will have most of them tagged with that word. > > In > > that case it would make more sense to mark the weak stuff as such > > to > > keep readability. Maybe that is the way to go. But does the average > > Joe > > know what is meant by "weak"? > > Joe should know enough that "weak" is normally not what is wanted. > Otherwise he should RTFM ;-) > > You could recommend the strongest cipher that would take an attacker > millions of years to break, but on the other hand force the hardware > to > burn its CPU, while another "not as strong as the recommended one" > cipher > would also take an attacker thousands of years, but not consume that > much > CPU. It is always about the tradeoffs. If we didn't have to do these we wouldn't have AES. We would only use OTP. > Would have to differentiate between "recommended for high performance > > CPU" and "recommended for your small box". So, that doesn't sound > good. That doesn't sound good at all because it is not really the case that there is such a big difference between the throughput of some of the algorithms. The right thing would be to upgrade the hardware and keep the strong security. > > Weak is weak for every kind of hardware. So +1 for "weak". If we have "weak". Should we have "broken", too? For example we have to support MD5. I wouldn't say that MD5 is weak. It is more than that. > > > Lars -Michael
>> Weak is weak for every kind of hardware. So +1 for "weak". > > If we have "weak". Should we have "broken", too? For example we have to > support MD5. I wouldn't say that MD5 is weak. It is more than that. If we need to support it, it should be "broken", yes. Lars
Hello Michael, hello Larsen, sorry for not replying a while; xmas is always very busy >>> There seems to be a problem with the word "recommended". In the >>> patches >>> submitted, I recommended always the most strongest cipher. >>> However, >>> as >>> you said, some of them are simply one step too much. Should then >>> both >>> be >>> recommended? >> >> I am not sure. Can anyone come up with a more fitting expression? >> If we >> mark everything as "recommended" that is strong enough for now >> after >> our consideration, we will have most of them tagged with that word. >> In >> that case it would make more sense to mark the weak stuff as such >> to >> keep readability. Maybe that is the way to go. But does the average >> Joe >> know what is meant by "weak"? > > Joe should know enough that "weak" is normally not what is wanted. > Otherwise he should RTFM > > You could recommend the strongest cipher that would take an attacker > millions of years to break, but on the other hand force the hardware > to > burn its CPU, while another "not as strong as the recommended one" > cipher > would also take an attacker thousands of years, but not consume that > much > CPU. Maybe it is better to mark just the weak or broken entries. I agree, "recommended" is not very specific here - maybe "strongest" would be better. Especially to mark AES-256-CBC on the OpenVPN main page. > > If we have "weak". Should we have "broken", too? For example we have to > support MD5. I wouldn't say that MD5 is weak. It is more than that. Okay, so we have: MD5 "broken" SHA1 "weak" DH-1024-params "broken" (? not sure about this) DH-2048-params "weak" AES-256-CBC "recommended"/"strongest" (on OpenVPN page only) Do you think this is a good way to start? If yes, I could send in some patches. > > Why should IKEv2 be recommended? AFAIK there are no known design issues > with IKEv1. Some algorithms might not be available, but this is not an > issue for now since AES, SHA2, (AKA the strong ones) are supported. @Michael: That is correct, I did not RTFM. o:-) Looking forward to hear from you. Happy new year! Best regards, Timmothy Wilson
Hi all, and for the first a good new year to you all. > > I agree, that it is desirable to use longer keys. However, I am not > sure if it is a good idea to go all the way for 4096 bit and not only > for e.g. 2048 bit. Why not 8192 even? > > I would like to read some justification for the values that are picked. > > Furthermore, I think that we the upper bound should be something that > the average IPFire box is able to handle. tried that now with OpenVPN whereby i added a flip menu in the 'Generate Root/Host Certificate' section as it is for the Diffie-Hellman parameter so the keylengths aren´t hardcoded anymore and can be configured by the user. Added for the root CA 4096, 8192 and 16348 tit lengths selection possibilities and for the host CA 2048, 4096, 8192 and also 16348 bit. The configured keylength for the host CA was also used for the control channel. The Root CA generation took 31 minutes for a 16348 bit keylength, the Host CA 12 minutes for 8192 bit and a 1024 bit DH-parameter needed 2 minutes which is in summary ~ 45 minutes. The generation time differs also on every generation. The creation of a new client PKCS#12 package for 8192 bit needed 3 minutes. The key exchange with a Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 8192 bit RSA needed 10 sec. All tests was made with a JNC9C --> http://fireinfo.ipfire.org/profile/72d11e77621ec66ea75d39e3c9b10025e746e5af and without HWRNG or PRNG . If someone is interested in a ovpnmain.cgi diff and/or more testing results let it me know. Greetings, Erik
Hello and happy new year, On Fri, 2016-01-01 at 17:54 +0100, IT Superhack wrote: > Hello Michael, hello Larsen, > > sorry for not replying a while; xmas is always very busy Same. > > > > There seems to be a problem with the word "recommended". In the > > > > patches > > > > submitted, I recommended always the most strongest cipher. > > > > However, > > > > as > > > > you said, some of them are simply one step too much. Should > > > > then > > > > both > > > > be > > > > recommended? > > > > > > I am not sure. Can anyone come up with a more fitting expression? > > > If we > > > mark everything as "recommended" that is strong enough for now > > > after > > > our consideration, we will have most of them tagged with that > > > word. > > > In > > > that case it would make more sense to mark the weak stuff as such > > > to > > > keep readability. Maybe that is the way to go. But does the > > > average > > > Joe > > > know what is meant by "weak"? > > > > Joe should know enough that "weak" is normally not what is wanted. > > Otherwise he should RTFM > > > > You could recommend the strongest cipher that would take an > > attacker > > millions of years to break, but on the other hand force the > > hardware > > to > > burn its CPU, while another "not as strong as the recommended one" > > cipher > > would also take an attacker thousands of years, but not consume > > that > > much > > CPU. > Maybe it is better to mark just the weak or broken entries. I agree, > "recommended" is not very specific here - maybe "strongest" would be > better. Especially to mark AES-256-CBC on the OpenVPN main page. Using "strongest" is a very good idea. As mentioned earlier it is hard to tell if an algorithm is good or bad, but we can rank them based on key sizes, etc. And in the end there will be a "strongest" cipher. That is still as subjective as "weak" is, but I think it is easy to understand for every user. > > If we have "weak". Should we have "broken", too? For example we > > have to > > support MD5. I wouldn't say that MD5 is weak. It is more than that. > Okay, so we have: > MD5 "broken" > SHA1 "weak" > DH-1024-params "broken" (? not sure about this) > DH-2048-params "weak" > AES-256-CBC "recommended"/"strongest" (on OpenVPN page only) > > Do you think this is a good way to start? If yes, I could send in > some > patches. I can agree on this with all the labels except "broken" for DH-1024. It works and it makes sense to use this for short-lived keys. It should be avoided if we can, so I would suggest "very weak". I think we can label AES-256-GCM as "strongest" on the IPsec page, too. > > > > > Why should IKEv2 be recommended? AFAIK there are no known design > > issues > > with IKEv1. Some algorithms might not be available, but this is not > > an > > issue for now since AES, SHA2, (AKA the strong ones) are supported. > @Michael: That is correct, I did not RTFM. o:-) > > Looking forward to hear from you. Happy new year! > > Best regards, > Timmothy Wilson Best, -Michael >
Hi, On Sat, 2016-01-02 at 14:03 +0100, ue wrote: > Hi all, > and for the first a good new year to you all. > > > > I agree, that it is desirable to use longer keys. However, I am not > > sure if it is a good idea to go all the way for 4096 bit and not > > only > > for e.g. 2048 bit. Why not 8192 even? > > > > I would like to read some justification for the values that are > > picked. > > > > Furthermore, I think that we the upper bound should be something > > that > > the average IPFire box is able to handle. > > > tried that now with OpenVPN whereby i added a flip menu in the > 'Generate Root/Host Certificate' section as it is for the Diffie > -Hellman parameter so the keylengths aren´t hardcoded anymore and can > be configured by the user. Added for the root CA 4096, 8192 and 16348 > tit lengths selection possibilities and for the host CA 2048, 4096, > 8192 and also 16348 bit. The configured keylength for the host CA was > also used for the control channel. Is it even possible to use arbitrary key lengths with OpenVPN? 16k is really really long. > The Root CA generation took 31 minutes for a 16348 bit keylength, the > Host CA 12 minutes for 8192 bit and a 1024 bit DH-parameter needed 2 > minutes which is in summary ~ 45 minutes. The generation time differs > also on every generation. > The creation of a new client PKCS#12 package for 8192 bit needed 3 > minutes. > The key exchange with a Control Channel: TLSv1.2, cipher TLSv1/SSLv3 > DHE-RSA-AES256-GCM-SHA384, 8192 bit RSA needed 10 sec. This sounds increadible fast to me. We had devices on which that took way longer. I have recently seen a talk about using /dev/urandom instead. This is probably worth a watch: https://www.youtube.com/watch?v=Q8JAlZ-HJQI > > All tests was made with a JNC9C --> http://fireinfo.ipfire.org/profil > e/72d11e77621ec66ea75d39e3c9b10025e746e5af and without HWRNG or PRNG > . > > If someone is interested in a ovpnmain.cgi diff and/or more testing > results let it me know. You can post it as a patch on here and add a note that this is for testing only and not (yet?) intended to be merged. > > > Greetings, > > Erik Best, -Michael
Hi Michael, Michael Tremer: > Hello and happy new year, > > On Fri, 2016-01-01 at 17:54 +0100, IT Superhack wrote: >> Hello Michael, hello Larsen, >> >> sorry for not replying a while; xmas is always very busy > > Same. > >>>>> There seems to be a problem with the word "recommended". In the >>>>> patches >>>>> submitted, I recommended always the most strongest cipher. >>>>> However, >>>>> as >>>>> you said, some of them are simply one step too much. Should >>>>> then >>>>> both >>>>> be >>>>> recommended? >>>> >>>> I am not sure. Can anyone come up with a more fitting expression? >>>> If we >>>> mark everything as "recommended" that is strong enough for now >>>> after >>>> our consideration, we will have most of them tagged with that >>>> word. >>>> In >>>> that case it would make more sense to mark the weak stuff as such >>>> to >>>> keep readability. Maybe that is the way to go. But does the >>>> average >>>> Joe >>>> know what is meant by "weak"? >>> >>> Joe should know enough that "weak" is normally not what is wanted. >>> Otherwise he should RTFM >>> >>> You could recommend the strongest cipher that would take an >>> attacker >>> millions of years to break, but on the other hand force the >>> hardware >>> to >>> burn its CPU, while another "not as strong as the recommended one" >>> cipher >>> would also take an attacker thousands of years, but not consume >>> that >>> much >>> CPU. >> Maybe it is better to mark just the weak or broken entries. I agree, >> "recommended" is not very specific here - maybe "strongest" would be >> better. Especially to mark AES-256-CBC on the OpenVPN main page. > > Using "strongest" is a very good idea. As mentioned earlier it is hard > to tell if an algorithm is good or bad, but we can rank them based on > key sizes, etc. And in the end there will be a "strongest" cipher. Hmmm, what about CAMELLIA at the IPsec page? As far as I know, it is not weaker or stronger than AES, but slower and there aren't any GCM modes available. > > That is still as subjective as "weak" is, but I think it is easy to > understand for every user. Yup. > >>> If we have "weak". Should we have "broken", too? For example we >>> have to >>> support MD5. I wouldn't say that MD5 is weak. It is more than that. >> Okay, so we have: >> MD5 "broken" >> SHA1 "weak" >> DH-1024-params "broken" (? not sure about this) >> DH-2048-params "weak" >> AES-256-CBC "recommended"/"strongest" (on OpenVPN page only) >> >> Do you think this is a good way to start? If yes, I could send in >> some >> patches. > > I can agree on this with all the labels except "broken" for DH-1024. It > works and it makes sense to use this for short-lived keys. It should be > avoided if we can, so I would suggest "very weak". Okay. > > I think we can label AES-256-GCM as "strongest" on the IPsec page, too. 1. As above, what about CAMELLIA? 2. Which AES-256-GCM suite is the strongest one? (128/96/64 bits ICV?) > >> >>> >>> Why should IKEv2 be recommended? AFAIK there are no known design >>> issues >>> with IKEv1. Some algorithms might not be available, but this is not >>> an >>> issue for now since AES, SHA2, (AKA the strong ones) are supported. >> @Michael: That is correct, I did not RTFM. o:-) >> >> Looking forward to hear from you. Happy new year! >> >> Best regards, >> Timmothy Wilson > > Best, > -Michael Best regards, Timmothy Wilson
Hi, On Sun, 2016-01-10 at 17:29 +0100, IT Superhack wrote: > Hi Michael, > > Michael Tremer: > > Hello and happy new year, > > > > On Fri, 2016-01-01 at 17:54 +0100, IT Superhack wrote: > > > Hello Michael, hello Larsen, > > > > > > sorry for not replying a while; xmas is always very busy > > > > Same. > > > > > > > > There seems to be a problem with the word "recommended". In > > > > > > the > > > > > > patches > > > > > > submitted, I recommended always the most strongest cipher. > > > > > > However, > > > > > > as > > > > > > you said, some of them are simply one step too much. Should > > > > > > then > > > > > > both > > > > > > be > > > > > > recommended? > > > > > > > > > > I am not sure. Can anyone come up with a more fitting > > > > > expression? > > > > > If we > > > > > mark everything as "recommended" that is strong enough for > > > > > now > > > > > after > > > > > our consideration, we will have most of them tagged with that > > > > > word. > > > > > In > > > > > that case it would make more sense to mark the weak stuff as > > > > > such > > > > > to > > > > > keep readability. Maybe that is the way to go. But does the > > > > > average > > > > > Joe > > > > > know what is meant by "weak"? > > > > > > > > Joe should know enough that "weak" is normally not what is > > > > wanted. > > > > Otherwise he should RTFM > > > > > > > > You could recommend the strongest cipher that would take an > > > > attacker > > > > millions of years to break, but on the other hand force the > > > > hardware > > > > to > > > > burn its CPU, while another "not as strong as the recommended > > > > one" > > > > cipher > > > > would also take an attacker thousands of years, but not consume > > > > that > > > > much > > > > CPU. > > > Maybe it is better to mark just the weak or broken entries. I > > > agree, > > > "recommended" is not very specific here - maybe "strongest" would > > > be > > > better. Especially to mark AES-256-CBC on the OpenVPN main page. > > > > Using "strongest" is a very good idea. As mentioned earlier it is > > hard > > to tell if an algorithm is good or bad, but we can rank them based > > on > > key sizes, etc. And in the end there will be a "strongest" cipher. > Hmmm, what about CAMELLIA at the IPsec page? As far as I know, it is > not weaker or stronger than AES, but slower and there aren't any GCM > modes available. I think that camellia is slower is just marketing or something like that. On my machine it is actually *a lot* faster than AES. This machine does not have AES-NI, but even on those machines CAMELLIA benefits from AES-NI. [ms@rice-oxley ~]$ openssl speed {aes,camellia}-256-cbc Doing aes-256 cbc for 3s on 16 size blocks: 14349124 aes-256 cbc's in 2.99s Doing aes-256 cbc for 3s on 64 size blocks: 3813409 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 256 size blocks: 969069 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 1024 size blocks: 243184 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 8192 size blocks: 30436 aes-256 cbc's in 3.01s Doing camellia-256 cbc for 3s on 16 size blocks: 16332000 camellia-256 cbc's in 3.00s Doing camellia-256 cbc for 3s on 64 size blocks: 5406041 camellia-256 cbc's in 2.99s Doing camellia-256 cbc for 3s on 256 size blocks: 1471399 camellia-256 cbc's in 3.00s Doing camellia-256 cbc for 3s on 1024 size blocks: 376682 camellia-256 cbc's in 3.00s Doing camellia-256 cbc for 3s on 8192 size blocks: 47506 camellia-256 cbc's in 3.00s OpenSSL 1.0.1k-fips 8 Jan 2015 built on: Fri Dec 4 15:45:46 2015 options:bn(64,64) md2(int) rc4(16x,int) des(idx,cisc,16,int) aes(partial) idea(int) blowfish(idx) compiler: -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -m64 -DL_ENDIAN -DTERMIO -Wall -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -Wa,--noexecstack -DPURIFY -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-256 cbc 76784.61k 81352.73k 82693.89k 83006.81k 82834.46k camellia-256 cbc 87104.00k 115714.59k 125559.38k 128574.12k 129723.05k 3DES is very slow though: [ms@rice-oxley ~]$ openssl speed des-ede3 Doing des ede3 for 3s on 16 size blocks: 5230784 des ede3's in 3.00s Doing des ede3 for 3s on 64 size blocks: 1328063 des ede3's in 3.00s Doing des ede3 for 3s on 256 size blocks: 333500 des ede3's in 2.99s Doing des ede3 for 3s on 1024 size blocks: 83474 des ede3's in 3.00s Doing des ede3 for 3s on 8192 size blocks: 10474 des ede3's in 3.00s OpenSSL 1.0.1k-fips 8 Jan 2015 built on: Fri Dec 4 15:45:46 2015 options:bn(64,64) md2(int) rc4(16x,int) des(idx,cisc,16,int) aes(partial) idea(int) blowfish(idx) compiler: -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -m64 -DL_ENDIAN -DTERMIO -Wall -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -Wa,--noexecstack -DPURIFY -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes des ede3 27897.51k 28332.01k 28553.85k 28492.46k 28601.00k > > > > That is still as subjective as "weak" is, but I think it is easy to > > understand for every user. > Yup. > > > > > > If we have "weak". Should we have "broken", too? For example we > > > > have to > > > > support MD5. I wouldn't say that MD5 is weak. It is more than > > > > that. > > > Okay, so we have: > > > MD5 "broken" > > > SHA1 "weak" > > > DH-1024-params "broken" (? not sure about this) > > > DH-2048-params "weak" > > > AES-256-CBC "recommended"/"strongest" (on OpenVPN page > > > only) > > > > > > Do you think this is a good way to start? If yes, I could send in > > > some > > > patches. > > > > I can agree on this with all the labels except "broken" for DH > > -1024. It > > works and it makes sense to use this for short-lived keys. It > > should be > > avoided if we can, so I would suggest "very weak". > Okay. > > > > I think we can label AES-256-GCM as "strongest" on the IPsec page, > > too. > 1. As above, what about CAMELLIA? I consider CAMELLIA just as strong as AES. It might have benefits over AES even. However I consider the GCM cipher mode to be safer (and usually faster) than CBC which puts those into an order. > 2. Which AES-256-GCM suite is the strongest one? (128/96/64 bits > ICV?) If you have good random numbers a longer IV should be better. I don't think that that makes a huge difference though. > > > > > > > > > > > > > Why should IKEv2 be recommended? AFAIK there are no known > > > > design > > > > issues > > > > with IKEv1. Some algorithms might not be available, but this is > > > > not > > > > an > > > > issue for now since AES, SHA2, (AKA the strong ones) are > > > > supported. > > > @Michael: That is correct, I did not RTFM. o:-) > > > > > > Looking forward to hear from you. Happy new year! > > > > > > Best regards, > > > Timmothy Wilson > > > > Best, > > -Michael > Best regards, > Timmothy Wilson > >