[Ach] Vote for new Cipherstring B [Was: Issue with OpenSSL >0.9.8l]
iang at iang.org
Wed Jun 4 13:45:10 CEST 2014
On 3/06/2014 22:00 pm, christian mock wrote:
> OK, just trying to bring this up after today's meeting -- can we find
> an agreement on the "drop AES/CAMELLIA 256" issue? And if we do, can
> we also drop SHA384, to further simplify the cipher string?
> My vote: drop *256 and SHA384.
Drop AES256, Camelia*, SHA384++ would be my vote.
Notes: If you must have a 'B' as well as an 'A' then might as well
bifurcate around AES length. This is all within a temporary moment in
time while we wait for new EC curves, chacha/poly and CAESAR. What is
good enough for most is good enough.
> On Tue, May 13, 2014 at 08:31:48PM +0200, Aaron Zauner wrote:
>> Ok, I've come up with the following B cipherstring:
>> This works for all versions that I've tested (0.9.8+).
>> Another issue I'd like to discuss:
>> There's still a thing that bothers me a bit, we're using AES256
>> everywhere, there are very little devices that will not support this,
>> which means that either:
>> - we can get rid of AES128 completely
>> - we can get rid of AES256 completely
>> I'd opt for the second option, we sill have a A cipherstring that serves
>> only AES256, there's really no need to have it in our B cipherstring.
>> Even if quantum computers become a reality (which is unlikely for the
>> next decades - but don't believe me, hear it from schneier ) AES128
>> provides around (2^128)/2 security (brute force in a quantum computer)
>> . This would also shorten our cipherstring and as such make it
>> possible for use in software that has a restricted character limit for a
>> cipherstring option (such as OpenVPN).
>> Any input on that? I don't think it does weaken our B recommendation -
>> it simplifies it.
>>  https://www.youtube.com/watch?v=hSFgHVTWq0w#t=2638
>> Ach mailing list
>> Ach at lists.cert.at
More information about the Ach