Re: [PATCH] Mark recommended ciphers/algorithms

[Michael Tremer <michael.tremer@ipfire.org>]

[-- Attachment #1: Type: text/plain, Size: 7919 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]