Results 1  10
of
13
Efficient Instantiations of Tweakable Blockciphers and Refinements to Modes OCB and PMAC
, 2003
"... We describe highly efficient constructions, XE and XEX, that turn a blockcipher E: K × {0, 1}^n → {0, 1}^n into a tweakable blockcipher... ..."
Abstract

Cited by 77 (9 self)
 Add to MetaCart
(Show Context)
We describe highly efficient constructions, XE and XEX, that turn a blockcipher E: K &times; {0, 1}^n &rarr; {0, 1}^n into a tweakable blockcipher...
Ciphers with Arbitrary Finite Domains
, 2002
"... Abstract. We explore the problem of enciphering members of a finite set M where k = M  is arbitrary (in particular, it need not be a power of two). We want to achieve this goal starting from a block cipher (which requires a message space of size N =2 n, for some n). We look at a few solutions to t ..."
Abstract

Cited by 53 (9 self)
 Add to MetaCart
(Show Context)
Abstract. We explore the problem of enciphering members of a finite set M where k = M  is arbitrary (in particular, it need not be a power of two). We want to achieve this goal starting from a block cipher (which requires a message space of size N =2 n, for some n). We look at a few solutions to this problem, focusing on the case when M =[0,k − 1]. We see ciphers with arbitrary domains as a worthwhile primitive in its own right, and as a potentially useful one for making higherlevel protocols.
On the impossibility of highlyefficient blockcipherbased hash functions
 in Advances in Cryptology—EUROCRYPT 2005
, 2005
"... Abstract. Fix a small, nonempty set of blockcipher keys K. We say a blockcipherbased hash function is highlyefficient if it makes exactly one blockcipher call for each message block hashed, and all blockcipher calls use a key from K. Although a few highlyefficient constructions have been propose ..."
Abstract

Cited by 32 (3 self)
 Add to MetaCart
(Show Context)
Abstract. Fix a small, nonempty set of blockcipher keys K. We say a blockcipherbased hash function is highlyefficient if it makes exactly one blockcipher call for each message block hashed, and all blockcipher calls use a key from K. Although a few highlyefficient constructions have been proposed, no one has been able to prove their security. In this paper we prove, in the idealcipher model, that it is impossible to construct a highlyefficient iterated blockcipherbased hash function that is provably secure. Our result implies, in particular, that the Tweakable Chain Hash (TCH) construction suggested by Liskov, Rivest, and Wagner [7] is not correct under an instantiation suggested for this construction, nor can TCH be correctly instantiated by any other efficient means.
On the Impossibility of Highly Efficient BlockcipherBased Hash Functions
, 2004
"... We say a blockcipherbased hash function is highly efficient if it makes exactly one blockcipher call for each message block hashed, and all blockcipher calls use a single underlying key. Although a few highly efficient constructions have been proposed, no one has been able to prove their security. ..."
Abstract

Cited by 7 (3 self)
 Add to MetaCart
We say a blockcipherbased hash function is highly efficient if it makes exactly one blockcipher call for each message block hashed, and all blockcipher calls use a single underlying key. Although a few highly efficient constructions have been proposed, no one has been able to prove their security. In this paper we prove, in the blackbox model, that it is impossible to construct a highly efficient blockcipherbased hash function which is provably secure. Our result implies, in particular, that the Tweakable Chain Hash (TCH) construction suggested by Liskov, Rivest, and Wagner [3] is not correct under an instantiation suggested for this construction, nor can TCH be correctly instantiated by any other efficient means.
Report on the AES Candidates
, 1999
"... This document reports the activities of the AES working group organized at the Ecole Normale Superieure. Several candidates are evaluated. In particular we outline some weaknesses in the designs of some candidates. We mainly discuss selection criteria between the candidates, and make casebycas ..."
Abstract

Cited by 4 (1 self)
 Add to MetaCart
This document reports the activities of the AES working group organized at the Ecole Normale Superieure. Several candidates are evaluated. In particular we outline some weaknesses in the designs of some candidates. We mainly discuss selection criteria between the candidates, and make casebycase comments. We finally recommend the selection of Mars, RC6, Serpent, ... and DFC. As the report is being finalized, we also added some new preliminary cryptanalysis on RC6 and Crypton in the Appendix which are not considered in the main body of the report.
Elastic Block Ciphers: Method, Security and Instantiations
"... We introduce the concept of an elastic block cipher, which refers to stretching the supported block size of a block cipher to any length up to twice the original block size while incurring a computational workload that is proportional to the block size. Our method uses the round function of an exist ..."
Abstract

Cited by 4 (0 self)
 Add to MetaCart
