Results 1  10
of
16
AES Proposal: Rijndael
, 1998
"... this document we describe the cipher Rijndael. First we present the mathematical basis necessary for understanding the specifications followed by the design rationale and the description itself. Subsequently, the implementation aspects of the cipher and its inverse are treated. This is followed by t ..."
Abstract

Cited by 100 (0 self)
 Add to MetaCart
this document we describe the cipher Rijndael. First we present the mathematical basis necessary for understanding the specifications followed by the design rationale and the description itself. Subsequently, the implementation aspects of the cipher and its inverse are treated. This is followed by the motivations of all design choices and the treatment of the resistance against known types of attacks. We give our security claims and goals, the advantages and limitations of the cipher, ways how it can be extended and how it can be used
CBC MACs for arbitrarylength messages: The threekey constructions
 Advances in Cryptology – CRYPTO ’00, Lecture Notes in Computer Science
, 2000
"... Abstract. We suggest some simple variants of the CBC MAC that let you efficiently MAC messages of arbitrary lengths. Our constructions use three keys, K1, K2, K3, to avoid unnecessary padding and MAC any message M ∈ {0, 1} ∗ using max{1, ⌈M/n⌉} applications of the underlying nbit block cipher. O ..."
Abstract

Cited by 66 (16 self)
 Add to MetaCart
Abstract. We suggest some simple variants of the CBC MAC that let you efficiently MAC messages of arbitrary lengths. Our constructions use three keys, K1, K2, K3, to avoid unnecessary padding and MAC any message M ∈ {0, 1} ∗ using max{1, ⌈M/n⌉} applications of the underlying nbit block cipher. Our favorite construction, XCBC, works like this: if M  is a positive multiple of n then XOR the nbit key K2 with the last block of M and compute the CBC MAC keyed with K1; otherwise, extend M’s length to the next multiple of n by appending minimal 10 i padding (i ≥ 0), XOR the nbit key K3 with the last block of the padded message, and compute the CBC MAC keyed with K1. We prove the security of this and other constructions, giving concrete bounds on an adversary’s inability to forge in terms of her inability to distinguish the block cipher from a random permutation. Our analysis exploits new ideas which simplify proofs compared to prior work. 1
Evidence and Nonrepudiation
 JOURNAL OF NETWORK AND COMPUTER APPLICATIONS
, 1997
"... The ultimate purpose of a nonrepudiation service is to resolve disputes about the occurrence or nonoccurrence of a claimed event or action. Dispute resolution relies on the evidence held by the participants. This paper discusses types of nonrepudiation evidence, elements of nonrepudiation evide ..."
Abstract

Cited by 35 (5 self)
 Add to MetaCart
The ultimate purpose of a nonrepudiation service is to resolve disputes about the occurrence or nonoccurrence of a claimed event or action. Dispute resolution relies on the evidence held by the participants. This paper discusses types of nonrepudiation evidence, elements of nonrepudiation evidence and validity of nonrepudiation evidence. We also investigate and compare a number of protocols aiming at fair exchange of nonrepudiation evidence.
OMAC: OneKey CBC MAC
 Preproceedings of Fast Software Encryption, FSE 2003
, 2002
"... In this paper, we present Onekey CBC MAC (OMAC) and prove its security for arbitrary length messages. OMAC takes only one key, K (k bits) of a block cipher E. Previously, XCBC requires three keys, (k + 2n) bits in total, and TMAC requires two keys, (k + n) bits in total, where n denotes the block l ..."
Abstract

Cited by 18 (6 self)
 Add to MetaCart
In this paper, we present Onekey CBC MAC (OMAC) and prove its security for arbitrary length messages. OMAC takes only one key, K (k bits) of a block cipher E. Previously, XCBC requires three keys, (k + 2n) bits in total, and TMAC requires two keys, (k + n) bits in total, where n denotes the block length of E.
On the Construction of VariableInputLength Ciphers
 In Fast Software Encryption
, 1998
"... We invesitgate how to construct ciphers which operate on messages of various (and effectively arbitrary) lengths. In particular, lengths not necessarily a multiple of some block length. (By a "cipher" we mean a keyindexed family of lengthpreserving permutations, with a "good" cipher being one that ..."
Abstract

Cited by 15 (4 self)
 Add to MetaCart
