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.
- 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.
- 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