From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: [PATCH] Mark recommended ciphers/algorithms Date: Sun, 10 Jan 2016 22:22:43 +0000 Message-ID: <1452464563.5665.19.camel@ipfire.org> In-Reply-To: <569286F2.2030904@web.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1641519608844587433==" List-Id: --===============1641519608844587433== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, On Sun, 2016-01-10 at 17:29 +0100, IT Superhack wrote: > Hi Michael, >=20 > Michael Tremer: > > Hello and happy new year, > >=20 > > On Fri, 2016-01-01 at 17:54 +0100, IT Superhack wrote: > > > Hello Michael, hello Larsen, > > >=20 > > > sorry for not replying a while; xmas is always very busy > >=20 > > Same. > >=20 > > > > > > 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? > > > > >=20 > > > > > 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"? > > > >=20 > > > > Joe should know enough that "weak" is normally not what is > > > > wanted.=20 > > > > Otherwise he should RTFM=20 > > > >=20 > > > > You could recommend the strongest cipher that would take an > > > > attacker=20 > > > > millions of years to break, but on the other hand force the > > > > hardware > > > > to =20 > > > > burn its CPU, while another "not as strong as the recommended > > > > one" > > > > cipher =20 > > > > would also take an attacker thousands of years, but not consume > > > > that > > > > much =20 > > > > 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. > >=20 > > 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(a)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 i= n 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 i= n 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) ide= a(int) blowfish(idx)=20 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=3Dformat-security -Wp,-D_FORTIFY_SOURCE=3D2 = -fexceptions -fstack-protector-strong --param=3Dssp-buffer-size=3D4 -grecord-= gcc-switches -m64 -mtune=3Dgeneric -Wa,--noexecstack -DPURIFY -DOPENSSL_IA32= _SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSH= A1_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(a)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) ide= a(int) blowfish(idx)=20 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=3Dformat-security -Wp,-D_FORTIFY_SOURCE=3D2 = -fexceptions -fstack-protector-strong --param=3Dssp-buffer-size=3D4 -grecord-= gcc-switches -m64 -mtune=3Dgeneric -Wa,--noexecstack -DPURIFY -DOPENSSL_IA32= _SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSH= A1_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 > >=20 > > That is still as subjective as "weak" is, but I think it is easy to > > understand for every user. > Yup. > >=20 > > > > 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) > > >=20 > > > Do you think this is a good way to start? If yes, I could send in > > > some > > > patches. > >=20 > > 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. > >=20 > > 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. > >=20 > > >=20 > > > >=20 > > > > 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:-) > > >=20 > > > Looking forward to hear from you. Happy new year! > > >=20 > > > Best regards, > > > Timmothy Wilson > >=20 > > Best, > > -Michael > Best regards, > Timmothy Wilson >=20 >=20 --===============1641519608844587433== Content-Type: application/pgp-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" MIME-Version: 1.0 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEKCmlRSWNCQUFC Q2dBR0JRSldrdG16QUFvSkVJQjU4UDl2a0FrSEIvZ1FBTFZsd0VDRmhHdklRSS9neEk1dGM5L1cK QVVCQTlsSHE4bVFFY05weXgwelIwT21YckVLdmpSeWNkOThQakIxUUJUNFA2WlBpcWRnR2daL3cr QzIrNFhhMwpFcDk4VTBYRHAwZEpiVGF1eVd3NEkxbDMxQjRKYWloWFV4OUQzQmRudS9Qc01pSy9N MXAwcFdZMktsekluMEttClJoR3NUVXR2NXZJVU9rT0tJNmpkNEVXSnlZQlU4eTFmRHhTL0xWY0w5 ckJqWkovWXB4WjdFOUZHUnFRM3BrUGIKckRZWEVFM0lHR0xVRXpqeUJ3eVk2QlFJRmJnSGVFeE11 NTBOUFZqdmZTUHhOejhOMmpvUVVzYjhtd2k4a2UzTQpvMGZHR0RsT3BQbEJua2Z5S2JsYVJjSktX NHJXYW5wUitRbVk3NHU5VU42TFpncyszRDBQa2RMRjczbzZZcHpECkFJaStWRjJUK1lZbjZKMlJZ bm9ZYmFEWmx1cmtnbFhIZU5yQ1NwTFlJSzkzKzlUaVlmckdHU0gvVDFyODU3VWsKM1YxbUJmTytE OHhwZGZsV1E5c1VyZEZUNWJBUjF0Ym1BaUIyU3laZk4yL3FNTGl5cDRTUG5LaGxLcUNnU3lJOQpU d3ZnK2lXRWVPbS96U1BuMkpFN1lXMUUzdWcrbmthTDVVaDBvVmVJVlF1THhHU3FydVlvTzhuWlll M1NYK25qClZMWEorYTYybnMrWlRyNDkyNDdkZW03Wlcvb0xRMW1SejUwd2xWMm0wUFNUYzJDTFZt V2hIM1I3OFFqdC8vcGYKZ0VYOWZHb2V0Nk85bHNKN2hBaFYrQys2WlNGSUErV2g1UmNQTmI0bXdo RU5tZzFJVGtWNFVCenkrWnk0dS81YwoyUHZnVFlsWG9aTnZseGZlRjFzMQo9UFQwcgotLS0tLUVO RCBQR1AgU0lHTkFUVVJFLS0tLS0K --===============1641519608844587433==--