## A Formal Treatment of Remotely Keyed Encryption (1998)

### Cached

### Download Links

- [www.wisdom.weizmann.ac.il]
- [www.wisdom.weizmann.ac.il]
- [www.wisdom.weizmann.ac.il]
- [ftp.research.att.com]
- [www.cs.yale.edu]
- DBLP

### Other Repositories/Bibliography

Venue: | In Eurocrypt ’98 |

Citations: | 29 - 1 self |

### BibTeX

@INPROCEEDINGS{Blaze98aformal,

author = {Matt Blaze and Joan Feigenbaum and Moni Naor},

title = {A Formal Treatment of Remotely Keyed Encryption},

booktitle = {In Eurocrypt ’98},

year = {1998},

pages = {251--265},

publisher = {Springer-Verlag}

}

### OpenURL

### Abstract

. Remotely keyed encryption schemes (RKESs), introduced by Blaze [6], support high-bandwidth cryptographic applications (such as encrypted video conferences) in which long-lived secrets (such as users' private keys) never leave lower-bandwidth environments such as secure smart-cards. We provide a formal framework in which to study the security of RKESs and give RKESs that satisfy our formal security requirements. Our RKESs are efficient in that the amount of communication and computation required of the smart-card is independent of the input size. In one proof of security, we use the pseudorandom permutation framework of Naor and Reingold [18] in an essential way. Keywords: Block Ciphers, Pseudorandomness, Remotely Keyed Encryption, Session Keys, Smart-cards 1 Introduction No cryptographic protocol is stronger than the mechanism protecting its secret keys. However, in many computing and communication systems, there is no "safe place" in which secret keys can be stored and cryptographi...

### Citations

1231 |
Probabilistic encryption
- Goldwasser, Micali
- 1984
(Show Context)
Citation Context ...ace is bigger than the plaintext space. We can (and should) use a probabilistic encryption algorithm that induces, for each plaintext, a probability distribution on a corresponding set of ciphertexts =-=[13]-=-. Furthermore, if ciphertexts are of length c(u), it need not be the case that every string in {0, 1} c(u) is a legitimate encryption of some plaintext. Because we have these two types of flexibility ... |

662 |
How to construct random functions
- Goldreich, Goldwasser, et al.
- 1986
(Show Context)
Citation Context ...part of everything that follows. For example, the statement “F is a pseudorandom function” means that F : {0, 1} κ(u) × {0, 1} b(u) → {0, 1} b(u) is a pseudorandom function generator, in the sense of =-=[12]-=- or [15, Lecture 12]. Similarly, additional (but standard) detail is also required to say precisely what is meant by a “random” function, permutation, or function pair. These details can be found in, ... |

470 | Non-malleable cryptography
- Dolev, Dwork, et al.
(Show Context)
Citation Context ...algorithm and on which the decryption algorithm does not output “invalid.” Note that the combination of these two properties yields a private-key non-malleable cryptosystem as defined by Dolev et al. =-=[8]-=- 2 , in which it is infeasible not only to compute anything about a plaintext but also to generate the ciphertext of a related message. It is worth noting that self-validation together with semantic s... |

371 | A Concrete Security Treatment of Symmetric Encryption: Analysis of the DES Modes of Operation
- Bellare, Desai, et al.
- 1997
(Show Context)
Citation Context ...nomial-time adversary can distinguish between a random ciphertext and the encryption of a chosen plaintext, even if it had prior access to the encryption and decryption mechanisms (see Bellare et al. =-=[1]-=-). To make use of the property that not every string in {0, 1} c(u) needs to correspond to a plaintext, we give the decryption algorithm the option of outputting a distinguished string 7“invalid.” In... |

247 | Differential fault analysis of secret key cryptosystems,” CRYPTO ’97
- Biham, Shamir
(Show Context)
Citation Context ... that the card owner wants to safeguard the “remote keys” and that an attacker can only communicate with the card via its official communication channels. See, e.g., Boneh et al. [7] and Biham-Shamir =-=[5]-=-, for a discussion of direct attacks on cards. Note as well that the remotely keyed encryption problem is different from the one of having a smart-card take advantage of a host’s superior processing p... |

219 | Provably secure session key distribution—the three party case
- BELLARE, ROGAWAY
- 1995
(Show Context)
Citation Context ... advantage of no interaction; however, there are other reasons for key exchange. See, for example, Shoup and Rubin [19] for a rigorous treatment of session-key exchange (following Bellare and Rogaway =-=[3]-=-), in which the adversary is similar in power to the one we consider here. The Shoup-Rubin protocol requires several rounds of communication between the hosts. We give formal definitions that capture ... |

156 |
Pseudorandomness and Cryptographic Applications
- Luby
- 1996
(Show Context)
Citation Context ...erving RKES is given in Section 5. 2 Notation, Terminology, and Building Blocks Definitions of standard cryptographic and complexity theoretic terms can be found in, for example, Goldreich [11], Luby =-=[15]-=-, and Naor and Reingold [18]. The following is a description of the building blocks and terminology used throughout. – The plaintext and the ciphertext are, respectively, X and Y . Usually, both are g... |

155 | The security of cipher block chaining
- Bellare, Kilian, et al.
- 1994
(Show Context)
Citation Context ...ons of GS are: • Apply a pseudorandom generator to S and Xor the resulting sequence with X1, . . . , Xn. • Use ES with some sort of chaining, e.g., CBC. The security of such an operation follows from =-=[2]-=-. – A collision-intractable hash function H : {0, 1} ∗ ↦→ {0, 1} b . “Collision-intractability” means that it is computationally infeasible to find distinct X and X ′ such that H(X) = H(X ′). – The ad... |

143 | Foundations of Cryptography (Fragments of a Book). Available at http://www.wisdom.weizmann.ac.il/home/oded/public_html/frag.html Exposure-Resilient Functions and All-or-Nothing Transforms 469
- Goldreich
(Show Context)
Citation Context ...length-preserving RKES is given in Section 5. 2 Notation, Terminology, and Building Blocks Definitions of standard cryptographic and complexity theoretic terms can be found in, for example, Goldreich =-=[11]-=-, Luby [15], and Naor and Reingold [18]. The following is a description of the building blocks and terminology used throughout. – The plaintext and the ciphertext are, respectively, X and Y . Usually,... |

91 | How to protect DES against exhaustive key search
- Kilian, Rogaway
- 1996
(Show Context)
Citation Context ... ⊓⊔ We provide another construction of non-colliding encryption . The proof is based on generating many “independent” permutations from a single one, as in Even and Mansour [9] and Kilian and Rogaway =-=[14]-=-. It may be the preferred construction if the smart-card constraints make it very difficult to change a key to a permutation. NCE Construction 2: Let k = (k1, k2, k3), where k2 and k3 are used as keys... |

53 | A construction of a cipher from a single pseudorandom permutation
- Even, Mansour
- 1991
(Show Context)
Citation Context ...at most ε1 m, yielding (1). ⊓⊔ We provide another construction of non-colliding encryption . The proof is based on generating many “independent” permutations from a single one, as in Even and Mansour =-=[9]-=- and Kilian and Rogaway [14]. It may be the preferred construction if the smart-card constraints make it very difficult to change a key to a permutation. NCE Construction 2: Let k = (k1, k2, k3), wher... |

42 | High-bandwidth encryption with low-bandwidth smart cards
- Blaze
- 1996
(Show Context)
Citation Context ....com 2 Dept. Applied Math. and Computer Science Weizmann Institute of Science Rehovot 76100, Israel naor@wisdom.weizmann.ac.il Abstract. Remotely keyed encryption schemes (RKESs), introduced by Blaze =-=[6]-=-, support high-bandwidth cryptographic applications (such as encrypted video conferences) in which long-lived secrets (such as users’ private keys) never leave lower-bandwidth environments such as sec... |

42 |
Speeding Up Secret Computations with Insecure Auxiliary Devices
- Matsumoto, Kato, et al.
- 1989
(Show Context)
Citation Context ...do a public-key computation without leaking the input to the host. For a discussion of the (well-studied) problem of host-assisted public-key cryptography, see e.g., Feigenbaum [10], Matsumoto et al. =-=[17]-=-, and the references therein. Finally, note that the goal of a remotely keyed encryption scheme (RKES) is not “session-key exchange” between two different hosts each connected to a card, where the two... |

22 | Locally random reductions in interactive complexity theory
- FEIGENBAUM
- 1993
(Show Context)
Citation Context ...sing power in order to do a public-key computation without leaking the input to the host. For a discussion of the (well-studied) problem of host-assisted public-key cryptography, see e.g., Feigenbaum =-=[10]-=-, Matsumoto et al. [17], and the references therein. Finally, note that the goal of a remotely keyed encryption scheme (RKES) is not “session-key exchange” between two different hosts each connected t... |

12 | Accelerated Remotely Keyed Encryption
- LUCKS
- 1999
(Show Context)
Citation Context ...rsary that has controlled the host during m interactions with the card subsequently to “forge” a plaintext/ciphertext pair that is not one of the m pairs he has obtained during the interaction. Lucks =-=[16]-=- first noted that the RKES in [6] was not completely satisfactory; in particular, he noted the forgery weakness just described. Lucks [16] attempted to formalize the security properties that an RKES s... |

3 |
Collision Resistant Hashing, Towards Making UOWHFs practical
- Bellare, Rogaway
- 1997
(Show Context)
Citation Context ...te that a collision-intractable hash function is used in our constructions and that it is not known how to build such a hash function based only on the assumption that a one-way function exists. (See =-=[4]-=- for a discussion of the desirability of using UOWHFs instead of collision-intractable hash functions.) Acknowledgments We thank Omer Reingold for useful discussions and the Eurocrypt ’98 Program Comm... |

2 | On the Importance of Checking Protocols for Faults - Boneh, Demillo, et al. - 1997 |