Abstract. We describe several software side-channel attacks based on inter-process leakage through the state of the CPU’s memory cache. This leakage reveals memory access patterns, which can be used for cryptanalysis of cryptographic primitives that employ data-dependent table lookups. The attacks allow an unprivileged process to attack other processes running in parallel on the same processor, despite partitioning methods such as memory protection, sandboxing and virtualization. Some of our methods require only the ability to trigger services that perform encryption or MAC using the unknown key, such as encrypted disk partitions or secure network links. Moreover, we demonstrate an extremely strong type of attack, which requires knowledge of neither the specific plaintexts nor ciphertexts, and works by merely monitoring the effect of the cryptographic process on the cache. We discuss in detail several attacks on AES, and experimentally demonstrate their applicability to real systems, such as OpenSSL and Linux’s dm-crypt encrypted partitions (in the latter case, the full key was recovered after just 800 writes to the partition, taking 65 milliseconds). Finally, we discuss a variety of countermeasures which can be used to mitigate such attacks.

Abstract—We take a systematic approach to developing a symmetric cryptography library in Javascript. We study various strategies for optimizing the code for the Javascript interpreter, and observe that traditional crypto optimization techniques do not apply when implemented in Javascript. We propose a number of optimizations that reduce both running time and code size. Our optimized library is about four times faster and 12 % smaller than the fastest and smallest existing symmetric Javascript encryption libraries. On Internet Explorer 8, our library is about 11 times faster than the fastest previously existing code. In addition, we show that certain symmetric systems that are faster than AES when implemented in native x86 code, are in fact much slower than AES when implemented in Javascript. As a result, the choice of ciphers for a Javascript crypto library may be substantially different from the choice of ciphers when implementing crypto natively. Finally, we study the problem of generating strong randomness in Javascript and give extensive measurements validating our techniques. Keywords-Javascript; cryptography; optimization; Project homepage:

Secure end-to-end communication is becoming increasingly important as more private and sensitive data is transferred on the Internet. Unfortunately, today’s SSL deployment is largely limited to security or privacycritical domains. The low adoption rate is mainly attributed to the heavy cryptographic computation overhead on the server side, and the cost of good privacy on the Internet is tightly bound to expensive hardware SSL accelerators in practice. In this paper we present high-performance SSL acceleration using commodity processors. First, we show that modern graphics processing units (GPUs) can be easily converted to general-purpose SSL accelerators. By exploiting the massive computing parallelism of GPUs, we accelerate SSL cryptographic operations beyond what state-of-the-art CPUs provide. Second, we build a transparent SSL proxy, SSLShader, that carefully leverages the trade-offs of recent hardware features such as AES-NI and NUMA and achieves both high throughput and low latency. In our evaluation, the GPU implementation of RSA shows a factor of 22.6 to 31.7 improvement over the fastest CPU implementation. SSLShader achieves 29K transactions per second for small files while it transfers large files at 13 Gbps on a commodity server machine. These numbers are comparable to high-end commercial SSL appliances at a fraction of their price.

We study the software performance of authenticated-encryption modes CCM, GCM, and OCB. Across a variety of platforms, we find OCB to be substantially faster than either alternative. For example, on an Intel i5 (“Clarkdale”) processor, good implementations of CCM, GCM, and OCB encrypt at around 4.2 cpb, 3.7 cpb, and 1.5 cpb, while CTR mode requires about 1.3 cpb. Still we find room for algorithmic improvements to OCB, showing how to trim one blockcipher call (most of the time, assuming a counter-based nonce) and reduce latency. Our findings contrast with those of McGrew and Viega (2004), who claimed similar performance for GCM and OCB. Key words: authenticated encryption, cryptographic standards, encryption speed, modes of

