Re: [PATCH] Mark recommended ciphers/algorithms

[IT Superhack <itsuperhack@web.de>]

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

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



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