From mboxrd@z Thu Jan 1 00:00:00 1970 From: IT Superhack To: development@lists.ipfire.org Subject: Re: [PATCH] Mark recommended ciphers/algorithms Date: Sun, 10 Jan 2016 17:29:38 +0100 Message-ID: <569286F2.2030904@web.de> In-Reply-To: <1451925110.31655.257.camel@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3269135805959476922==" List-Id: --===============3269135805959476922== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit 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 --===============3269135805959476922== Content-Type: application/pgp-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" MIME-Version: 1.0 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KCmlRRWNCQUVCQ2dBR0JRSldrb2J5QUFvSkVP eUxhMUM1RWF6ckVkb0gvMDRpemR2WFhXYXFlekJiWDR3THBocEYKVlVTN1JDZDd5WDFlQ0RNaUZM UkhadVNaTWlGSHo0WlRkS3hxdmp0aFloZnhkQXpjV1Y5cVlwT01wVGltaDJ6cgp5NGdKUDlBNklv enhKMTBrUitJU1dCQ1VQQS82dk9oVngrMU14MjRQck5qdHdHWnpYaWs4bVptTU9LZWZYRTR1Cmwv cUJnbmQrSkdIdHpHUWcvaWYzMnA3d2I5VnoxeDl1cUNiZzNLdkpzZi81aVdJVmxaZlc4ZkFyUDc0 RzFWYkYKaXRFRC9GYWZmUkJCd3NsQWh0WG5wTlFZVnVreEZiNlhFclFhSENlV2pMZTZSZnpQYVhB RDRwMjU1ZC9qdkNkcgp5WThhNERkQmsycGRzN3Q3YXlDcEtDTVNRQkQyeWVKekJ3Nm40dnp5RHIr aGNkUDNacTFFT3V1My9pUmVVSzg9Cj1wTkpTCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQo= --===============3269135805959476922==--