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?
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...
Comments?
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
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."
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)...So, one point I somewhat forget in this is that the version of software AES in the kernel (that this new GHASH would go with) is vulnerable to side-channel attacks... So, we are already in the fast and less secure side of the equation.. There are lots of interesting optimizations that can made, including a version of AES that uses SSE registers, is constant time, and faster than the Sbox lookup version... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."