A fast, Cross-VM attack on AES [pdf]
eprint.iacr.org
A fast, Cross-VM attack on AES [pdf]
1–10 of 12 posts
Re: A fast, Cross-VM attack on AES [pdf]
#2The paper only talks about T-table AES implementation,
but it should probably mention at countermeasures this paper "Faster and timing-attack resistant AES-GCM" by Emilia Käsper and Peter Schwabe at CHES 2009, which I found when looking at 'No data-dependent array indices' feature of NaCl:
http://nacl.cr.yp.to/features.html
Re: A fast, Cross-VM attack on AES [pdf]
#3The paper only talks about T-table AES implementation, but it should probably mention at countermeasures this paper "Faster and timing-attack resistant AES-GCM" by Emilia Käsper and Peter Schwabe at CHES 2009, which I found when looking at 'No data-dependent array indices' feature of NaCl: http://nacl.cr.yp.to/features.html
I'm curious about NaCl, would it be possible to replace OpenSSL with something based on this library? If not, why not?
The feature list certainly looks impressive!
Re: A fast, Cross-VM attack on AES [pdf]
#4The paper only talks about T-table AES implementation, but it should probably mention at countermeasures this paper "Faster and timing-attack resistant AES-GCM" by Emilia Käsper and Peter Schwabe at CHES 2009, which I found when looking at 'No data-dependent array indices' feature of NaCl: http://nacl.cr.yp.to/features.html
I'm curious about NaCl, would it be possible to replace OpenSSL with something based on this library? If not, why not? The feature list certainly looks impressive!
It depends on your use case.
If you need something that speaks TLS, then no. NaCl is a different (simpler) protocol that does not have TLS compatibility as a goal.
If you're building a new application then NaCl is probably a good choice. There are some problems you may need to solve yourself, if your application calls for them. For example, NaCl has no notion of a CA hierarchy.
Re: A fast, Cross-VM attack on AES [pdf]
#5Earlier quoted context omitted.
I'm curious about NaCl, would it be possible to replace OpenSSL with something based on this library? If not, why not? The feature list certainly looks impressive!
It depends on your use case. If you need something that speaks TLS, then no. NaCl is a different (simpler) protocol that does not have TLS compatibility as a goal. If you're building a new application then NaCl is probably a good choice. There are some problems you may need to solve yourself, if your application calls for them. For example, NaCl has no notion of a CA hierarchy.
Lack of a CA hierarchy sounds like a problem has just been solved for you
Re: A fast, Cross-VM attack on AES [pdf]
#6Virtualization is not a security implementation. I've been saying this for years and I'll continue to keep my tinfoil hat on.
As Theo DeRaadt said
You are absolutely deluded, if not stupid, if you think that
a worldwide collection of software engineers who can't write
operating systems or applications without security holes,
can then turn around and suddenly write virtualization
layers without security holes.
Re: A fast, Cross-VM attack on AES [pdf]
#7The paper only talks about T-table AES implementation, but it should probably mention at countermeasures this paper "Faster and timing-attack resistant AES-GCM" by Emilia Käsper and Peter Schwabe at CHES 2009, which I found when looking at 'No data-dependent array indices' feature of NaCl: http://nacl.cr.yp.to/features.html
I'm curious about NaCl, would it be possible to replace OpenSSL with something based on this library? If not, why not? The feature list certainly looks impressive!
If you have to interoperate with something already using OpenSSL then probably not.
If you are writing a new application then read on.
There are 2 NaCl alternatives to consider as well: Sodium (API compatible) [2], TweetNaCl (small, auditable) [1].
There are higher-level protocols that uses NaCl, CurveCP [3] for UDP, and CurveZMQ for TCP[4], although "CurveCP software isn't ready for users yet".
[1] http://tweetnacl.cr.yp.to/ [2] http://doc.libsodium.org/
[3] http://curvezmq.org/page:read-the-docs [4] http://curvecp.org/
Re: A fast, Cross-VM attack on AES [pdf]
#8Earlier quoted context omitted.
It depends on your use case. If you need something that speaks TLS, then no. NaCl is a different (simpler) protocol that does not have TLS compatibility as a goal. If you're building a new application then NaCl is probably a good choice. There are some problems you may need to solve yourself, if your application calls for them. For example, NaCl has no notion of a CA hierarchy.
Lack of a CA hierarchy sounds like a problem has just been solved for you
Yeah, it's arguably a plus.
Re: A fast, Cross-VM attack on AES [pdf]
#9Virtualization is not a security implementation. I've been saying this for years and I'll continue to keep my tinfoil hat on. As Theo DeRaadt said You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes. I caugh…
That ship has already sailed, so much so that real companies are willing to execute hostile code inside Docker instances; Docker isn't even virtualized.
Given that virtualization is the de facto standard deployment technology for the majority of all new applications, it's worth knowing the specific limitations.
Re: A fast, Cross-VM attack on AES [pdf]
#10Virtualization is not a security implementation. I've been saying this for years and I'll continue to keep my tinfoil hat on. As Theo DeRaadt said You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes. I caugh…
Virtualization does offer additional security if it's used to isolate things that otherwise would have been running on the same host. For example, at my old job we used OpenVZ to isolate wordpress, twiki, and roundcube, whereas historically we would have had them all installed on the same webserver.
I think this is the original source of the confusion, which has since disseminated to those who don't understand the nuances and think that virtualization adds security in every case.
The PCI DSS requires that each server just has one purpose. I was surprised when in a later version they explicitly allowed virtualization as a way to comply with that requirement.