Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 25 Jun 2014 18:44:30 -0700
From:      John-Mark Gurney <jmg@funkthat.com>
To:        freebsd-security@FreeBSD.org
Subject:   Re: fast or slow crypto?
Message-ID:  <20140626014430.GY1560@funkthat.com>
In-Reply-To: <20140626012226.GX1560@funkthat.com>
References:  <20140626012226.GX1560@funkthat.com>

next in thread | previous in thread | raw e-mail | index | archive | help
John-Mark Gurney wrote this message on Wed, Jun 25, 2014 at 18:22 -0700:
> Subj is more limited by your attack profile, than purely fast crypto..
> In some cases the crypto can be made reasonably fast while being
> secure against side channel analysis, but in other cases (GHASH) it's
> pretty much one (slow and secure) or the other (fast and insecure)...
> 
> The question I have is what attack profile are we going for?  Do we
> want to make this an option?

I forgot to say, in many (most?) cases, the side channel leaks to
another process on the local system...  So, this may be more of a,
do you have untrusted user accounts on your system or not question..

> The reason I ask is that I'm working on adding AES-GCM to FreeBSD,
> but the speed difference between the two is significant...  We are
> looking at 35MB/sec for slow, vs. 234MB/sec for fast, almost 7x
> faster, for running the GHASH part of GCM...  The fast one does help
> use tricks to try to prevent cache line snooping, but it turns out that
> you can snoop even on intra-cache line accesses (the first word of a
> cache line is accessed significantly faster than others on amd64
> machines)...  So, even the fast one isn't 100% secure...
> 
> So, how do we address this?
> 
> One idea I have had is to have both in the kernel, and then via a
> tuneable/sysctl/kernel compile option select which one gets used...
> 
> This is both good and bad..  Choice is good, the bad part is that
> which ever choice we make be the default will be the wrong choice
> for a non-small group of our users...
> 
> Hopefully now that side channel is well appreciated, that future
> crypto designs will not have this issue (here's looking at you
> ChaCha20/Poly1305) and this won't have to last that long...
> 
> But till then, we still need to make the choice...

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140626014430.GY1560>