[Ach] Modernizing Cipherstrings (once again) [Re: Looks

Aaron Zauner azet at azet.org
Sun Mar 6 09:15:25 CET 2016


like
 SSLv3 is enabled for httpd in spec?]
Message-ID: <20160306090225.c68ce12825 at 37545b1a29b4c14>
Reply-To: 
In-Reply-To: <20160304203609.GF22007 at kriegisch.at>

* Adi Kriegisch <adi at kriegisch.at> [04/03/2016 21:36:16] wrote:
> Hi!
> 
> > > I'm not exactly sure what the camellia crap is doing there and
> > > this
> > > looks fishy and overly complicated to me in many ways, but
> > > anyway:
> > Because - you know - what if AES is backdoored by NSA or
> > something.
> Oh well... It all began with removing weak ciphers; at the time
> the ecrypt
> paper stated that CAMELLIA as well as AES was just fine.
> Now as Firefox/Thunderbird dropped support, removing CAMELLIA is
> just fine.
> 

I've noted before that my issue is also that CAMELLIA has seen a lot
less cryptanalysis (especially in recent years) than AES.  Because
it was mentioned earlier: eh ECRYPT document is excellent but
written by Cryptographers, it does not consider practical issues
with recommendations they make regarding ciphers (e.g. quality of
OpenSSL implementations, performance and hardware support). We're
well off with AES in my opinion and anyone that believes otherwise
should make a serious attempt at explaining his believes in detail,
backing them up with papers and appropriate arguments.

So far we're at: CAMELLIA goes. Before we do that I'll take another
look at the cipherstring in general and encourage everyone to do so.
Test with current OpenSSL releases as their parsing and
interpretation of the cipherstring might have changed (for the
better) again. I'll do the same.

> > While we're add it; especially for HTTPS: I think it would make
> > a lot of sense to get rid of the Cipherstring-A. It's not used
> > anywhere in the actual Applied Crypto Hardening document and I
> > think current browsers will have a hard time establishing any
> > connection with that preferred suite.
> Actually cipherstring A was never meant to be defined by us. It
> was
> meant to be defined by the admin who knows more about the
> environment
> and the clients connecting whereas cipherstring B was designed to
> work
> 'everywhere' -- a secure, general purpose cipher string that works
> with
> OpenSSL v0.9.8 as well as v1.0.2.

Yes, I remember. The general idea was that if e.g. a admin has good
control over large parts of his infrastructure (i.e. clients as
well) he might want to shorten the cipherstring significantly, only
allowing a few, very modern, ciphers. The idea is good and we should
keep it in there. But there're two problems currently with it:

  a) it's called 'cipherstring-a' which is a bit misleading as we're
     not actually providing anything like a cipherstring. we should
     keep the recommendation in there but change the title around.
     For example controlled-environment-cipherstring. But maybe
     someone finds a slicker name, I'm not good at naming things.

  b) We should discuss the following issue; do we want to encourage
     Administrtors to take action and deploy their own cipherstring?
     We've seen how difficult it is to get this right and working
     with different OpenSSL-branches and software environments. I'd
     actually actively discourge that. And if someone knows enough
     to do so anyway, he probably doesn't need our document but will
     want to refer to the ECYPT reference directly, or look up newer
     documents released by various researchers and organizations in
     that direction, certainly this is not something we even try to
     supply as it's outside of our expertise and project scope.
> I rather believe we should rename cipherstring B to C and define a
> next
> generation cipherstring B using something like OpenSSL v1.0.1 as a
> baseline
> (we, of course, need to evaluate current distributions and the
> OpenSSL
> versions used there).

Let's just call cipherstring-b: BetterCrypto CipherString?

What do you think?
Aaron
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://lists.cert.at/pipermail/ach/attachments/20160306/74eed61c/attachment.sig>


More information about the Ach mailing list