Abstract. The FSB (fast syndrome-based) hash function was submitted to the SHA-3 competition by Augot, Finiasz, Gaborit, Manuel, and Sendrier in 2008, after preliminary designs proposed in 2003, 2005, and 2007. Many FSB parameter choices were broken by Coron and Joux in 2004, Saarinen in 2007, and Fouque and Leurent in 2008, but the basic FSB idea appears to be secure, and the FSB submission remains unbroken. On the other hand, the FSB submission is also quite slow, and was not selected for the second round of the competition. This paper introduces RFSB, an enhancement to FSB. In particular, this paper introduces the RFSB-509 compression function, RFSB with a particular set of parameters. RFSB-509, like the FSB-256 compression function, is designed to be used inside a 256-bit collision-resistant hash function: all known attack strategies cost more than 2 128 to find collisions in RFSB-509. However, RFSB-509 is an order of magnitude faster than FSB-256. On a single core of a Core 2 Quad Q9550 CPU, RFSB-509 runs at 10.67 cycles/byte: faster than SHA-256, faster than 7 of the 14 secondround SHA-3 candidates, and faster than 3 of the 5 SHA-3 finalists. Key words: compression functions, collision resistance, linearization, generalized birthday attacks, information-set decoding, tight reduction to L1 cache. 1

Abstract. NEON is a vector instruction set included in a large fraction of new ARM-based tablets and smartphones. This paper shows that NEON supports high-security cryptography at surprisingly high speeds; normally data arrives at lower speeds, giving the CPU time to handle tasks other than cryptography. In particular, this paper explains how to use a single 800MHz Cortex A8 core to compute the existing NaCl suite of high-security cryptographic primitives at the following speeds: 5.60 cycles per byte (1.14 Gbps) to encrypt using a shared secret key, 2.30 cycles per byte (2.78 Gbps) to authenticate using a shared secret key, 527102 cycles (1517/second) to compute a shared secret key for a new public key, 650102 cycles (1230/second) to verify a signature, and 368212 cycles (2172/second) to sign a message. These speeds make no use of secret branches and no use of secret memory addresses.

Abstract. This document lists the different modifications done in the SHAvite-3 submission package, including the tweak suggested for SHAVite-3. The changes summarized in this report were divided according to their cause, to facilitate an easy evaluation of the changes. All the locations are given with respect to the version submitted to NIST on January 15th, 2009. 1 Tweak Related Changes As mentioned in the submission, we have suggested a small tweak for SHAvite-3, to increase the security of the compression function.

Abstract. We describe several software side-channel attacks based on inter-process leakage through the state of the CPU’s memory cache. This leakage reveals memory access patterns, which can be used for cryptanalysis of cryptographic primitives that employ data-dependent table lookups. The attacks allow an unprivileged process to attack other processes running in parallel on the same processor, despite partitioning methods such as memory protection, sandboxing, and virtualization. Some of our methods require only the ability to trigger services that perform encryption or MAC using the unknown key, such as encrypted disk partitions or secure network links. Moreover, we demonstrate an extremely strong type of attack, which requires knowledge of neither the specific plaintexts nor ciphertexts and works by merely monitoring the effect of the cryptographic process on the cache. We discuss in detail several attacks on AES and experimentally demonstrate their applicability to real systems, such as OpenSSL and Linux’s dm-crypt encrypted partitions (in the latter case, the full key was recovered after just 800 writes to the partition, taking 65 milliseconds). Finally, we discuss a variety of countermeasures which can be used to mitigate such attacks. Key words.

A digest function is a sort of universal hash that takes a key and a message as its inputs. This paper will study these functions ’ properties and design in the context of their application in manual authentication technology. Frequently a digest function needs to have a very short output (e.g. 16–32 bits) and no key is used to digest more than one message. These together with other characteristics represent a new kind of game played between an attacker and honest parties, which is very different from other authentication mechanisms, notably message authentication codes or MACs. Short digests can be constructed directly or by ”condensing ” longer functions. We offer an improved method for the latter but concentrate mainly on direct constructions. We propose a digest algorithm which uses word multiplications to obtain a very fast implementation. This digest scheme enjoys strong and provable security properties, namely for a single-word or b-bit output digest function the collision probability is ɛ = 2 1−b on equal and arbitrarily length inputs. The scheme is based on the multiplicative universal hash function of Dietzfelbinger et al., and it improves on several well-studied and efficient universal hashing algorithms, including MMH and NH.

a new cryptographic library