4 ms·
The 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 edwintorok 12y ago
The 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 http://nacl.cr.yp.to/features.html
- 0x0 12y agoI'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!
- sdevlin 12y agoIt 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.
- edwintorok 12y agoIf 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/ http://tweetnacl.cr.yp.to/ [2] http://doc.libsodium.org/ http://doc.libsodium.org/ [3] http://curvezmq.org/page:read-the-docs http://curvezmq.org/page:read-the-docs [4] http://curvecp.org/ http://curvecp.org/