(Show Context)
We introduce the concept of an elastic block cipher, which refers to stretching the supported block size of a block cipher to any length up to twice the original block size while incurring a computational workload that is proportional to the block size. Our method uses the round function of an existing block cipher as a black box and inserts it into a substitution permutation network. Our method is designed to enable us to form a reduction between the elastic and the original versions of the cipher. Using this reduction, we prove that the elastic version of a cipher is secure against keyrecovery attacks if the original cipher is secure against such attacks. We note that while reductionbased proofs of security are a cornerstone of cryptographic analysis, they are typical when complete components are used as subcomponents in a larger design. We are not aware of use of such techniques in the case of concrete block cipher designs. We demonstrate the general applicability of the elastic block cipher method by constructing examples from existing block ciphers: AES, Camellia, MISTY1 and RC6. We compare the performance of the elastic versions to that of the original versions and evaluate the elastic versions using statistical tests measuring the randomness of the ciphertext. We also use our examples to demonstrate the concept of a generic key schedule for block ciphers. key words: elastic block ciphers, variablelength block ciphers, security analysis, reduction proof, key recovery attacks. 1
A Synopsis of FormatPreserving Encryption
 UNPUBLISHED MANUSCRIPT
, 2010
"... Formatpreserving encryption (FPE) encrypts a plaintext of some specified format into a ciphertext of the same format—for example, encrypting a socialsecurity number into a socialsecurity number. In this survey we describe FPE and review known techniques for achieving it. These include FFX, a rece ..."
Abstract

Cited by 2 (0 self)
 Add to MetaCart
Formatpreserving encryption (FPE) encrypts a plaintext of some specified format into a ciphertext of the same format—for example, encrypting a socialsecurity number into a socialsecurity number. In this survey we describe FPE and review known techniques for achieving it. These include FFX, a recent proposal made to NIST.
A Secure Directory Service based on Exclusive Encryption
, 2002
"... We describe the design of a Windows filesystem directory service that ensures the persistence, integrity, privacy, syntactic legality, and caseinsensitive uniqueness of the names it indexes. Byzantine state replication provides persistence and integrity, and encryption imparts privacy. To enforce ..."
Abstract

Cited by 2 (2 self)
 Add to MetaCart
(Show Context)
We describe the design of a Windows filesystem directory service that ensures the persistence, integrity, privacy, syntactic legality, and caseinsensitive uniqueness of the names it indexes. Byzantine state replication provides persistence and integrity, and encryption imparts privacy. To enforce Windows ' baroque name syntax including restrictions on allowable characters, on the terminal character, and on several specific names we develop a cryptographic process, called &quot;exclusive encryption, &quot; that inherently excludes syntactically illegal names and that enables the exclusion of caseinsensitively duplicate names without access to their plaintext. This process excludes entire names by mapping the set of allowed strings to the set of all strings, excludes certain characters through an amended prefix encoding, excludes terminal characters through varying the prefix coding by character index, and supports caseinsensitive comparison of names by extracting and encrypting case information separately. We also address the issues of hiding namelength information and accessauthorization information, and we report a newly discovered problem with enforcing caseinsensitive uniqueness for Unicode names.
Tweaks and Keys for Block Ciphers: the TWEAKEY Framework
"... Abstract. We propose the TWEAKEY framework with goal to unify the design of tweakable block ciphers and of block ciphers resistant to relatedkey attacks. Our framework is simple, extends the keyalternating construction, and allows to build a primitive with arbitrary tweak and key sizes, given the ..."
Abstract

Cited by 2 (0 self)
 Add to MetaCart
(Show Context)
Abstract. We propose the TWEAKEY framework with goal to unify the design of tweakable block ciphers and of block ciphers resistant to relatedkey attacks. Our framework is simple, extends the keyalternating construction, and allows to build a primitive with arbitrary tweak and key sizes, given the public round permutation (for instance, the AES round). Increasing the sizes renders the security analysis very difficult and thus we identify a subclass of TWEAKEY, that we name STK, which solves the size issue by the use of finite field multiplications on low hamming weight constants. We give very efficient instances of STK, in particular, a 128bit tweak/key/state block cipher DeoxysBC that is the first AESbased adhoc tweakable block cipher. At the same time, DeoxysBC could be seen as a secure alternative to AES256, which is known to be insecure in the relatedkey model. As another member of the TWEAKEY framework, we describe KiasuBC, which is a very simple and even more efficient tweakable variation of AES128 when the tweak size is limited to 64 bits. In addition to being efficient, our proposals, compared to the previous schemes that use AES as a black box, offer security beyond the birthday bound. DeoxysBC and KiasuBC represent interesting pluggable primitives for authenticated encryption schemes, for instance, ΘCB3 instantiated with KiasuBC runs at about 0.75 c/B on Intel Haswell. Our work can also be seen as advances on the topic of secure key schedule design for AESlike ciphers, describing several proposals in this direction.