Re: [PATCH] Mark recommended ciphers/algorithms

[IT Superhack <itsuperhack@web.de>]

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

Hello Michael, hello Larsen,

sorry for not replying a while; xmas is always very busy

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

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

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


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