We invesitgate how to construct ciphers which operate on messages of various (and effectively arbitrary) lengths. In particular, lengths not necessarily a multiple of some block length. (By a "cipher" we mean a keyindexed family of lengthpreserving permutations, with a "good" cipher being one that resembles a family of random lengthpreserving permutations.) Oddly enough, this question seems not to have been investiaged. We show how to construct variableinput length ciphers starting from any block cipher (ie, a cipher which operates on strings of some fixed length n). We do this by giving a general method starting from a particular kind of pseudorandom function and a particular kind of encryption scheme, and then we give example ways to realize these tools from a block cipher. All of our constructions are proven sound, in the provablesecurity sense of contemporary cryptography. Variableinputlength ciphers can be used to encrypt in the presence of the constraint that the ciphertex...
A Suggestion for Handling ArbitraryLength Messages with the CBC MAC
, 2000
"... Introduction The CBC MAC is the customary way to make a message authentication code (MAC) from a block cipher. It is the subject of several standards, including [1, 5, 6]. It is wellknown and wellunderstood. Given all this, it seems likely that the CBC MAC will be standardized as an AES mode of o ..."
Abstract

Cited by 8 (0 self)
 Add to MetaCart
Introduction The CBC MAC is the customary way to make a message authentication code (MAC) from a block cipher. It is the subject of several standards, including [1, 5, 6]. It is wellknown and wellunderstood. Given all this, it seems likely that the CBC MAC will be standardized as an AES mode of operation. In this note we suggest a nice version of the CBC MAC that one might select for this purpose. We recall that the CBC MAC actually comes in a number of different versions. These versions differ in details involving padding (what to do when a message is not a nonzero multiple of the block length), lengthvariability (how to properly authenticate messages that come in a variety of lengths), and keysearch strengthening (making the mode more secure against keysearch attacks). Our CBC MAC variant is described in [4], where it is called XCBC. Let us now review this MAC's definition, as well as the definition for
Stronger Security Bounds for OMAC, TMAC and XCBC
, 2003
"... OMAC, TMAC and XCBC are CBCtype MAC schemes which are provably secure for arbitrary message length. In this paper, we present a more tight upper bound on denotes the maximum success (forgery) probability of adversaries. Our bounds are expressed in terms of the total length of all queries of ..."
Abstract

Cited by 3 (1 self)
 Add to MetaCart
OMAC, TMAC and XCBC are CBCtype MAC schemes which are provably secure for arbitrary message length. In this paper, we present a more tight upper bound on denotes the maximum success (forgery) probability of adversaries. Our bounds are expressed in terms of the total length of all queries of an adversary to the MAC generation oracle while the previous bounds are expressed in terms of the maximum length of each query. In particular, a significant improvement occurs if the lengths of queries are heavily unbalanced.
Proposal to NIST for a parallelizable message authentication code
, 2001
"... accounting. PMAC uses djM j=ne blockcipher invocations for any nonempty message M . (The empty string takes one blockcipher invocation). We compare with the CBC MAC: The \basic" CBC MAC, which assumes that the message is a nonzero multiple of the block length and which is only secure when all mes ..."
Abstract

Cited by 3 (0 self)
 Add to MetaCart
accounting. PMAC uses djM j=ne blockcipher invocations for any nonempty message M . (The empty string takes one blockcipher invocation). We compare with the CBC MAC: The \basic" CBC MAC, which assumes that the message is a nonzero multiple of the block length and which is only secure when all messages to be MACed are of one xed length, uses the same number of block cipher calls: jM j=n.
Divide and Concatenate: A Scalable Hardware Architecture for Universal MAC
 in 12 th ACM International Symp. on FieldProgrammable Gate Arrays (FPGA2004
, 2003
"... We present a cryptographic architecture optimization technique called divideandconcatenate based on two observations: (i) the area of a multiplier and associated data path decreases exponentially and their speeds increase linearly as their operand size is reduced. (ii) in hash functions, message a ..."
Abstract

Cited by 1 (0 self)
 Add to MetaCart
We present a cryptographic architecture optimization technique called divideandconcatenate based on two observations: (i) the area of a multiplier and associated data path decreases exponentially and their speeds increase linearly as their operand size is reduced. (ii) in hash functions, message authentication codes and related cryptographic algorithms, two functions are equivalent if they have the same collision probability property. In the proposed approach we divide a 2wbit data path (with collision probability 2 ) into two wbit data paths (each with collision probability 2 ) and concatenate their results to construct an equivalent 2wbit data path (with a collision probability 2 ). We applied this technique on NH hash, a universal hash function that uses multiplications and additions. When compared to the 100% overhead associated with duplicating a straightforward 32bit pipelined NH hash data path, the divideandconcatenate approach yields a 94% increase in throughput with only 40% hardware overhead. The NH hash associated message authentication code UMAC architecture with collision probability 2 that uses four equivalent 8bit divideandconcatenate NH hash data paths yields a throughput of 79.2 Gbps with only 3840 FPGA slices when implemented on a Xilinx XC2VP77 Field Programmable Gate Array (FPGA). 1. Motivation In the past, most cryptographic algorithms have been developed to run fast on generalpurpose processors. More recently, dedicated cryptographic hardware is being developed and deployed to match the >10 Gbps wire speed requirements. In this paper we will investigate scalable hardware architectures for cryptographic algorithms.