## CryptoDB

### Scott R. Fluhrer

#### Publications

Year
Venue
Title
2014
EPRINT
2014
FSE
2008
EPRINT
We give a method that appears to be able to find colliding messages for the Waterfall hash function with approximately $O(2^{70})$ work for all hash sizes. If correct, this would show that the Waterfall hash function does not meet the required collision resistance.
2007
EPRINT
The XCB mode of operation was outlined in 2004 as a contribution to the IEEE Security in Storage effort, but no security analysis was provided. In this paper, we provide a proof of security for XCB, and show that it is a secure tweakable (super) pseudorandom permutation. Our analysis makes several new contributions: it uses an algebraic property of XCB's internal universal hash function to simplify the proof, and it defines a nonce mode in which XCB can be securely used even when the plaintext is shorter than twice the width of the underlying block cipher. We also show minor modifications that improve the performance of XCB and make it easier to analyze. XCB is interesting because it is highly efficient in both hardware and software, it has no alignment restrictions on input lengths, it can be used in nonce mode, and it uses the internal functions of the Galois/Counter Mode (GCM) of operation, which facilitates design re-use and admits multi-purpose implementations.
2005
EPRINT
Some message authentication codes (MACs) are vulnerable to multiple forgery attacks, in which an attacker can gain information that allows her to succeed in forging multiple message/tag pairs. This property was first noted in MACs based on universal hashing, such as the Galois/Counter Mode (GCM) of operation for block ciphers. However, we show that CBC-MAC and HMAC also have this property, and for some parameters are more vulnerable than GCM. We present multiple-forgery attacks against these algorithms, then analyze the security against these attacks by using the expected number of forgeries. We compare the different MACs using this measure. This document is a pre-publication draft manuscript.
2004
EPRINT
We describe a block cipher mode of operation that implements a `tweakable' (super) pseudorandom permutation with an arbitrary block length. This mode can be used to provide the best possible security in systems that cannot allow data expansion, such as disk-block encryption and some network protocols. The mode accepts an additional input, which can be used to protect against attacks that manipulate the ciphertext by rearranging the ciphertext blocks. Our mode is similar to a five-round Luby-Rackoff cipher in which the first and last rounds do not use the conventional Feistel structure, but instead use a single block cipher invocation. The third round is a Feistel structure using counter mode as a PRF. The second and fourth rounds are Feistel structures using a universal hash function; we re-use the polynomial hash over a binary field defined in the Galois/Counter Mode (GCM) of operation for block ciphers. This choice provides efficiency in both hardware and software and allows for re-use of implementation effort. XCB also has several useful properties: it accepts arbitrarily-sized plaintexts and associated data, including any plaintexts with lengths that are no smaller than the width of the block cipher. This document is a pre-publication draft manuscript.
2002
EPRINT
The encryption system $E_{0}$, which is the encryption system used in the Bluetooth specification, is a two level system where a key and a packet nonce is given to a level 1 key stream generator, which produces the key for a level 2 key stream generator, whose output is used to encrypt. We give a method for recovering the key for the level 1 key stream generator given the internal keys for two or three level 2 key stream generators. This method, combined with published methods for recovering keys for the level 2 key stream generator, can be used to recover the $E_{0}$ second key with $O(2^{65})$ work, and $O(2^{80})$ precomputation time. Although this attack is of no advantage if $E_{0}$ is used with the recommended security parameters (64 bit encryption key), it shows that no addition security would be made available by enlarging the encryption key, as discussed in the Bluetooth specification.
2001
FSE
2001
FSE
2000
FSE

#### Coauthors

Farzaneh Abed (2)
Christian Forler (2)
Eik List (2)
Stefan Lucks (2)
David A. McGrew (6)
Jakob Wenzel (2)