1: %=======================================================================

2: %The Random Oracle Model, Revisited. [Ran, Oded and Shai]

3: %=======================================================================

4: \documentclass[11pt]{article}

5: \usepackage{fullpage}

6: \usepackage{latexsym}

7: 

8: \title{The Random Oracle Methodology, Revisited\thanks{Extended

9: abstract has appeared in the {\em Proc. of the 30th ACM Symp. on

10: Theory of Computing (STOC)}, pages 209--218, 1998.}}

11: 

12: 

13: \def\myitem{\smallskip\noindent} 

14: \def\IBM{IBM Watson, P.O. Box 704, Yorktown Height, NY 10598, USA}

15: 

16: \def\ROM{Random Oracle Model}

17: 

18: \def\CorInt{Correlation intractable}

19: \def\corInt{correlation intractable}

20: \def\CorInty{Correlation intractability}

21: \def\corInty{correlation intractability}

22: 

23: \author{Ran Canetti\thanks{\IBM. E-mail: {\tt canetti@watson.ibm.com}}  

24: \and Oded Goldreich\thanks{Department of Computer Science,  

25: Weizmann Institute of Science, Rehovot, {\sc Israel}. 

26: E-mail: {\tt oded@wisdom.weizmann.ac.il}. 

27: Work done while visiting LCS, MIT.

28: Partially supported by DARPA grant DABT63-96-C-0018.} 

29: \and Shai Halevi\thanks{\IBM. E-mail: {\tt shaih@watson.ibm.com}}} 

30: 

31: \def\ni{\noindent}

32: \def\etal{{\it et.~al.}}

33: 

34: \newcommand{\eqdef}{\stackrel{\rm def}{=}} 

35: \newcommand{\bitset}{\{0,1\}} 

36: \newcommand{\rnd}{\in_R}

37: \newcommand{\gf}{{\rm GF}}

38: \newcommand{\negl}{{\rm negl}}

39: \newcommand{\sk}{{\rm sk}}

40: \newcommand{\vk}{{\rm vk}}

41: \newcommand{\ek}{{\rm ek}}

42: \newcommand{\dk}{{\rm dk}}

43: \newcommand{\msg}{{\rm msg}}

44: \def\th{{\rm th}}

45: \newcommand{\ov}{\overline}

46: \newcommand{\e}{\epsilon}

47: \newcommand{\f}{{\cal O}}

48: \newcommand{\SD}{\bigtriangledown}

49: %---

50: \newtheorem{thm}{Theorem}[section]      % A counter for Theorems etc

51: \newcommand{\BT}{\begin{thm}}   

52: \newcommand{\ET}{\end{thm}}

53: 

54: \newtheorem{dfn}[thm]{Definition}      % 

55: \newcommand{\BD}{\begin{dfn}}   

56: \newcommand{\ED}{\end{dfn}}

57: 

58: \newtheorem{propos}[thm]{Proposition}      % 

59: \newcommand{\BP}{\begin{propos}}   

60: \newcommand{\EP}{\end{propos}}

61: 

62: \newtheorem{corr}[thm]{Corollary}      % 

63: \newcommand{\BCR}{\begin{corr}} 

64: \newcommand{\ECR}{\end{corr}}

65: 

66: \newtheorem{rmk}[thm]{Remark}      % 

67: \newcommand{\BRK}{\begin{rmk}\rm\ } 

68: \newcommand{\ERK}{\end{rmk}}

69: \newcommand{\BR}[1]{\begin{rmk}[#1] \rm\ } 

70: \newcommand{\ER}{\end{rmk}}

71: %---

72: \newtheorem{Ithm}{Informal Theorem}[section]  % A counter for Theorems in Intro

73: \newcommand{\BIT}{\begin{Ithm}}   

74: \newcommand{\EIT}{\end{Ithm}}

75: 

76: \newtheorem{Idfn}[Ithm]{Informal Definition}      % 

77: \newcommand{\BID}{\begin{Idfn}}   

78: \newcommand{\EID}{\end{Idfn}}

79: %---

80: \newcommand{\BE}{\begin{enumerate}}

81: \newcommand{\EE}{\end{enumerate}}

82: 

83: \newcommand{\BI}{\begin{itemize}}

84: \newcommand{\EI}{\end{itemize}}

85: 

86: %%%%%%% Proof Environments

87: \def\FullBox{\hbox{\vrule width 8pt height 8pt depth 0pt}}

88: \newcommand{\qed}{\;\;\;\FullBox}

89: 

90: \newenvironment{proof}{\noindent{\bf Proof:~~}}{\(\qed\)}

91: \newcommand{\BPF}{\begin{proof}} 

92: \newcommand {\EPF}{\end{proof}}

93: 

94: \newcommand{\qedsketch}{\;\;\;\Box}

95: \newenvironment{pfsketch}{\noindent{\bf Proof Sketch:~}}{\(\qedsketch\)}

96: \def\blackslug

97: {\hbox{\hskip 1pt\vrule width 8pt height 8pt depth 1.5pt\hskip 1pt}}

98: \def\qqed{$\Box$}

99: %------------------------------------------------------------------------

100: 

101: \newcommand{\dist}{{\rm dist}} 

102: \renewcommand{\l}{{\ell}} 

103: \newcommand{\elln}{{\ell(n)}} 

104: \newcommand{\dlen}{\ell_{\rm in}} 

105: \newcommand{\rlen}{\ell_{\rm out}} 

106: 

107: 

108: \renewcommand{\L}{{\cal L}} 

109: \newcommand{\R}{{\sf R}} 

110: \newcommand{\N}{{\sf N}} 

111: \newcommand{\intfnc}{{\N\!\to\!\N}} 

112: \newcommand{\Z}{{\sf Z}} 

113: \newcommand{\vol}{{\rm vol}} 

114: \newcommand{\prob}{{\rm Pr}} 

115: \newcommand{\poly}{{\rm poly}} 

116: \newcommand{\union}{{\cup}} 

117: \newcommand{\GapCVP}{{\tt GapCVP}} 

118: \newcommand{\GapSVP}{{\tt GapSVP}} 

119: \newcommand{\NP}{{\cal NP}} 

120: \renewcommand{\P}{{\cal P}} 

121: \newcommand{\qP}{{\widetilde\P}} 

122: \newcommand{\coNP}{{\rm co}{\cal NP}} 

123: \newcommand{\AM}{{\cal AM}} 

124: \newcommand{\coAM}{{\rm co}{\cal AM}} 

125: \newcommand{\yes}{{\sc yes}} 

126: \newcommand{\no}{{\sc no}} 

127: \newcommand{\vect}[1]{\langle{#1}\rangle}

128: 

129: \newcommand{\eqref}[1]{Eq.~(\ref{#1})}

130: \newcommand{\secref}[1]{Section~\ref{#1}}

131: \newcommand{\ssecref}[1]{\S\ref{#1}}

132: \newcommand{\defref}[1]{Definition~\ref{#1}}

133: \newcommand{\thmref}[1]{Theorem~\ref{#1}}

134: \newcommand{\rlenemref}[1]{Lemma~\ref{#1}}

135: \newcommand{\prpref}[1]{Proposition~\ref{#1}}

136: \newcommand{\corref}[1]{Corollary~\ref{#1}}

137: 

138: \begin{document} 

139: 

140: \begin{titlepage}

141: \maketitle

142: 

143: \begin{abstract} 

144: We take a critical look at the relationship between the 

145: security of cryptographic schemes in the Random Oracle Model, and 

146: the security of the schemes that result from implementing the random 

147: oracle by so called ``cryptographic hash functions''. 

148: 

149: The main result of this paper is a negative one: There exist signature 

150: and encryption schemes that are secure in the Random Oracle Model, but 

151: for which {\em any implementation}\/ of the random oracle results in 

152: insecure schemes. 

153: 

154: In the process of devising the above schemes, we consider possible 

155: definitions for the notion of a ``good implementation'' of a random 

156: oracle, pointing out limitations and challenges.

157: \end{abstract}

158: 

159: \vfill

160: \paragraph{Keywords:} Correlation Intractability, 

161: \BI

162: \item Cryptography (Encryption and Signature Schemes, The Random Oracle model); 

163: \item Complexity Theory (diagonalization, application of CS-Proofs).  

164: \EI 

165: \medskip\ni{~}

166: \end{titlepage}

167: 

168: 

169: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

170: \section{Introduction}\label{intro.sec}

171: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

172: A popular methodology for designing cryptographic protocols consists 

173: of the following two steps. One first designs an {\em ideal}\/ system 

174: in which all parties (including the adversary) have oracle access to 

175: a truly random function, and proves the security of this ideal system. 

176: Next, one replaces the random oracle by a ``good cryptographic hashing 

177: function'' (such as MD5 or SHA), providing all parties (including the 

178: adversary) with a succinct description of this function. Thus, one 

179: obtains an {\em implementation}\/ of the ideal system in a ``real-world'' 

180: where random oracles do not exist. 

181: This methodology, explicitly formulated by Bellare and Rogaway~\cite{BeRo93} 

182: and hereafter referred to as the {\em random oracle methodology}, 

183: has been used in many works (see, for example, 

184: \cite{FiSh86,Sc91,GuQu88,Ok92,BeRo93,Mi94,BeRo96,PoSt96}). 

185: 

186: Although the random oracle methodology seems to be useful in practice, 

187: it is unclear how to put this methodology on firm grounds.  One can 

188: indeed make clear statements regarding the operation of the ideal system, 

189: but it is not clear what happens when one replaces the random oracle by 

190: a function that has a succinct description available to all parties. 

191: What one would have liked is (at least a definition of) a class of functions 

192: that, when used to replace the random oracle, maintains the security of the 

193: ideal scheme. The purpose of this work is to point out fundamental 

194: difficulties in proceeding towards this goal. We demonstrate that 

195: the traditional approach of providing a {\em single} robust definition 

196: that supports a wide range of applications is bound to fail. 

197: That is, one  cannot expect to see definitions such as of pseudorandom 

198: generators or functions~\cite{BlMi84,yao82a,ggm86}, and general 

199: results of the type saying that these can be used in any application 

200: in which parties are restricted merely by computing resources. 

201: Specifically, we identify a specific property

202: of the random oracle, that

203: seems to capture one aspect of the random oracle methodology 

204: (and in particular seems to underline heuristics such as the 

205: Fiat--Shamir transformation of a three-round identification scheme 

206: into a signature scheme in the ~\cite{FiSh86}). 

207: We show that even a minimalistic formulation of this property, 

208: called {\sf correlation intractability}, 

209: cannot be obtained by any fully specified 

210: function (or function ensemble). 

211: 

212: To demonstrate the implications of the above to the security of 

213: cryptographic systems, we show that systems whose security relies 

214: on the ``correlation intractability'' of their oracle may be secure 

215: in the \ROM, and yet be insecure when implemented using any fully 

216: specified function (or function ensemble). In particular, we describe 

217: schemes for digital signatures and public-key encryption that are 

218: secure in the \ROM, but for which any implementation yields insecure 

219: schemes. This refutes the belief that a security proof in the \ROM\ 

220: means that there are no ``structural flaws'' in the scheme.

221: 

222: 

223: \subsection{The Setting}

224: %--------------------------

225: For the purpose of the following discussion, a cryptographic system consists

226: of a set of parties, which are 

227: modeled by probabilistic polynomial time interactive Turing machines.

228: A {\sf cryptographic application} 

229: comes with a security requirement specifying 

230: the adversary's abilities and when the latter is considered successful. 

231: The abilities of the adversary include its computational power 

232: (typically, an arbitrary polynomial-time machine) and the ways in which 

233: it can interact with the other parties. 

234: The {\em success} of the adversary is defined by means of a predetermined 

235: polynomial-time predicate of the {\em application's global view}.%

236: \footnote{\ 

237: The application's global view consists of the initial inputs of all 

238: the parties (including the adversary), their internal coin tosses, and 

239: all the messages which were exchanged among them.

240: }\ 

241: A system is considered {\sf secure} if any adversary with the 

242: given abilities has only a negligible probability of success. 

243: 

244: \subsubsection{The Random Oracle Model} 

245: In a scheme that operates in the \ROM, all parties (including the 

246: adversary) interact with one another as usual 

247: interactive machines, but in addition they can make oracle queries. It 

248: is postulated that all oracle queries, regardless of the identity of 

249: the party making them, are answered by a single function, denoted $\f$, 

250: that is uniformly selected among all possible functions. The set of 

251: possible functions is determined by a length function, $\rlen(\cdot)$,

252: and by the security parameter of the system. Specifically, given 

253: security parameter $k$ we consider functions mapping 

254: $\bitset^{{\rm poly}(k)}$ to $\bitset^{\rlen(k)}$.

255: A set of interactive oracle machines as above corresponds to an 

256: {\em ideal system for one specific application}. 

257: Security of an ideal system is defined as usual. That is,

258: an ideal system is considered secure if any adversary with the 

259: given abilities (including oracle access)

260: has only a negligible probability of success. Here the probability is

261: taken also over the choices of the random oracle.

262: 

263: 

264: 

265: \subsubsection{Implementing an ideal system}

266: Loosely speaking, by ``implementing'' a particular ideal system we mean 

267: using an easy-to-evaluate function $f$ instead of the random oracle. 

268: That is, whenever the ideal system queries the oracle with a value 

269: $x$, the implementation instead evaluates $f(x)$. 

270: Formally defining this notion, however, takes some care. Below we 

271: briefly examine (and discard of) the notion of implementation by a 

272: single function, and then present the notion of implementation by a 

273: function ensemble, which is the notion we use throughout the paper. 

274: 

275: 

276: \paragraph{Implementation by a single function.} 

277: In accordance with the above discussion, 

278: each ideal system (for some specific application), $\Pi$, is 

279: transformed into a real system (for the same application) by

280: transforming each interactive oracle machine, 

281: into a standard interactive machine in the natural manner.

282: That is, each oracle call is replaced by the evaluation of

283: a fixed function $f$ on the corresponding query.% 

284: \footnote{\ Formally, the function $f$ also takes as input the 

285: security parameter $k$, so that the function $f_k(\cdot) \eqdef 

286: f(k,\cdot)$ maps $\bitset^{{\rm poly}(k)}$ to $\bitset^{\rlen(k)}$.}

287: 

288: The above system is called an {\em implementation of $\Pi$ using function 

289: $f$}. The adversary, attacking this implementation, may mimic the behavior 

290: of the adversary of the ideal system, by evaluating $f$ at arguments of 

291: its choice,  but it needs not do so. 

292: In particular, it may obtain some global insight into the structure of 

293: the function $f$, and use this insight towards its vicious goals. An 

294: implementation is called {\sf secure} if any adversary attacking it may 

295: succeed only with negligible probability, where the success event is defined 

296: exactly as in the ideal system (i.e., it is defined by the same 

297: polynomial-time computable predicate of the application's global view). 

298: 

299: Using this notion of an implementation, we would like to say that a 

300: function $f$ is a ``good implementation of a random oracle'' if for any 

301: ideal system $\Pi$, security of $\Pi$ implies security of the

302: implementation of $\Pi$ using $f$. 

303: It is very easy to see, however, that no (single) polynomial-time 

304: computable function can provide a good implementation of a random oracle. 

305: Consider, for example, a candidate function $f$. Then, a (contrived) 

306: application for which $f$ does not provide a good implementation 

307: consists of an oracle machine (representing an honest 

308: party) that upon receiving a message $m$, makes query $m$ to the oracle 

309: and reveals its private input if the oracle answers with $f(m)$. 

310: Suppose that the adversary is deemed successful whenever the honest party 

311: reveals its private input. Clearly, this ideal system is secure (in the 

312: Random Oracle Model), since the random oracle will return the value

313: $f(m)$ only with negligible probability; 

314: however, its implementation using $f$ is certainly not secure. 

315: 

316: 

317: \paragraph{Implementation by a function ensemble.} 

318: In face of the failure of the above naive attempt, 

319: a more sophisticated interpretation is indeed called for. 

320: Here one considers the substitution of the random oracle by a function 

321: randomly selected from a collection of functions. In this setting, we 

322: have a ``system set-up'' phase, in which the function is selected once 

323: and for all, and its description is available to all parties.%

324: \footnote{\ 

325: In the sequel we consider examples of public key signature and 

326: encryption schemes. In these schemes, the initialization (set-up)

327: step is combined with the key-generation step of the original scheme.

328: }\ 

329: After this set-up phase, this function is used in place of the 

330: random oracle just as above. 

331: A little more precisely, 

332: we consider a function ensemble ${\cal F} = \{F_k | k\in\N\}$, where 

333: $$

334: F_k = \{

335: f_s\!:\!\bitset^{{\rm poly}(k)}\!\to\!\bitset^{\rlen(k)}

336: \}_{s\in\bitset^k}\;,

337: $$ 

338: such that there exists a polynomial time algorithm 

339: that, on input $s$ and $x$, returns $f_s(x)$. 

340: The implementation of an ideal system, $\Pi$, by the function ensemble 

341: $\cal F$ is obtained as follows. On security parameter $k$, we uniformly 

342: select $s\in\bitset^k$, and make $s$ available to all parties including 

343: the adversary. 

344: Given this initialization phase, we replace each oracle call of 

345: an interactive oracle machine by the evaluation of the function $f_s$ 

346: on the corresponding query. The resulting system is called an {\em 

347: implementation of $\Pi$ using function ensemble $\cal F$}.

348: 

349: Again, the adversary may (but need not necessarily) mimic the behavior of 

350: the adversary in the Random Oracle Model by evaluating $f_s$ at arguments 

351: of its choice. 

352: Such a real system is called {\sf secure} if any adversary attacking it 

353: has only a negligible probability of success, where the probability is taken 

354: over the random choice of $s$ as well as the coins of all the parties. 

355: As before, we would like to say that an ensemble ${\cal F}$ provides a 

356: ``good implementation of a random oracle'' if for every ideal system $\Pi$, 

357: if $\Pi$ is secure then so is the implementation of $\Pi$ using $\cal F$. 

358: Notice that in this case, the contrived example from above does not work 

359: anymore, since the success event must be independent of the random choice 

360: of $s$. Nonetheless, this work implies that 

361: no function ensemble can provide a good implementation of a random oracle. 

362: We elaborate in the next subsection.

363: 

364: 

365: \subsection{Our Results}

366: %-----------------------

367: \subsubsection{Correlation intractability.}

368: One property we certainly expect from a good implementation of a random 

369: oracle is that it should be infeasible to find inputs to the function 

370: that stand in some ``rare'' relationship with the corresponding outputs.

371: Indeed, many applications of the random-oracle methodology (such as 

372: the Fiat-Shamir heuristic) assume that it is infeasible to find an 

373: input-output pair that stands in a particular relations induced by 

374: the application. 

375: Trying to formulate this property, we may require that given the description 

376: of the function it is hard to find a sequence of preimages that together 

377: with their images (under this function) satisfy some given relation. 

378: Clearly, this can only hold for relations for which finding such sequences 

379: is hard in the \ROM. %\ (i.e., w.r.t a random oracle). 

380: That is, {\sc if} it is hard to find a sequence of 

381: preimages that together with their images under a random oracle satisfy 

382: relation $R$, {\sc then} given the description of a ``good'' function $f_s$ 

383: it should be hard to find a sequence of preimages that together with their 

384: images under $f_s$ satisfy $R$. 

385: 

386: In fact, we mainly consider the task of 

387: finding a {\em single} 

388: preimage that together with its image satisfies some property. Loosely 

389: speaking, a relation is called {\sf evasive} if when given access to a 

390: random oracle $\f$, it is infeasible to find a string $x$ so that the pair 

391: $(x,\f(x))$ is in the relation. (For instance, the relation

392: $\{(x,0^{\rlen(k)}):x\in\bitset^*\}$ is evasive. The relation

393: $\{(x,0y):x\in\bitset^*,y\in\bitset^{\rlen(k)-1}\}$ is not.) 

394: A function ensemble $\cal F$ (as above) is called {\sf correlation 

395: intractable} if for every evasive relation, given the description of 

396: a uniformly selected function $f_s\in F_k$ it is infeasible to find an 

397: $x$ such that $(x,f_s(x))$ is in the relation. 

398: We show that

399: 

400: \BIT

401: There exist no correlation intractable function ensembles. 

402: \label{fail1.thm}

403: \EIT

404: 

405: 

406: \paragraph{Restricted correlation intractability.} 

407: The proof of the above negative result relies on the fact that 

408: the description of the function is shorter than its input. Thus 

409: we also investigate the case where one restricts the function $f_s$ 

410: to inputs whose length is less than the length of $s$. We show that 

411: the negative result can be extended to the case where the function 

412: description is shorter than the sum of the 

413: lengths of the input and output of the function. (Furthermore, if one 

414: generalizes the notion of \corInty\ to relations on sequences of inputs 

415: and outputs, then the negative result holds as long as the total length 

416: of all the inputs and outputs is more than the length of the function 

417: description.) 

418: %

419: This still leaves open the possibility that there exist function 

420: ensembles that are correlation intractable with respect to 

421: input-output sequences of a-priori bounded total length.  

422: See further discussion in Section~\ref{sec-lengths}.

423: 

424: 

425: \subsubsection{Failure of the Random Oracle Methodology}

426: 

427: Upon formulating the random oracle methodology, 

428: Bellare and Rogaway did warn 

429: that a proof of security in the Random Oracle Model should {\sc not} 

430: be taken as guarantee to the security of implementations (in which the 

431: Random Oracle is replaced by functions such as MD5)~\cite{BeRo93}. 

432: However, it is widely believed that a security proof in the {\ROM} 

433: means that there are no ``structural flaws'' in the scheme.

434: That is, any attack against an implementation of this scheme must 

435: take advantage of specific flaws in the function that is used to 

436: implement the oracle. In this work we demonstrate that these beliefs 

437: are false. Specifically, we show that 

438: 

439: \BIT

440: There exists encryption and signature schemes that are secure in the 

441: Random Oracle Model, but have {\sc no secure implementation} in the 

442: real model (where a Random Oracle does not exist).

443: That is, implementing these secure ideal schemes, using any function 

444: ensemble, results in insecure schemes. 

445: \label{fail2.thm}

446: \EIT

447: The encryption and signature schemes presented to prove 

448: Theorem~\ref{fail2.thm} are ``unnatural''.  We do not claim (or 

449: even suggest) that a statement as above holds with respect to 

450: schemes presented in the literature. 

451: Still, the lesson is that the mere fact that a scheme is secure 

452: in the Random Oracle Model does not necessarily imply that a particular 

453: implementation of it (in the real world) is secure, or even that this 

454: scheme does not have any ``structural flaws''. Furthermore, unless 

455: otherwise justified, such ideal scheme may have {\em no secure 

456: implementations at all}. 

457: 

458: In fact, our techniques are quite general and can be applied to

459: practically {\em any} cryptographic application. That is, given an 

460: ideal cryptographic application $A$, we can construct an 

461: ideal cryptographic application $A'$ such that 

462: $A'$ is just as secure as $A$ (in the \ROM), but $A'$ 

463: has {\em no secure implementation.} 

464: Hence, in this sense, security of an ideal system in the \ROM\ is a bad 

465: predictor of the security of an implementation of the system in real

466: life.

467: 

468: 

469: \subsection{Techniques}

470: Our proof of Theorem~\ref{fail2.thm} uses 

471: in an essential way 

472: non-interactive CS-proofs (in the \ROM),

473: as defined and constructed by Micali~\cite{Mi94}.%  

474: \footnote{\ 

475: The underlying ideas of Micali's construction~\cite{Mi94} 

476: can be traced to Kilian's construction~\cite{Ki92}

477: and to the Fiat--Shamir transformation~\cite{FiSh86}

478: (which is sound in the \ROM).}  

479: Interestingly, we only use the fact that non-interactive CS-proofs 

480: exist in the \ROM, and do not care whether or not these ideal CS-proofs 

481: have an implementation using any function ensembles 

482: (nor if non-interactive CS-proofs exists at all outside of the \ROM).

483: Specifically, CS-proofs are used to ``effectively verify''  

484: {\em any}\/ polynomial-time verifiable statement within time that 

485: is bounded by one {\em fixed}\/ polynomial. 

486: Furthermore, we use the fact that the definition of

487: CS-proofs guarantees that the complexity of generating such proofs 

488: is polynomial in the time required for ordinary verification.

489: See further discussion in Section~\ref{sec:csproofs}. 

490: 

491: 

492: \subsection{Related Work}

493: %------------------------

494: 

495: \paragraph{Correlation intractability.} 

496: Our definition of correlation-intractability is related to a definition 

497: by Okamoto \cite{Ok92}. Using our terminology, Okamoto considers 

498: function ensembles for which it is infeasible to form input-output 

499: relations with respect to a specific evasive relation~\cite[Def.~19]{Ok92} 

500: (rather than all such relations).

501: He uses the assumption that such function ensembles exists,

502: for a specific evasive relation in \cite[Thm.~20]{Ok92}.

503: 

504: \paragraph{Special-purpose properties of the \ROM.} 

505: First steps in the direction of identifying and studying useful 

506: special-purpose properties of the \ROM\ have been taken by 

507: Canetti~\cite{Ca97}. Specifically, Canetti considered a property 

508: called ``perfect one-wayness'', provided a definition of this 

509: property, constructions which possess this property (under some 

510: reasonable assumptions), and applications for which such functions 

511: suffice. Additional constructions have been suggested by 

512: Canetti, Micciancio and Reingold~\cite{CMR98}. Another context where

513: specific properties of the random oracle where captured and realized

514: is the signature scheme of Gennaro, Halevi and Rabin \cite{GHR99}.

515: 

516: 

517: \paragraph{Relation to Zero-Knowledge proofs.} 

518: Following the preliminary version of the current work~\cite{CGH98}, 

519: Hada and Tanaka 

520: observed that the existence of even restricted correlation intractable 

521: functions (in the non uniform model) would be enough to prove that 

522: 3-round auxiliary-input zero-knowledge AM proof systems only exist 

523: for languages in BPP \cite{HaTa99}. 

524: (Recall that auxiliary-input

525: zero-knowledge is seemingly weaker than black-box zero-knowledge,

526: and so the result of~\cite{HaTa99} is incomparable to prior work

527: of Goldreich and Krawczyk~\cite{GK} that showed 

528: that constant-round auxiliary-input zero-knowledge

529: AM proof systems only exist for languages in BPP.) 

530: 

531: \paragraph{Relation to ``magic functions''.} 

532: More recently, Dwork~{\etal} investigated  the notion 

533: of ``magic functions'', which is related to our {\corInt} 

534: functions \cite{magic}.  

535: Like {\corInty}, the definition of ``magic functions'' is 

536: motivated by the quest to capture the properties that are required from 

537: the hash function in the Fiat-Shamir heuristic. 

538: Correlation intractability seems like a general and natural property,

539: but is not known to be either necessary or sufficient for the 

540: Fiat-Shamir heuristic (which is a special case of the random oracle

541: methodology). In contrast, ``magic functions'' are explicitly 

542: defined as ``functions that make the Fiat-Shamir heuristic work''.  

543: In their paper \cite{magic}, Dwork~{\etal} demonstrated a relation 

544: between ``magic functions'' and 3-round zero-knowledge, 

545: which is similar to the relation between {\corInty} 

546: and zero-knowledge exhibited in \cite{HaTa99}. 

547: Specifically, they showed that the existence of ``magic functions'' 

548: implies the non-existence of some kind of 3-round zero-knowledge proof 

549: systems, as well as a weakened version of a converse theorem. 

550: 

551: 

552: \subsection{Organization}

553: \secref{sec-syntax} presents syntax necessary for the rest of 

554: the paper as well as review the definition of CS-proofs. 

555: \secref{sec-unpredict} discusses the reasoning that 

556: led us to define the {\corInty} property, and prove that even such 

557: a minimalistic definition cannot be met by a function ensemble. 

558: \secref{sec-insecure} presents our main negative results -- 

559: demonstrating the existence of secure ideal signature and encryption 

560: schemes that do not have secure implementations. Restricted {\corInty} 

561: is defined and studied in \secref{sec-lengths}. 

562: Three different perspectives on the results obtained in this paper are

563: presented in \secref{sec-conclusions}.

564: 

565: 

566: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

567: \section{Preliminaries}\label{sec-syntax}

568: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

569: We consider probability spaces defined over executions

570: of probabilistic machines. Typically, we consider the probability

571: that an output generated by one machine $M_1$ satisfies a

572: condition that involves the execution of a second machine $M_2$.

573: For example, we denote 

574: by $\prob[y\gets M_1(x)\,,\,|y|\!=\!|x|\,\&\,M_2(y)\!=\!1]$

575: the probability that on input $x$, machine $M_1$ outputs 

576: a string that has length $|x|$ and is accepted by machine $M_2$. 

577: That is, $y$ in the above notation represents a random variable

578: that may be assigned arbitrary values in $\bitset^*$,

579: conditions are made regarding this $y$,

580: and we consider the probability that these conditions are

581: satisfied when $y$ is distributed according to $M_1(x)$. 

582: 

583: \subsection{Function Ensembles}\label{sec-ensembles}

584: To make the discussion in the Introduction more precise, we explicitly 

585: associate a length function, $\rlen:\intfnc$, with the output of the 

586: random oracle 

587: and its candidate implementations. We always assume that the length 

588: functions are super-logarithmic and polynomially bounded (i.e. 

589: $\omega(\log k) \leq \rlen(k) \leq \poly(k)$).  We refer to an 

590: oracle with length function $\rlen$ as an {\sf $\rlen$-oracle}. 

591: On security parameter $k$, each answer of the oracle  is a 

592: string of length $\rlen(k)$. A candidate implementation of a random 

593: $\rlen$-oracle is an $\rlen$-ensemble as defined below. 

594: 

595: 

596: \BD[function ensembles] \label{def-ensemble}

597: Let $\rlen : \intfnc$ be a length function. 

598: An {\sf $\rlen$-ensemble} 

599: is a sequence ${\cal F} = \{F_k\}_{k \in N}$ of families of functions, 

600: $F_k = \{ f_s:\bitset^*\!\to\!\bitset^{\rlen(k)}\}_{s \in \bitset^k}$, 

601: so that the following holds

602: \begin{description}

603: \item[{\rm Length requirement.}]  

604: For every $s\in\bitset^k$ and every $x\in\bitset^*$, $|f_s(x)| = \rlen(k)$. 

605: \item[{\rm Efficiency requirement.}]

606: There exists a polynomial-time algorithm {\sc Eval} 

607: so that for every $s, x \in \bitset^*$, 

608: it holds that $\mbox{\sc Eval}(s,x) = f_s(x)$.

609: \end{description}

610: In the sequel we often call $s$ the {\sf description} 

611: or the {\sf seed} of the function $f_s$. 

612: \ED

613: 

614: 

615: \BRK \label{rmk-seed-len}

616: The length of the seed in the above definition serves as 

617: a ``security parameter'' and is meant to control the ``quality'' 

618: of the implementation. 

619: It is important to note that although $f_s(\cdot)$ is syntactically 

620: defined on every input, in a cryptographic applications it is only used 

621: on inputs of length at most $\poly(|s|)$. We stress that all results 

622: presented in this paper refer to such usage. 

623: \ERK

624: 

625: \BRK \label{rmk-restricted-corint}

626: One may even envision applications in which a more stringent condition 

627: on the use of $f_s$ holds. Specifically, one may require that the 

628: function $f_s$ be only applied to inputs of length at most $\dlen(|s|)$, 

629: where $\dlen : \intfnc$ is a specific (polynomially bounded) length 

630: function (e.g., $\dlen(k) = 2k$).  We discuss the effects of making 

631: such a stringent requirement in \secref{sec-lengths}. 

632: \ERK

633: 

634: \subsection{CS Proofs} \label{sec:csproofs}

635: \def\prv{\mbox{\sc Prv}}

636: \def\badP{\mbox{\sc Bad}}

637: \def\ver{\mbox{\sc Ver}}

638: 

639: Our construction of signature and encryption schemes that are secure in 

640: the {\ROM} but not in the ``real world'' uses CS-proofs as defined and 

641: constructed by Micali~\cite{Mi94}. 

642: Below, we briefly recall the relevant definitions and results.

643: 

644: A CS-proof system consists of a prover, $\prv$, 

645: that is trying to convince a verifier, $\ver$, 

646: of the validity of an assertion of the type 

647: {\em machine $M$ accepts input $x$ within $t$ steps}.\footnote{\

648: When $t$ is presented in binary, such valid assertions form

649: a complete language for the class (deterministic) exponential time.} 

650: The central feature of CS-proofs is that the running-time of the prover 

651: on input $x$ is (polynomially) related to the {\em actual} running time 

652: of $M(x)$ rather than to the global upper bound $t$; furthermore, the

653: verifier's running-time is poly-logarithmic related to $t$. 

654: (These conditions are expressed in the {\em additional efficiency 

655: requirements} in \defref{def-cs-proofs} below.)

656: 

657: In our context, we use non-interactive CS-proofs 

658: that work in the \ROM; that is, 

659: both prover and verifier have access to a common random oracle.

660: The prover generates an alleged proof 

661: that is examined by the verifier. 

662: A construction for such CS-proofs was presented by Micali~\cite{Mi94}, 

663: using ideas that can be traced to Kilian's construction~\cite{Ki92},

664: and requires no computational assumptions. 

665: Following is the formulation of CS-proofs, as defined in~\cite{Mi94}.

666: 

667: In the formulation below, the security parameter $k$ 

668: is presented in unary to both parties, whereas the global time bound 

669: $t$ is presented in unary to the prover and in binary to the verifier. 

670: This allows the (polynomial-time) prover to run in time polynomial

671: in $t$, whereas the (polynomial-time) verifier may only run in

672: time that is poly-logarithmic in $t$. 

673: (Observe that it is \emph{not required} that $t$ is bounded above by 

674: a polynomial in $|x|$. In fact, in our arguments, we shall use a 

675: slightly super-polynomial function $t$ (i.e., $t(n)=n^{\log n}$).) 

676: Finally, we mention that both the prover and the verifier in the definition 

677: below are required to be deterministic machines. See some discussion in 

678: Remark~\ref{rmk-det-verifier} below. 

679: 

680: 

681: \BD[Non-interactive CS proofs in the \ROM] \label{def-cs-proofs}

682: A {\sf CS-proof system} consists of two {\em(deterministic)} 

683: polynomial-time oracle machines, a prover $\prv$ and a verifier 

684: $\ver$, which operate as follows: 

685: \begin{itemize}

686: \item 

687: On input $(1^k,\vect{M},x,1^t)$ and access to an oracle $\f$, 

688: the prover computes a proof $\pi = \prv^\f(1^k,\vect{M},x,1^t)$

689: such that $|\pi|=\poly(k,|\vect{M}|,|x|,\log t)$. 

690: 

691: \item 

692: On input $(1^k,\vect{M},x,t,\pi)$, with $t$ encoded in binary, 

693: and access to $\f$, 

694: the verifier decides whether to accept or reject the proof $\pi$

695: {\rm(i.e., $\ver^\f(1^k,\vect{M},x,t,\pi)

696:                \in\{{\tt accept},{\tt reject}\}$)}.

697: \end{itemize}

698: The proof system satisfies the following conditions, where the 

699: probabilities are taken over the random choice of the oracle $\f$:

700: 

701: \begin{description}

702: \item[{\rm Perfect completeness:}]

703:  For any $M,x,t$ such that machine $M$ accepts the string $x$ within

704:  $t$ steps, and for any $k$,

705:  \[\Pr_\f\left[

706:      \begin{array}{l}\pi \gets \prv^\f(1^k,\vect{M},x,1^t),\\

707:      \ver^\f(1^k,\vect{M},x,t,\pi)={\tt accept}\end{array}\right]

708:     \; = 1 \]

709: 

710: \item[{\rm Computational soundness:}]

711:  For any polynomial time oracle machine $\badP$ and any input $w =

712:  (\vect{M},x,1^t)$ such that $M$ {\em does not} accepts $x$ within

713:  $t$ steps, it holds that

714:  \[\Pr_\f\left[\begin{array}{l}

715:                 \pi \gets \badP^\f(1^k,\vect{M},x,1^t),\\

716:                 \ver^\f(1^k,\vect{M},x,t,\pi)={\tt accept}

717:                \end{array} \right] \leq \frac{poly(k+|w|)}{2^k} \]

718: 

719: \item[{\rm Additional efficiency conditions:}\footnotemark]

720:  The running-time of the prover $\prv$ on input $(1^k, \vect{M},x,1^t)$ 

721:  is (polynomially) related to the {\em actual} running time of $M(x)$, 

722:  rather than to the global upper bound $t$.  That is, there exists a 

723:  fixed polynomial $p(\cdot)$, such that 

724:  \[

725:    T_{_{PRV}}\left(1^k, \vect{M},x,1^t\right) \leq p(k,\min\{t,T_M(x)\})

726:  \] 

727:  where $T_A(x)$ denotes the running time of machine $A$ on input $x$. 

728: \footnotetext{\

729: By the above, the running time of $\prv$ on input $(1^k,\vect{M},x,1^t)$

730: is at most $\poly(k,|\vect{M}|,|x|,t)$, 

731: whereas the running time of $\ver$ on input $(1^k,\vect{M},x,t,\pi)$

732: is at most $\poly(k,|\vect{M}|,|x|,|\pi|,\log t)$.

733: The following condition provide even lower running time bound

734: for the prover.} 

735: \end{description}

736: \ED

737: 

738: 

739: \BR{Oracle output length} \label{rmk-output-length}

740: The above definition does not specify the output length of the oracle 

741: (i.e., the length of the answers to the oracle queries). In some cases 

742: it is convenient to identify this output length with the security 

743: parameter, but in many case we do not follow this convention (e.g., 

744: in \prpref{prp-cs-prf} below). 

745: In any case, it is trivial to implement an oracle with one output 

746: length given an oracle with different output length, so we allow 

747: ourselves to ignore this issue. 

748: \ER

749: 

750: \BR{Deterministic verifier} \label{rmk-det-verifier}

751: Recall that \defref{def-cs-proofs} mandates that both the prover and 

752: verifier are deterministic. 

753: Indeed this deviates from the tradition (in this area) of

754: allowing the verifier to be probabilistic; but Micali's

755: construction (in the \ROM) happens to employ a deterministic

756: verifier (cf.~\cite{Mi94}). This issue is not essential to our

757: main results, but plays an important role in the proof of

758: Proposition~\ref{Nissim.prop2} (due to K.~Nissim).

759: We note that when working in the \ROM\/

760: (and only caring about completeness and soundness),

761: one may assume without loss of generality that the prover is

762: deterministic (because it can obtain adequate randomness by

763: querying the oracle). This does not hold with respect to the

764: verifier, since its coin tosses must be unknown to the prover. 

765: \ER

766: 

767: 

768: \BT[Micali~\cite{Mi94}] \label{thm-cs-proofs}

769: There exists a non-interactive CS proof system in the \ROM. 

770: \ET 

771: 

772: For the proof of our construction (\thmref{sign.thm}), we will 

773: need a different soundness condition than the one from above.

774: Specifically, we need to make sure that given the machine $M$

775: (and the complexity bound $t$), it is hard to find {\em any pair}

776: $(x,\pi)$ such that $M$ does not accept $x$ within $t$ steps and yet

777: $\ver$ will accept $\pi$ as a valid CS-proof to the contrary.

778: One way to obtain this soundness property from the original one,

779: is by postulating that when the verifier is given a proof for an

780: assertion $w = (\vect{M},x,t)$, 

781: it uses security parameter $k+|w|$ (rather than just $k$).  

782: Using a straightforward counting argument we get: 

783: 

784: \BP{~}\label{prp-cs-prf} 

785: Let $(\prv,\ver)$ be a CS proof system. % in the \ROM. 

786: Then for every polynomial time 

787: oracle machine $\badP$, there exists a polynomial $q(\cdot)$, such that 

788: for every $k$ it holds that

789: \[

790: \e_{\rm bad}(k) \eqdef

791: \Pr_\f\left[\begin{array}{l}

792:  (\pi,w) \gets \badP^\f(1^{k}), \mbox{ where } w = (\vect{M},x,t),\\

793:  \mbox{s.t. machine $M$ does not accept $x$ within $t$ steps}\\

794:  \ \ \ \ \mbox{ and yet }\ver^\f(1^{k+|w|},w,\pi)={\tt accept}

795: \end{array} \right] \leq \frac{q(k)}{2^{k}}

796: \]

797: \EP

798: 

799: 

800: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

801: \section{Correlation Intractability} \label{sec-unpredict}

802: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

803: In this section we present and discuss the difficulty 

804: of defining the intuitive requirement that a function ensemble 

805: ``behaves like a random oracle'' even when its description is given. 

806: In particular, we show that

807: even some minimalistic definitions cannot be realized.

808: 

809: 

810: \paragraph{An obvious failure.}

811: We first comment that an obvious maximalistic definition, which amount 

812: to adopting the pseudorandom requirement of~\cite{ggm86}, fails poorly. 

813: That is, we cannot require that an (efficient) algorithm that is

814: given the description of the function cannot distinguish its input-output 

815: behavior from the one of a random function, because the function 

816: description determines its input-output behavior. 

817: 

818: \paragraph{Towards a minimalistic definition.}

819: Although we cannot require the value of a fully specified function 

820: to be ``random'', we may still be able to require that it has some 

821: ``unpredictability properties''.  

822: For example, we may require that, given a description 

823: of a family and a function chosen at random from a this family,

824: it is hard to find two preimages that the function maps to the same 

825: image. Indeed, this sound definition coincides with the well-known 

826: {\em collision-intractability} property \cite{Da87}. 

827: Trying to generalize, we may replace the ``equality of images'' relation 

828: by any other relation among the pre-images and images of the function. 

829: Namely, we would like to say that an ensemble is {\em \corInt\ } if for 

830: {\em any} relation, given the description of a randomly chosen function, 

831: it is infeasible to find a sequence of preimages that together with their 

832: images satisfy this relation. 

833: 

834: This requirement, however, is still unreasonably strong since there 

835: are relations that are easy to satisfy even in the \ROM. We therefore 

836: restrict the above infeasibility requirement by saying that it holds 

837: only with respect to relations that are hard to satisfy in the \ROM. 

838: That is, {\sc if} it is hard to find a sequence of preimages that together 

839: with their images under a random function satisfy relation $R$, {\sc then} 

840: given the description of a randomly chosen function $f_s$ it should be 

841: hard to find a sequence of preimages that together with their images 

842: under $f_s$ satisfy $R$. 

843: 

844: This seems to be a minimalistic notion of \corInt\ ensemble of 

845: functions, yet we show below that no ensemble can satisfy it. 

846: In fact, in the definition below we only consider the task of 

847: finding a single preimage that together with its image satisfies some 

848: property. Namely, instead of considering all possible relations, we only 

849: consider binary ones. Since we are showing impossibility result, this 

850: syntactic restriction only strengthens the result. 

851: 

852: 

853: \subsection{Actual Definitions} 

854: 

855: We start with a formal definition of a relation 

856: that is hard to satisfy in the random oracle model.

857: 

858: \BD[Evasive Relations]

859: \label{def-admissible}

860: A binary relation $R$ is said to be {\sf evasive} with respect 

861: to length function $\rlen$ if for any 

862: probabilistic polynomial time oracle machine $M$ 

863: $$\Pr_\f[x\gets M^\f(1^k),\;\, % \mbox{\rm s.t.}\;\;|x|=k \mbox{\rm  and }

864: 	(x,\f(x))\!\in\!R]\;\;=\;\;\negl(k)$$

865: where $\f:\bitset^*\to\bitset^{\rlen(k)}$ is a uniformly 

866: chosen function and $\negl(\cdot)$ is a negligible function.%

867: \footnote{\ 

868: A function $\mu\!:\!\N\to\!R$ is negligible if for every positive 

869: polynomial $p$ and all sufficiently large $n$'s, $\mu(n)<1/p(n)$.

870: } 

871: \ED

872: A special case of evasive relations consists of $R$'s for which there 

873: exists a negligible function $\negl(\cdot)$ so that for all $k$ 

874: $$\max_{x \in \bitset^*}\ \ \left\{

875:   \Pr_{y\in\bitset^{\rlen(k)}}[(x,y)\!\in\!R\,]\,\right\}\ =\ \negl(k)

876: $$

877: (All the binary relations used in the sequel falls into this category.) 

878: The reason such an $R$ is evasive is that any oracle machine, $M$, 

879: making at most $\poly(k)$ queries to a random $\f$ satisfies

880: \begin{eqnarray*}

881: \Pr_\f[x\gets M^\f(1^k),\;\, (x,\f(x))\!\in\!R] 

882: &\leq& \poly(k)\cdot

883: 	\max_{x \in \bitset^*}\{\ \Pr_\f[(x,\f(x))\!\in\!R]\ \}\\

884: &\leq& \poly(k) \cdot \negl(k) 

885: \end{eqnarray*}

886: 

887: 

888: We are now ready to state our minimalistic definition 

889: of a \corInt\ ensemble: 

890: \BD[\CorInty]

891: \label{def-unpredict}

892: Let $\rlen : N \to N$ be length function, 

893: and let ${\cal F}$ be an $\rlen$-ensemble. 

894: \BI

895: \item 

896: Let $R\subseteq\bitset^*\times\bitset^*$ be a binary relation. 

897: We say that ${\cal F}$ is {\sf \corInt\/ with respect to $R$} 

898: if for every probabilistic polynomial-time machine $M$ 

899: it holds that

900: \[

901: \Pr_{s \in \bitset^k}[ x \gets M(s),\;\; %|x| = k \mbox{\rm  and }

902: 	(x,f_s(x)) \in R ] = \negl(k)

903: \]

904: where $\negl(\cdot)$ is a negligible function, and the probability 

905: is taken over the choice of $s \in \bitset^k$ and the coins of $M$. 

906: \item 

907: We say that ${\cal F}$ is {\sf \corInt} if it is \corInt\/ with

908: respect to every evasive (w.r.t. $\rlen$) relation, 

909: \EI 

910: \ED

911: 

912: \BRK \label{rmk-weak-corint}

913: In the above definition we quantify over all evasive relations. 

914: A weaker notion, called {\sf weak \corInty}, is obtained by quantifying 

915: only over all polynomial-time recognizable evasive relations (i.e., 

916: we only consider those relations $R$ such that there exists a polynomial 

917: time algorithm that, given $(x,y)$, decides whether or not $(x,y) \in R$). 

918: In the sequel we consider both notions. 

919: \ERK

920: 

921: \subsection{Correlation-intractable ensembles do not exist} 

922: \label{sec.no-corint}

923: %----------------------------------------------------------

924: 

925: \BT\label{no-impl1} 

926: There exist no \corInt\ ensembles, not even in the weak sense. 

927: \ET

928: 

929: \begin{proof}

930: Let $\rlen$ be a length function and let ${\cal F}=\{f_s\}$

931: be an $\rlen$-ensemble. We define the binary relation: 

932: 

933: \begin{equation}

934: \label{eq-rf}

935: R^{\cal F} \eqdef \bigcup_k \left\{(s,f_s(s)) : s\in\bitset^k\right\}

936: \end{equation}

937: %

938: Clearly, this relation is polynomial-time recognizable, since $f_s$ 

939: can be computed in polynomial time. Also, the relation is evasive 

940: (w.r.t. $\rlen$) since for every $x \in \bitset^*$ there is at most

941: one $y \in \bitset^{\rlen(k)}$ satisfying $(x,y) \in R^{\cal F}$, 

942: \footnote{

943: Such a $y$ exists if and only if $\rlen(|x|)=\rlen(k)$.

944: }\ 

945: and so 

946: $$\Pr_y[(x,y) \in R^{\cal F}] \leq 2^{-\rlen(k)}=2^{-\omega(\log k)}

947: =\negl(k)\,.

948: $$ 

949: On the other hand, consider the machine $I$ that computes the 

950: identity function, $I(x) = x$ for all $x$. It violates the \corInty\ 

951: requirement, since for all $k$, 

952: $$

953: \Pr_{s\in\bitset^k}[(I(s),f_s(I(s)))\in R^{\cal F}]

954: \ =\ \Pr_{s\in\bitset^k}[(s,f_s(s))\in R^{\cal F}]

955: \ =\ 1\,.

956: $$

957: In fact, since $R^{\cal F}$ is polynomial-time recognizable,

958: even the weak \corInty\ of $\cal F$ is violated. 

959: \end{proof}

960: 

961: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

962: \section{Failure of the Random Oracle Methodology}

963: \label{sec-insecure}

964: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

965: This section demonstrates that the security of a cryptographic scheme 

966: in the \ROM\/ does not always imply its security under some specific 

967: choice of a ``good hash function'' that is used to implement 

968: the random oracle.  To prove this statement we construct signature and 

969: encryption schemes, which are secure in the \ROM, yet for which {\em 

970: any implementation} of the random oracle yield insecure schemes. Put 

971: in other words, although the ideal scheme is secure, any implementation 

972: of it is necessarily insecure. 

973: 

974: The underlying idea is to start with a secure scheme (which may or may 

975: not use a random oracle) and modify it to get a scheme that is secure 

976: in the \ROM, but such that its security is easily violated when trying 

977: to replace the random oracle by any ensemble. This is done by using  

978: evasive relations as constructed in \thmref{no-impl1}. 

979: The modified scheme starts by trying to find a preimage that 

980: together with its image yields a pair in the evasive relation. In case 

981: the attempt succeeds, the scheme does something that is clearly insecure 

982: (e.g., 

983: output the secret key). 

984: Otherwise, the scheme behaves as the original (secure) 

985: scheme does. The former case (i.e., finding a pair in the relation) will 

986: occur rarely in the \ROM, thus the scheme will maintain its security 

987: there. However, it will be easy for an adversary to make sure that the 

988: former case always occurs under any implementation 

989: of the \ROM,  thus no implementation may be secure.  

990: We start with the case of a signature scheme, 

991: and present the construction in three steps. 

992: 

993: \BI

994: \item

995: In the first step we 

996: carry out the above idea in a naive way. This allows us to

997: prove a weaker statement, saying that for any function ensemble 

998: $\cal F$, there exists a signature scheme that is secure in the 

999: \ROM, but is not secure when implemented using $\cal F$. 

1000: 

1001: This, by itself, means that one cannot construct a function ensemble 

1002: that provides secure implementation of any cryptographic scheme that 

1003: is secure in the \ROM.  But it does not rule out the possibility (ruled 

1004: out below) that for any cryptographic scheme that is secure in the 

1005: \ROM\ there exists a secure implementation (via a different function 

1006: ensemble). 

1007: 

1008: \item 

1009: In the second step we use diagonalization techniques to reverse the 

1010: order of quantifiers. Namely, we show that there exists a signature 

1011: scheme that is secure in the \ROM, but for which {\em any} implementation

1012: (using any function ensemble) results in an insecure scheme. However, 

1013: the scheme constructed in this step utilizes signing and verification 

1014: procedures that run in (slightly) super-polynomial time.

1015: 

1016: \item 

1017: In the third step we use CS-proofs \cite{Mi94} to get rid of the 

1018: super-polynomial running-time (of the legitimate procedures), 

1019: hence obtaining a standard signature scheme that is secure in the \ROM, 

1020: but has no secure implementation. 

1021: Specifically, in this step we use CS-proofs as a tool to 

1022: ``diagonalize against all polynomial-time ensembles in polynomial 

1023: time''. (As noted by Silvio Micali, this technique may be useful also 

1024: in other settings where diagonalization techniques are applied.) 

1025: \EI

1026: %

1027: The reader is referred to~\cite{gmr88} for basic terminology regarding

1028: signature schemes and corresponding notions of security. As a starting 

1029: point for our constructions, we use a signature scheme, denoted 

1030: ${\cal S} = (G,S,V)$, where $G$ is the key-generation algorithm, $S$ is 

1031: the signing algorithm, and $V$ is the verification algorithm. We assume 

1032: that the scheme $(G,S,V)$ is existentially unforgeable under adaptive 

1033: chosen message attack, in the \ROM.

1034: We do not need to rely on any computational 

1035: assumptions here, since one-way functions are sufficient for

1036: constructing secure signature schemes~\cite{ny89,ro90}, and the random

1037: oracle can be used to implement one-way functions without any

1038: assumptions.%

1039: \footnote{\ Alternatively, we could use an `ordinary' signature scheme, 

1040: but then our Theorem~\ref{sign.thm} would be conditioned on the existence 

1041: of one-way functions.} 

1042: 

1043: \paragraph{Conventions.}

1044: In the three steps below we assume, without loss of generality, that 

1045: the security parameter (i.e., $k$) is implicit in the keys generated 

1046: by $G(1^k)$. Also, let us fix some length function $\rlen : \intfnc$, 

1047: which would be implicit in the discussions below (i.e., we assume that 

1048: the random oracles are all $\rlen$-oracles, the relations are evasive 

1049: w.r.t.~$\rlen$, etc.). 

1050: 

1051: 

1052: \subsection{First Step}\label{step1.sec}

1053: %---------------------------------------

1054: \paragraph{Definition.} 

1055: {\em Let ${\cal S} = (G,S,V)$ be a signature scheme 

1056: (which may or may not use a random oracle), and let $R$ be any binary 

1057: relation, which is evasive w.r.t.~length function $\rlen$. 

1058: Then, by ${\cal S}_R = (G,S_R,V_R)$ we denote the following modification 

1059: of ${\cal S}$ which utilizes a random $\rlen$-oracle:} 

1060: \begin{description}

1061: \item[{\rm Modified signature, $S_R^\f(\sk,\msg)$,}]  

1062: {\em of message $\msg$ using signing key $\sk$:

1063: 

1064:  1. If $(\msg,\f(\msg))\!\in\!R$, output $(\sk,\msg)$. 

1065: 

1066:  2. Otherwise (i.e., $(\msg,\f(\msg))\!\not\in\!R$),

1067:     output $S^{\f}(\sk,\msg)$.}

1068: 

1069: \item[{\rm Modified verification, $V_R^\f(\vk,\msg,\sigma)$,}]   

1070: {\em of alleged signature $\sigma$ to $\msg$ using verification key $\vk$:

1071: 

1072:  1. If $(\msg,\f(\msg))\!\in\!R$ then {\tt accept}

1073: 

1074:  2. Otherwise output $V{^\f}(\vk,\msg,\sigma)$.} 

1075: \end{description}

1076: The key-generation algorithm, $G$, is the same as in the 

1077: original scheme ${\cal S}$.  Item~1 in the signing/verification 

1078: algorithms is a harmful modification to the original signature scheme. 

1079: Yet, if $R$ is evasive, then it has little effect on the ideal system, 

1080: and the behavior of the modified scheme is ``indistinguishable'' from 

1081: the original one. In particular, 

1082: 

1083: \BP\label{signROM} 

1084: Suppose that $R$ is evasive {\em(w.r.t.~$\rlen$)} and that ${\cal S}$ 

1085: is existentially unforgeable under a chosen message attack in the \ROM. 

1086: Then ${\cal S}_R$ is also existentially unforgeable under a chosen message 

1087: attack in the \ROM. 

1088: \EP 

1089: 

1090: \begin{proof}

1091: The intuition is that since $R$ is evasive, it is infeasible for the 

1092: forger to find a message $m$ so that $(m,\f(m))\in R$. Thus, a forgery 

1093: of the modified scheme must be due to Item~(2), which yields a breaking 

1094: of the original scheme. 

1095: 

1096: Formally, let $A_R$ be an adversary who mounts an adaptive chosen 

1097: message attack on ${\cal S}_R$, and whose success probability in 

1098: obtaining an existential forgery (in the \ROM) is $\epsilon_{\rm frg} 

1099: = \epsilon_{\rm frg}(k)$. Assume, toward contradiction, that 

1100: $\epsilon_{\rm frg}$ is not negligible in the security parameter $k$.

1101: 

1102: Denote by REL the event in which during an execution of $A_R$, it 

1103: hands out a message $m$ for which $(m,\f(m))\!\in\!R$ (either as a query 

1104: to the signer during the chosen message attack, or as the message for 

1105: which it found a forgery at the end), and let $\epsilon_{\rm rel} = 

1106: \epsilon_{\rm rel}(k)$ be the probability of that event. 

1107: Using the hypothesis that $R$ is evasive, 

1108: we prove that $\epsilon_{\rm rel}$ is negligible 

1109: in the security parameter $k$. 

1110: Suppose, to the contrary, that $\epsilon_{\rm rel}$ is not negligible.

1111: Then, we can try to efficiently find pairs $(x,\f(x))\in R$ by 

1112: choosing a key-pair for $\cal S$, and then implementing the attack, 

1113: playing the role of both the signer algorithm and the adversary $A_R$. 

1114: With probability $\epsilon_{\rm rel}$, one of $A_R$'s messages during 

1115: this attack satisfies $(m,\f(m))\!\in\!R$, so just choosing at random 

1116: one message that was used and outputting it yields a success probability 

1117: of $\epsilon_{\rm rel}/q$ (with $q$ being the number of different 

1118: messages that are used in the attack). If $\epsilon_{\rm rel}$ is not 

1119: negligible, then neither is $\epsilon_{\rm rel}/q$, contradicting 

1120: the evasiveness of $R$. 

1121: 

1122: It is clear that barring the event REL, the execution of $A_R$ 

1123: against the original scheme ${\cal S}$ would be identical to its 

1124: execution against ${\cal S}_R$. 

1125: Hence the probability that $A_R$ succeeds in obtaining an existential 

1126: forgery against ${\cal S}$ is at least $\epsilon_{\rm frg} - 

1127: \epsilon_{\rm rel}$. Since $\epsilon_{\rm rel}$ is negligible, 

1128: and $\epsilon_{\rm frg}$ is not, then $A_R$'s probability of obtaining 

1129: an existential forgery against ${\cal S}$ is also not negligible, 

1130: contradicting the assumed security of ${\cal S}$. 

1131: \end{proof}

1132: 

1133: \bigskip\ni

1134: The modification enables to break the modified scheme when implemented 

1135: with a real ensemble $\cal F$, in the case where $R$ is the relation 

1136: $R^{\cal F}$ from Proposition~\ref{no-impl1}.  Indeed, as corollary 

1137: to Propositions~\ref{no-impl1} and~\ref{signROM}, we immediately obtain:

1138: 

1139: \BCR\label{weak.cor} 

1140: For every efficiently computable $\rlen$-ensemble ${\cal F}$, 

1141: there exists 

1142: a signature scheme that 

1143: is existentially unforgeable under a chosen message attack 

1144: in the \ROM,

1145: yet when 

1146: implemented with $\cal F$, the resulting scheme is totally breakable 

1147: under an adaptive chosen message attack, and existentially forgeable 

1148: under a key-only attack. 

1149: \ECR

1150: 

1151: \begin{proof}

1152: When we use an ensemble ${\cal F}$ to implement the random 

1153: oracle in the scheme ${\cal S}_R$, we obtain the following real scheme 

1154: (which we denote ${\cal S}'_R = (G', S'_R, V'_R)$): 

1155: \begin{description}

1156: \item[$G'(1^k)$: ] Uniformly pick $s \in \bitset^k$, set $(\sk$,

1157:  $\vk)$ $\gets G^{f_s}(1^k)$, and output $(\vect{\sk,s},\vect{\vk,s})$. 

1158: 

1159: \item[$S'_R(\vect{\sk,s},\msg)$:] 

1160: Output $S_R^{f_s}(\sk,\msg)$. 

1161: 

1162: \item[$V'_R(\vect{\vk,s},\msg,\sigma)$:] 

1163: Output $V_R^{f_s}(\vk,\msg,\sigma)$. 

1164: \end{description}

1165: Consider now what happens when we use the ensemble ${\cal F}$ to 

1166: implement the the scheme ${\cal S}_{R^{\cal F}}$ (recall the definition 

1167: of $R^{\cal F}$ from \eqref{eq-rf}). Since $R^{\cal F}$ is evasive, then 

1168: {from} Proposition~\ref{signROM} we infer that the ${\cal S}_{R^{\cal F}}$ 

1169: is secure in the \ROM. 

1170: However, when we use the ensemble ${\cal F}$ to implement the scheme, 

1171: the seed $s$ becomes part of the public verification-key, and hence is known 

1172: to the adversary. The adversary can simply output the pair $(s,\epsilon)$, 

1173: which will be accepted by $V'_{R^{\cal F}}$ as a valid message-signature 

1174: pair (since $(s, f_s(s)) \in R^{\cal F}$). Hence, the adversary achieves 

1175: existential forgery (of ${\cal S}'_{R^{\cal F}}$) under key-only attack. 

1176: Alternatively, the adversary can ask the legitimate signer for a signature 

1177: on $s$, hence obtaining the secret signing-key (i.e., total forgery). 

1178: \end{proof}

1179: 

1180: 

1181: \subsection{Second Step}\label{step2.sec}

1182: %------------------------

1183: \paragraph{Enumeration.}

1184: For this (and the next) subsection we need an enumeration of all 

1185: efficiently computable function ensembles. Such enumeration is achieved 

1186: via an enumeration of all polynomial-time algorithms (i.e., candidates 

1187: for evaluation algorithms of such ensembles). 

1188: Several standard technicalities arise. 

1189: First, enumerating all polynomial-time algorithms is problematic since 

1190: there is no single polynomial that bounds the running time of all these 

1191: algorithms. Instead, we fix an arbitrary super-polynomial proper complexity 

1192: function\footnotemark, $t:\N\!\to\!\N$ (e.g., $t(n) = n^{\log n}$), 

1193: and enumerate all algorithms of running-time bounded by $t$. The latter 

1194: is done by enumerating all possible algorithms, and modifying each 

1195: algorithm by adding a time-out mechanism that terminates the execution 

1196: in case more than $t(|{\rm input}|)$ steps are taken. This modification 

1197: does not effect the polynomial-time algorithms. 

1198: \footnotetext{\ Recall that $t(n)$ is a {\em proper complexity function} 

1199: (or time-constructible) if there exists a machine that computes $t(n)$ 

1200: and works in time $O(t(n))$. This technical requirement is needed to 

1201: ensure that the enumeration itself is computable in time $O(t(n))$.}

1202: %

1203: Also, since we are interested in enumerating $\rlen$-ensembles, we 

1204: modify each function by viewing its seed as a pair $\vect{s,x}$ 

1205: (using some standard parsing rule\footnotemark) and padding or truncating 

1206: its output to length $\rlen(|s|)$. Again, this modification has no 

1207: effect on the $\rlen$-ensembles.

1208: \footnotetext{\ For example, using a prefix-free code $C$, we can encode

1209: a pair $(s,x)$ by $C(s)$ concatenated with $x$.}

1210: 

1211: Let us denote by ${\cal F}^i$ the $i^\th$ function ensemble according to 

1212: the above enumeration, and denote by $f^i_s$ the function indexed by $s$ 

1213: {from} the ensemble ${\cal F}^i$. Below we again use some standard 

1214: rule for parsing a string $\alpha$ as a pair $\vect{i,s}$ and viewing 

1215: it as a description of the function $f^i_s$. 

1216: 

1217: 

1218: \paragraph{Universal ensemble.} 

1219: Let ${\cal U}=\{U_k\}_{k\in{\bf N}}$ 

1220: denote the ``universal function ensemble'' that is induced 

1221: by the enumeration above, namely

1222: $U_k=\{u_{\vect{i,s}}\}_{\vect{i,s}\in\bitset^k}$ and 

1223: $u_{\vect{i,s}}(x) = f^i_s(x)$.

1224: There exists a machine that computes the universal 

1225: ensemble $\cal U$ and works in slightly super-polynomial time, $t$. 

1226: 

1227: 

1228: \paragraph{Universal relation.}  

1229: Denote by $R^{\cal U}$ the universal relation that is defined with 

1230: respect to the universal ensemble $\cal U$ similarly to the way that 

1231: $R^{\cal F}$ is defined with respect to any ensemble $\cal F$.

1232: That is: 

1233: \[

1234: \label{eq-rf2}

1235: R^{\cal U} \eqdef \bigcup_k \left\{\left(\vect{i,s},

1236: f^i_s(\vect{i,s})\right) : \vect{i,s}\in\bitset^k\right\}

1237: \]

1238: Or, in other words:

1239: \[ (x,y) \in R^{\cal U} \ \ \Longleftrightarrow

1240:              \begin{array}{l}

1241:              y =u_x(x) \\

1242:              \mbox{\rm (i.e., $x = \vect{i,s}$ and $y = f^i_s(x)$)}

1243:              \end{array}

1244: \]

1245: 

1246: 

1247: \paragraph{Modified signature scheme.} 

1248: Let ${\cal S} = (G,S,V)$ be a signature scheme (as above). We then 

1249: denote by ${\cal S}_u = (G,S_u,V_u)$ the modified signature scheme 

1250: that is derived by using $R^{\cal U}$ in place of $R$ in the previous

1251: construction. Specifically: 

1252: \begin{description}

1253: \item[$S_u^\f(\sk,\msg)$] $\eqdef$

1254: 

1255: 1. If $(\msg, \f(msg)) \in R^{\cal U}$ (i.e., if $\msg=\vect{i,s}$ 

1256:  and $\f(\msg)= f^i_s(\msg)$) then output $(\sk,\msg)$. 

1257: 

1258: 2. Otherwise, output $S^\f(\sk,\msg)$

1259: 

1260: \item[$V_u^\f(\vk,\msg,\sigma)$] $\eqdef$ 

1261: 

1262: 1. If $(\msg, \f(msg)) \in R^{\cal U}$ then {\tt accept}.

1263: 

1264: 2. Otherwise, output $V^\f(\vk,\msg,\sigma)$.

1265: \end{description}

1266: We note that since these signature and verification algorithms need 

1267: to compute $\cal U$, they both run in time $O(t)$, which is slightly 

1268: super-polynomial. 

1269: 

1270: \BP \label{super-poly.prop}

1271: Suppose that ${\cal S}$ is existentially unforgeable under a chosen 

1272: message attack in the \ROM. Then ${\cal S}_u$ is also existentially 

1273: unforgeable under a chosen message attack in the \ROM, but implementing 

1274: it with {\em any function ensemble} yields a scheme 

1275: that is totally breakable under chosen message attack 

1276: and existentially forgeable under key-only attack.

1277: \EP

1278: 

1279: \begin{proof}

1280: Since $R^{\cal U}$ is evasive, then from \prpref{signROM} it follows 

1281: that ${\cal S}_u$ is secure in the \ROM. On the other hand, suppose 

1282: that one tries to replace the random oracle in the scheme by an ensemble 

1283: ${\cal F}^i$ (where $i$ be the index in the enumeration). An adversary, 

1284: given a seed $s$ of a function in ${\cal F}^i$ can then set 

1285: $\msg=\vect{i,s}$ 

1286: and output the pair $(\msg,\epsilon)$, which would be accepted as a valid 

1287: message-signature pair by $V_u$. Alternatively, it can ask the signer for 

1288: a signature on this message $\msg$, and so obtain the secret signing-key. 

1289: \end{proof}

1290: 

1291: 

1292: \subsection{Third step}\label{step3.sec}

1293: %----------------------

1294: We now use CS-proofs to construct a new signature scheme that works in the 

1295: \ROM. This construction is similar to the one in Subsection~\ref{step2.sec}, 

1296: except that instead of checking that $(\msg,\f(\msg))\in R^{\cal U}$, 

1297: the signer/verifier gets a CS-proof of that claim, and it only needs 

1298: to verify the validity of that proof. Since verifying the validity of a 

1299: CS-proof can be done much more efficiently than checking the claim ``from 

1300: scratch'', the signing and verifications algorithms in the new scheme 

1301: may work in polynomial time. On the other hand, when the scheme

1302: is implemented using the function ensemble ${\cal F}^i$,

1303: supplying the adequate CS-proof 

1304: (i.e., for $(\msg,f_s^i(\msg))\in R^{\cal U}$)

1305: only requires polynomial-time

1306: (i.e., time polynomial in the time it takes to evaluate $f_s^i$).

1307: This yields the following: 

1308: 

1309: \BT\label{sign.thm}

1310: There exists a signature scheme that is existentially unforgeable under 

1311: a chosen message attack in the \ROM, but such that when implemented with 

1312: any function ensemble, the resulting scheme is existentially forgeable 

1313: using key-only attack and totally breakable under chosen message attack. 

1314: \ET

1315: We note again that unlike the ``signature scheme'' presented in 

1316: Subsection~\ref{step2.sec}, the signature scheme presented below works 

1317: in polynomial-time. 

1318: \medskip 

1319: 

1320: \begin{proof}

1321: Below we describe such a signature scheme. 

1322: For this construction we use the following ingredients.

1323: \BI

1324: \item ${\cal S} = (G,S,V)$ is a signature scheme, operating in the 

1325: \ROM, that is existentially unforgeable under a chosen message attack.  

1326: 

1327: \item 

1328: A fixed (and easily computable) parsing rule which interpret messages 

1329: as triples of strings $\msg = \vect{i,s,\pi}$.

1330: 

1331: \item 

1332: The algorithms $\prv$ and $\ver$ of a CS-proof system, as described 

1333: in \secref{sec:csproofs} above. 

1334: 

1335: \item

1336: Access to three independent random oracles. 

1337: This is very easy to achieve given access to one oracle $\f$;

1338: specifically, by setting $\f'(x) \eqdef \f(01x)$, $\f''(x) \eqdef \f(10x)$

1339: and $\f'''(x) \eqdef \f(11x)$. 

1340: 

1341: Below we use oracle $\f'''$ for the basic scheme $\cal S$, oracle 

1342: $\f''$ for the CS-proofs, and oracle $\f'$ for our evasive relation. 

1343: We note that if $\f$ is an $\rlen$-oracle, then so are $\f', \f''$ 

1344: and $\f'''$. 

1345: 

1346: \item 

1347: The universal function ensemble 

1348: ${\cal U}$ from Subsection~\ref{step2.sec}, 

1349: with proper complexity bound $t(n) = n^{\log n}$. 

1350: We denote by $M_{\cal U}$ the universal machine that decides 

1351: the relation $R^{\cal U}$.  

1352: That is, on input $(\vect{i,s},y)$,

1353: machine $M_{\cal U}$ invokes the $i^\th$ evaluation algorithm,

1354: and accepts if $f^i_s(\vect{i,s}) = y$.

1355: 

1356: We note that $M_{\cal U}$ works in time $t$ in the worst case. 

1357: More importantly, if ${\cal F}^i$ is a function ensemble that can be 

1358: computed in time $p_i(\cdot)$ (where $p_i$ is some polynomial), then 

1359: for any strings $s,y$, on input $(\vect{i,s},y)$, 

1360: machine $M_{\cal U}$ works 

1361: for only $\poly(|i|) \cdot p_i(|s|)$ many steps.%

1362: \footnote{\ The point is merely that, for every fixed $i$, the 

1363: expression $\poly(|i|) \cdot p_i(|s|)$ is bounded by a polynomial 

1364: in $|s|$.} 

1365: \EI

1366: Using all the above, we describe an ideal signature scheme ${\cal S}'_u = 

1367: (G,S'_u,V'_u)$.  As usual, the key generation algorithm, $G$, remains 

1368: unchanged. The signature and verification algorithms proceed as follows. 

1369: 

1370: \begin{description}

1371: \item[${S'_u}^\f(\sk,\msg)$] $\eqdef$  

1372: \BE

1373: \item

1374: Parse $\msg$ as $\vect{i,s,\pi}$, and set $x=\vect{i,s}$ and 

1375: $y=\f'(x)$. Let $n=|(x,y)|$. 

1376: \item

1377: Apply $\ver^{\f''}$ to verify whether $\pi$ is a valid CS-proof,

1378: with respect to the oracle $\f''$ and security parameter $1^{n+k}$, 

1379: for the claim that the machine $M_{\cal U}$ accepts the input $(x,y)$ 

1380: within time $t(n)$. 

1381: 

1382: (The punch-line is that we do not directly check whether the

1383: machine $M_{\cal U}$ accepts the input $(x,y)$ within time $t(n)$, 

1384: but rather only if $\pi$ is a valid CS-proof of this claim.

1385: Although $t(n)=n^{\log n}$, this CS-proof can be verified in

1386: polynomial-time.) 

1387: \item

1388: If $\pi$ is a valid proof, then output $(\sk,\msg)$. 

1389: \item

1390: Otherwise, output $S^{\f'''}(\sk,\msg)$.

1391: \EE

1392: 

1393: \item[${V'_u}^\f(\vk,\msg,\sigma)$] $\eqdef$  

1394: 

1395: {~~~}1+2. As above

1396: 

1397: {~~~}3. If $\pi$ is a valid proof, then {\tt accept}

1398:  

1399: {~~~}4. Otherwise, output $V^{\f'''}(\vk,\msg,\sigma)$.

1400: \end{description}

1401: The computation required in Item~2 of the signature 

1402: and verification algorithms can be executed in polynomial-time. The 

1403: reason being that (by definition) verifying a CS-proof can be done in 

1404: polynomial-time, provided the statement can be decided in at most 

1405: exponential time (which is the case here since we have $t(n) = 

1406: O(n^{\log n})$). 

1407: It is also easy to see that for every pair $(\sk,\vk)$ output by $G$, 

1408: and for every $\msg$ and every $\f$, the string ${S'_u}^\f(\sk,\msg)$ 

1409: constitutes a valid signature of $\msg$ relative to $\vk$ and the 

1410: oracle $\f$. 

1411: 

1412: To show that the scheme is secure in the \ROM, we first observe that 

1413: on security parameter $1^k$ it is infeasible to find a string $x$ so 

1414: that $(x,\f'(x)) \in R^{\cal U}$, since $R^{\cal U}$ is evasive.

1415: By \prpref{prp-cs-prf}, it is also infeasible to find $(x,\pi)$ 

1416: such that $(x,\f'(x))\not\in R_{\cal U}$ and yet $\pi$ is a valid 

1417: CS-proof of the contrary relative to $\f''$ (with security parameter 

1418: $1^{|x|+\rlen(k)+k}$). 

1419: Thus, it is infeasible for a polynomial-time adversary to find a message 

1420: that would pass the test on Item~2 of the signature/verification algorithms 

1421: above, and so we infer that the modified signature is secure in the \ROM. 

1422: 

1423: We now show that for every candidate implementation, ${\cal F}$, there 

1424: exists a polynomial-time adversary effecting total break via a chosen 

1425: message attack (or, analogously, an existential forgery via a ``key 

1426: only'' attack). 

1427: First, for each function $f_s \in {\cal F}$,

1428: denote $f'_s(x) \eqdef f_s(01x)$, $f''_s(x) \eqdef f_s(10x)$, 

1429: and $f'''_s(x) \eqdef f_s(11x)$. 

1430: Then denote by ${\cal F}'$ the ensemble of the $f'_s$ functions. 

1431: 

1432: Suppose that ${\cal F}'$ is the $i^\th$ function ensemble in the 

1433: enumeration mentioned above, namely ${\cal F}' = {\cal F}^i$. Given 

1434: a randomly chosen $k$-bit seed $s$, the adversary generate a message 

1435: $\msg=\vect{i,s,\pi}$ so that $\pi$ is a CS-proof (w.r.t the adequate 

1436: security parameter) for the {\em true}\/ statement that $M_{\cal U}$ 

1437: accepts the input $(x,y)$ within $t(|x|+|y|)$ steps, where $x = \vect{i,s}$ 

1438: and $y = f'_s(x)$. Recall that the above statement is indeed true 

1439: (since $f'_s\equiv f^i_s$),

1440: and hence the adversary can generate a proof for it in time which is 

1441: polynomial in the time that it takes to compute $f^i_s$. 

1442: (By the perfect completeness property 

1443: of the CS-proof system, the ability to prove 

1444: correct statements holds for {\em any} choice of the random oracle, 

1445: and in particular when it is equal to $f''_s$.) % See \AppendixCS.) 

1446: Since this adversary is specifically designed to break 

1447: the scheme in which the random oracle is implemented by ${\cal F}$, 

1448: then the index $i$~-- 

1449: which depends only on the choice of ${\cal F}$~-- 

1450: can be incorporated into the program of this adversary. 

1451: 

1452: By the efficiency condition of CS-proofs, it is possible to find $\pi$ 

1453: (given an oracle access to $f''_s$) in time polynomial in the time 

1454: that it takes $M_{\cal U}$ to accept the input $(x,y)$. Since ${\cal F}^i$ 

1455: is polynomial-time computable, then $M_{\cal U}$ works on the input $(x,y) 

1456: = (\vect{i,s},y)$ in polynomial time, and thus the described adversary 

1457: also operates in polynomial-time. 

1458: 

1459: By construction of the modified verification algorithm, $\epsilon$ is 

1460: a valid signature on $\msg=\vect{i,s,\pi}$, and so existential forgery 

1461: is feasible a-priori. Furthermore, requesting the signer to sign 

1462: the message $\msg$ yields the signing key, and thus total forgery. 

1463: \end{proof}

1464: 

1465: 

1466: \BRK \label{rmk-csproofs-exist}

1467: It is immaterial for the above argument whether CS-proofs 

1468: can be implemented in the ``real world'' (i.e., without access to random 

1469: oracles).  Specifically, it doesn't matter if one can cheat when the 

1470: oracle is substituted by a candidate function ensemble, as in this case 

1471: (i.e., in the real world implementation) it is sufficient for the adversary 

1472: to invoke the proof system on valid statements. 

1473: We do rely, however, on the perfect completeness of CS-proofs that 

1474: implies that valid statements can be proven for any possible choice of 

1475: oracle used in the proof system. 

1476: \ERK

1477: 

1478: \subsection{Encryption}

1479: %----------------------

1480: The construction presented for signature schemes can be adapted to 

1481: public-key 

1482: encryption schemes in a straightforward 

1483: way, yielding the following theorem:% 

1484: \footnote{\ 

1485: Similarly, we can adapt the argument to

1486: shared-key (aka private-key) encryption schemes.

1487: See Remark~\ref{rmk-similar-schemes}.}

1488: 

1489: \BT\label{encrypt.thm} 

1490: {~} 

1491: \begin{description}

1492: \item[(a)] Assume that there exists a  public key encryption scheme that is 

1493: semantically secure in the \ROM. Then there exists a public key 

1494: encryption scheme that is semantically secure in the \ROM\ but is not 

1495: semantically secure

1496: when implemented with any function ensemble.% 

1497: \footnote{Here we refer to semantic security

1498: as defined by Goldwasser and Micali in~\cite{GoMi84}, and not to

1499: the seemingly weaker definition presented in~\cite{G93,G99}.

1500: Goldwasser and Micali allow the message space to depend on the

1501: public-key, whereas this is not allowed in~\cite{G93,G99}.} 

1502: 

1503: \item[(b)] Assume that there exists a public key encryption scheme that is 

1504: secure under adaptive chosen ciphertext attack in the \ROM. Then there 

1505: exists a scheme that is secure under adaptive chosen ciphertext attack 

1506: in the \ROM, but implementing it with any function ensemble yields a 

1507: scheme that is not semantically secure, and in which a chosen ciphertext 

1508: attack reveals the secret decryption key. 

1509: \end{description}

1510: \ET

1511: \begin{proof}

1512: In this proof we use the same notations as in the proof of \thmref{sign.thm}.

1513: Let ${\cal E} = (G,E,D)$ be an encryption scheme that is semantically 

1514: secure in the \ROM, and we modify it to get another scheme ${\cal E}' = 

1515: (G,E',D')$. The key generation algorithm remains unchanged, and the 

1516: encryption and decryption algorithms utilize a random oracle $\f$,

1517: which is again viewed as three oracles $\f',\f''$ and $\f'''$. 

1518: \begin{description}

1519: \item[Modified encryption, ${E'_\ek}^\f(\msg)$,] of plaintext $\msg$

1520: using the public encryption-key $\ek$:

1521: \BE

1522: \item Parse $\msg$ as $\vect{i,s,\pi}$, set $x = \vect{i,s}$ and 

1523: $y = \f'(x)$, and let $n=|(x,y)|$.  

1524: 

1525: \item If $\pi$ is a valid CS-proof, w.r.t oracle $\f''$ and security 

1526: parameter $1^{n+k}$, for the assertion that $M_{\cal U}$ accepts the 

1527: pair $(x,y)$ within $t(n)$ steps, then output $(1,\msg)$. 

1528: 

1529: \item Otherwise (i.e., $\pi$ is not such a proof), output 

1530: $(2,E_\ek^{\f'''}(\msg))$. 

1531: \EE 

1532: 

1533: \item[Modified decryption, ${D'_\dk}^\f(c)$,] of ciphertext $c$

1534: using the private decryption-key $\dk$:

1535: 

1536: \BE 

1537: \item If $c = (1,c')$, output $c'$ and halt.

1538: 

1539: \item If $c = (2,c')$, output $D_{\dk}^{\f'''}(c')$ and halt.

1540: 

1541: \item If $c = (3,c')$ then parse $c'$ as $\vect{i,s,\pi}$, and set 

1542: $x = \vect{i,s}$, $y = \f'(x)$, and $n=|(x,y)|$. 

1543: If $\pi$ is a valid CS-proof, w.r.t oracle $\f''$ and security parameter 

1544: $1^{n+k}$, for the assertion that $M_{\cal U}$ accepts the pair $(x,y)$ 

1545: within $t(n)$ steps, then output $\dk$ and halt. 

1546: 

1547: \item Otherwise output $\epsilon$.

1548: \EE 

1549: \end{description}

1550: The efficiency of this scheme follows as before. It is also easy to 

1551: see that for every pair $(\ek,\dk)$ output by $G$, 

1552: and for every plaintext $\msg$, 

1553: the equality ${D'_\dk}^\f({E'_\ek}^\f(\msg))=\msg$ holds for every $\f$. 

1554: To show that the scheme is secure in the \ROM, we observe again that it 

1555: is infeasible to find a plaintext that satisfies the condition in Item~2 

1556: of the encryption algorithm (resp., a ciphertext that satisfies the 

1557: condition in Item~3 of the decryption algorithm). Thus, the modified 

1558: ideal encryption scheme (in the \ROM) inherits all security features 

1559: of the original scheme. 

1560: 

1561: Similarly, to show that replacing the random oracle by any function 

1562: ensemble yields an insecure scheme, we again observe that for any 

1563: such ensemble there exists an adversary who -- given the seed $s$ -- 

1564: can generate a plaintext $\msg$ (resp., a ciphertext $c$) 

1565: that satisfies the condition in Item~2 of the encryption algorithm 

1566: (resp., the condition in Item~3 of the decryption algorithm). 

1567: Hence, such an adversary can identify when $\msg$ is 

1568: being encrypted (thus violates semantic security), or ask for a 

1569: decryption of $c$, thus obtaining the secret decryption key. 

1570: \end{proof}

1571: 

1572: 

1573: \BRK \label{rmk-enc-exist}

1574: As opposed to \thmref{sign.thm}, here we need 

1575: to make computational assumptions, namely, that there exist schemes that 

1576: are secure in the \ROM. 

1577: (The result in~\cite{ImRu89} imply that it is unlikely that

1578: such schemes are proven to exists without making any assumptions.)

1579: Clearly, any scheme which is secure without random oracles is also secure 

1580: in the \ROM. Recall that the former exist, provided trapdoor permutations 

1581: exist~\cite{GoMi84,yao82a}. 

1582: \ERK

1583: 

1584: \BRK \label{rmk-similar-schemes}

1585: The constructions presented above can be adapted to yield

1586: many analogous results.  For example, a result analogous to 

1587: Theorem~\ref{encrypt.thm} holds for shared-key (aka private-key) 

1588: encryption schemes.  In this case no computational assumptions 

1589: are needed since secure shared-key encryption is known to exist 

1590: in the \ROM.

1591: Similarly, we can prove the existence of a CS-proof in the \ROM\/

1592: that has no implementations (via any function ensemble). 

1593: In fact,  as remarked in the Introduction,

1594: the same technique can be applied to practically any cryptographic

1595: application. 

1596: \ERK

1597: 

1598: 

1599: %----------------------------------------------

1600: \section{Restricted correlation intractability}\label{sec-lengths}

1601: %----------------------------------------------

1602: Faced with the negative result of \thmref{no-impl1}, one may explore 

1603: restricted (and yet possibly useful) versions of the \corInty\ property.

1604: One possibility is to put more stringent constraints on the use of 

1605: the ensemble in a cryptographic scheme, and then to show that as long 

1606: as the ensemble is only used in this restricted manner, 

1607: it is guaranteed to maintain some aspects of \corInty. 

1608: 

1609: In particular, notice that the proof of \thmref{no-impl1} relies heavily 

1610: on the fact that the input to $f_s$ can be as long as the seed $s$, so 

1611: we can let the input to the function $f_s$ be equal to $s$. 

1612: Thus, one option 

1613: would be to require that we only use $f_s$ on inputs that are shorter 

1614: than $s$. 

1615: Specifically, we require that each function $f_s$ will only be applied 

1616: to inputs of length $\dlen(|s|)$, where $\dlen:\intfnc$ is some 

1617: pre-specified function (e.g. $\dlen(k)=k/2$). The corresponding restricted 

1618: notion of \corInty\ is derived from 

1619: \defref{def-unpredict}: 

1620: 

1621: \BD[restricted \corInty]

1622: \label{def-restrict-unpredict}

1623: Let $\dlen,\rlen: \intfnc$ be length functions. A machine $M$ is called

1624: $\dlen$-respecting if $|M(s)| = \dlen(|s|)$ for all $s\in\bitset^*$.

1625: \BI 

1626: \item 

1627: A binary relation $R$ is evasive with respect to $(\dlen,\rlen)$ if for

1628: any $\dlen$-respecting probabilistic polynomial-time oracle machine $M$

1629: $$\Pr_\f[x\gets M^\f(1^k),\;\, (x,\f(x))\!\in\!R]\;\;=\;\;\negl(k)$$

1630: where $\f:\bitset^{\dlen(k)}\to\bitset^{\rlen(k)}$ is a uniformly

1631: chosen function and $\negl(\cdot)$ is a negligible function.

1632: \item 

1633: We say that an $\rlen$-ensemble ${\cal F}$ is {\sf $(\dlen,

1634: \rlen)$-restricted \corInt} {\em(}or just {\em $\dlen$-\corInt},

1635: for short{\em)}, if for every $\dlen$-respecting

1636: probabilistic polynomial-time machine $M$ 

1637: and every evasive relation $R$ w.r.t. $(\dlen,\rlen)$, 

1638: it holds that

1639: \[\Pr_{s \in \bitset^k}[ x \gets M(s),\;\; (x,f_s(x)) \in R ] = \negl(k)\]

1640: \EI 

1641: {\em Weak $\dlen$-\corInty}\/ is defined analogously by considering

1642: only polynomial-time recognizable $R$'s.

1643: \ED

1644: 

1645: The rest of this section is dedicated to demonstrating impossibility

1646: results for restricted correlation intractable 

1647: ensembles, in some cases.  We also highlight cases where

1648: existence of restricted correlation intractable               

1649: ensembles is left as an open problem.

1650: 

1651: \subsection{Negative results for short seeds} 

1652: The proof ideas of \thmref{no-impl1} can be easily applied to rule out 

1653: the existence of certain restricted correlation intractable ensembles

1654: where the seed is too short. 

1655: 

1656: \BP{~}\label{no-impl2} 

1657: \begin{description}

1658: \item[{(a)}] 

1659: If $\dlen(k) \geq k - O(\log k)$ for infinitely many $k$'s, then there 

1660: exists no ensemble that is $(\dlen,\rlen)$-\corInt, even in the weak sense. 

1661: \item[{(b)}] 

1662: If $\dlen(k)+\rlen(k) \geq k + \omega(\log k)$, there 

1663: exists no ensemble that is $(\dlen,\rlen)$-\corInt. 

1664: \end{description}

1665: \EP

1666: \begin{proof}

1667: The proof of (a) is a straightforward generalization of the proof of 

1668: \thmref{no-impl1}. Actually, we need to consider two cases: the case 

1669: $\dlen(k)\geq k$ and the case $k-O(\log k)\leq\dlen(k)<k$. In the first 

1670: case, we proceed as in the proof of \thmref{no-impl1} 

1671: (except that we define 

1672: $R^{\cal F}\eqdef\{(x,f_s(x)): s \in \bitset^*,x=s0^{\dlen(|s|)-|s|}\}$). 

1673: In the second case, for every ensemble ${\cal F}$, we define the relation 

1674: \[R^{\cal F} \eqdef 

1675:    \left\{(x,f_{xz}(x)) : x,z \in \bitset^*\,,\, |x|=\dlen(|xz|) \right\}

1676: \]

1677: We show that $R^{\cal F}$ is evasive by showing that, 

1678: for every $k\in\N$ and $x\in\bitset^{\dlen(k)}$,  

1679: there exist at most polynomially (in $k$) many $y$'s 

1680: such that $(x,y) \in R^{\cal F}$.

1681: This is the case since $(x,y)\in R^{\cal F}$ implies that there 

1682: exists some $z$ such that $\dlen(|xz|)=|x|$ and $y=f_{xz}(x)$.

1683: But using the case hypothesis we have 

1684: $|x| = \dlen(|xz|) \geq |xz| - O(\log|xz|)$, which implies that 

1685: $|z| = O(\log(|xz|))$ and hence also $|z|=O(\log|x|)$. 

1686: Next, using the other case hypothesis (i.e., $k>\dlen(k)=|x|$), 

1687: we conclude that $|z| = O(\log k)$. 

1688: Therefore, there could be at most polynomially many such $z$'s, 

1689: and so the upper bound on the number of $y$'s paired with $x$ follows.

1690: The evasiveness of $R^{\cal F}$ as well as the assertion that $R^{\cal F}$ 

1691: is polynomial-time computable follow (assuming that the function $\dlen$ 

1692: itself is polynomial-time computable). 

1693: On the other hand, consider the machine $M$ that, on input $s$,

1694: outputs the $\dlen(|s|)$-bit prefix of $s$. 

1695: Then, for every $s\in\bitset^*$, 

1696: we have $(M(s),f_s(M(s)))\in R^{\cal F}$. 

1697: 

1698: \medskip

1699: For the proof of (b), assume that $\dlen(k) < k$ (for all but finitely 

1700: many $k$'s). We start by defining the ``inverse'' of the $\dlen$ function 

1701: \[ \dlen^{-1}(n) \eqdef {\rm min}\{ k\ :\ \dlen(k) = n \} 

1702: \]

1703: (where, in case there exists no $k$ such that $\dlen(k) = n$, 

1704: we define $\dlen^{-1}(n) = 0$). 

1705: By definition it follows that $k \geq \dlen^{-1}(\dlen(k))$, for all 

1706: $k$'s (because $k$ belongs to the set $\{ k'\ :\ \dlen(k') = \dlen(k)\}$), 

1707: and that $\dlen(\dlen^{-1}(n)) = n$,  whenever there exists some $k$ for 

1708: which $n = \dlen(k)$.  Next we define 

1709: \[{R}^{\cal F}\eqdef\left\{(x,f_{xz}(x))\,:\,x,z\in\bitset^*\,,\,

1710:                                   |x|+|z|=\dlen^{-1}(|x|)\right\}

1711: \]

1712: This relation is well defined since, by the conditions 

1713: on the lengths of $x$ and $z$,

1714: we have $\dlen(|xz|) = \dlen(\dlen^{-1}(|x|)) = |x|$ and so 

1715: the function $f_{xz}$ is indeed defined on the input $x$. 

1716: In case $\dlen(k) \leq k - \omega(\log k)$, this relation may not be 

1717: polynomial-time recognizable. Still, it is evasive w.r.t. $(\dlen,\rlen)$, 

1718: since with security parameter $k$ we have 

1719: for every $x\in\bitset^{\dlen(k)}$ 

1720: \begin{eqnarray*}

1721:   \left|\left\{y\in\bitset^{\rlen(k)}\ : (x,y) \in {R}^{\cal F}\right\}\right| 

1722:   &=&\left| \left\{ f_{xz}(x)\ : |z| = \dlen^{-1}(\dlen(k))-\dlen(k)\right\}

1723:              \ \cap\ \bitset^{\rlen(k)} \right| \\

1724:   &\leq& 2^{\dlen^{-1}(\dlen(k))-\dlen(k)} \\ 

1725:   &\leq& 2^{k-\dlen(k)} 

1726: \end{eqnarray*}

1727: Using $k-\dlen(k)\leq\rlen(k)-\omega(\log k)$,

1728: we conclude that the set of $y$'s paired with $x$ forms a negligible

1729: fraction of $\bitset^{\rlen(k)}$, and so that $R^{\cal F}$ is evasive.

1730: Again, the machine $M$, that on input $s$ outputs 

1731: the $\dlen(|s|)$-bit prefix of $s$, 

1732: satisfies $(M(s),f_s(M(s)))\in R^{\cal F}$, for all $s$'s. 

1733: \end{proof}

1734: 

1735: \paragraph{Open Problems:}

1736: %-------------------------

1737: Proposition~\ref{no-impl2} still leaves open the question of 

1738: existence of $(\dlen,\rlen)$-restricted \corInt\ ensembles,

1739: for the case $\dlen(k)+\rlen(k)<k+O(\log k)$.\footnote{\label{d-log.fn}

1740: In fact such ensembles do exist in case $k\geq2^{\dlen(k)}\cdot\rlen(k)$

1741: (since the seed may be used to directly specify all the function's values),

1742: but we dismiss this trivial and useless case.}  

1743: We believe that it is interesting to resolve the situation either way: 

1744: Either provide negative results also for the above special case, 

1745: or provide a plausible construction.

1746: Also open is the sub-case where $\dlen(k)+\rlen(k)=k+\omega(\log k)$  

1747: but one considers only {\em weak}\/ $(\dlen,\rlen)$-restricted \corInty. 

1748: (Recall that Case~(b) of Proposition~\ref{no-impl2} 

1749: is proven using relations which are not known 

1750: to be polynomial-time recognizable.) 

1751: 

1752: We comment that even if restricted \corInt\

1753: ensembles exist, then they are very non-robust constructs.

1754: For example, even if the ensemble ${\cal F} = \{f_s : |s|=k\}_k$ 

1755: is \corInt\ with respect to some length functions $(\dlen,\rlen)$, 

1756: the ensemble that is obtained by applying many independent 

1757: copies of ${\cal F}$ and concatenating the results may not be. 

1758: That is, for $m\!:\!\N\!\to\!\N$, define 

1759: \begin{equation}\label{non-robust.eq1} 

1760: {\cal F}^m \eqdef \{f'_{\langle s_1,...,s_{m(k)}\rangle}

1761:   :|s_1|=\cdots=|s_{m(k)}|=k\}_{k\in\N}\,,

1762: \end{equation}

1763: where, for $\langle x_1,...,x_{m(k)}\rangle\in\bitset^{m(k)\cdot\dlen(k)}$, 

1764: \begin{equation}\label{non-robust.eq2} 

1765: f'_{\langle s_1,...,s_{m(k)}\rangle}(\langle x_1,...,x_{m(k)}\rangle)

1766:   \eqdef \langle f_{s_1}(x_1),....,f_{s_{m(k)}}(x_{m(k)})\rangle\,.

1767: \end{equation}

1768: Then, for sufficiently large $m$ (e.g., $m(k)\geq k/\dlen(k)$ will do),

1769: the ``direct product'' ensemble ${\cal F}^m$ is not \corInt\

1770: (not even in the restricted sense).

1771: That is, 

1772: 

1773: \BP \label{no-impl3}

1774: Let $\dlen, \rlen: \intfnc$ be length functions

1775: so that $\dlen(k)\leq k$, 

1776: and let $m:\intfnc$ be a polynomially-bounded 

1777: function so that $m(k)\geq k/\dlen(k)$. Let ${\cal F}$ be an 

1778: arbitrary function ensemble, and ${\cal F}^m$ be as defined in 

1779: \eqref{non-robust.eq1} and~(\ref{non-robust.eq2}). Then, ${\cal F}^m$ 

1780: is not \corInt, not even in the $(\dlen^m,\rlen^m)$-restricted 

1781: sense, where $\ell_{\rm in}^m(m(k)\cdot k)\eqdef 

1782: m(k)\cdot\ell_{\rm in}(k)$ and $\ell_{\rm out}^m(m(k)\cdot k)\eqdef 

1783: m(k)\cdot\ell_{\rm out}(k)$.

1784: \EP

1785: 

1786: \begin{proof}

1787: We assume, for simplicity that $m(k)=k/\dlen(k)$

1788: (and so $\dlen(k)=k/m(k)$ and $\dlen^m(m(k)\cdot k)=k$). 

1789: Given ${\cal F}^m$ as stated, 

1790: we again adapt the proof of \thmref{no-impl1}. 

1791: This time, using $\dlen(k)\leq k$, we define the relation

1792: $$R^{{\cal F}^m} 

1793:    \eqdef \bigcup_k\left\{\,(s,\langle f_{s}(s'),t\rangle)\,:\; 

1794:  |s| = k,\;\; \mbox{\rm $s'$ is the $\dlen(k)$-prefix of $s$},\;\;

1795:  |t| = (m(k)-1)\cdot\rlen(k) \, \right\}$$

1796: Notice that in this definition we have $|s| = \frac{k}{\dlen(k)} 

1797: \cdot \dlen(k) = m(k) \cdot \dlen(k) = \dlen^m(m(k) \cdot k)$, and also 

1798: $|f_s(s')|+|t| = m(k) \cdot \rlen(k) = \rlen^m(m(k) \cdot k)$, so this 

1799: relation is indeed $(\dlen^m,\rlen^m)$-restricted. 

1800: 

1801: Again, it is easy to see that $R^{\cal F}$ is polynomial-time recognizable, 

1802: and it is evasive since every string $x \in \bitset^k$ is coupled with 

1803: at most a $2^{-\rlen(k)}$ fraction of the possible $(m(k)\cdot\rlen(k))$-bit 

1804: long strings, and $\rlen(k)=\omega(\log k)=\omega(\log(m(k)\cdot k))$. 

1805: (Here we use the hypothesis $m(k)=\poly(k)$.)

1806: 

1807: On the other hand, consider a (real-life) adversary that given the seed 

1808: ${\ov s}=\langle s_1,...,s_{m(k)}\rangle\in\bitset^{m(k)\cdot k}$ 

1809: for the function $f'_{\langle s_1,...,s_{m(k)}\rangle}$, 

1810: sets the input to this function to be equal to $s_1$. 

1811: Denoting the $\dlen(k)$-prefix of $s_1$ 

1812: (equiv., of $\ov s$) by $s_1'$,

1813: it follows that $f_{s_1}(s_1')$ is a prefix 

1814: of $f'_{\langle s_1,...,s_{m(k)}\rangle}(s_1)$

1815: and so $(s_1, f'_{\langle s_1,....,s_{m(k)}\rangle}(s_1)) \in R^{\cal F}$. 

1816: Thus, this real-life adversary violates the (restricted) correlation 

1817: intractability of ${\cal F}^m$. 

1818: \end{proof}

1819: 

1820: 

1821: \subsection{Correlation intractability for multiple invocations}

1822: %===========================================

1823: Recall that Proposition~\ref{no-impl2} does not rule out the existence

1824: of  restricted ensembles having seeds that are longer than the sum 

1825: of lengths of their inputs and outputs. However, even for this special 

1826: case the only thing that is not ruled out is a {\em narrow definition} 

1827: that refers to forming rare relationships between a {\em single}\/ 

1828: input-output pair.  In fact, if one generalizes the definition 

1829: of \corInty\ so as to consider evasive relations over unbounded 

1830: sequences of inputs and outputs,  then the negative result in 

1831: \prpref{no-impl2} can be extended for arbitrary $\dlen$ and 

1832: $\rlen$. That is, 

1833: 

1834: \BD[multi-invocation restricted \corInty]

1835: \label{def-gen-restrict-unpredict}

1836: Let $\dlen,\rlen: \intfnc$ be length functions. 

1837: We consider probabilistic polynomial-time oracle machines 

1838: which on input $1^k$ have oracle access to 

1839: a function $\f:\bitset^{\dlen(k)}\to\bitset^{\rlen(k)}$.

1840: \BI 

1841: \item

1842: A relation $R$ over pairs of binary sequences

1843: is {\sf evasive with respect to $(\dlen,\rlen)$}

1844: {\em(or $(\dlen,\rlen)$-evasive)}

1845: if for any 

1846: probabilistic polynomial-time machine $M$ as above it holds that 

1847: $$

1848: \Pr_\f\left[ (x_1,...,x_m) \gets M^{\f}(1^k)\,;\ \ 

1849: \begin{array}{l}

1850:   |x_1| = \ldots = |x_{m}| = \dlen(k) \\

1851:   \mbox{\rm and } ((x_1,...,x_m),(\f(x_1),...,\f(x_m))\!\in\!R

1852: \end{array}

1853: \;\right]\;\;=\;\;\negl(k)

1854: $$

1855: As usual, $\f:\bitset^{\dlen(k)}\to\bitset^{\rlen(k)}$ is a uniformly

1856: chosen function. 

1857: \item

1858: We say that an $\rlen$-ensemble ${\cal F}$ is 

1859: {\sf $(\dlen,\rlen)$-restricted multi-invocation \corInt} 

1860: {\em(}or just {\em $\dlen$-multi-invocation \corInt}, for short{\em)}, 

1861: if for every $(\dlen,\rlen)$-evasive relation $R$ and 

1862: every probabilistic polynomial-time machine $M$ it holds that

1863: $$

1864: \Pr_{s\in\{0,1\}^k}\left[ (x_1,...,x_m) \gets M(s)\,;\ \ 

1865: \begin{array}{l}

1866:   |x_1| = \ldots = |x_{m}| = \dlen(k) \\

1867:   \mbox{\rm and } ((x_1,...,x_m),(f_s(x_1),...,f_s(x_m))\!\in\!R

1868: \end{array}

1869: \;\right]\;\;=\;\;\negl(k)

1870: $$

1871: \EI 

1872: \ED

1873: 

1874: \BP \label{no-impl4}

1875: Let $\dlen,\rlen: \intfnc$ be arbitrary length functions, with 

1876: $\dlen(k) \geq 2+\log k$ and $\rlen(k) \geq 1$.  Then there exist no 

1877: $(\dlen,\rlen)$-restricted {\em multi-invocation} {\corInt} function 

1878: ensembles.

1879: \EP 

1880: 

1881: \begin{proof}

1882: For simplicity, we consider first the case $\rlen(k) \geq 2$. 

1883: Let ${\cal F}$ be an $\rlen$-ensemble.

1884: Adapting the proof of \thmref{no-impl1}, we define the relation

1885: $$

1886: R^{\cal F} \eqdef \bigcup_k \left\{ 

1887:   \left((x_1, \ldots, x_k), (f_s(x_1),\ldots,f_s(x_k))\right) :

1888: \begin{array}{l}

1889:   x_i = (i,s_i), \mbox{ with }s_i \in \{0,1\} \\

1890:   \mbox{\rm and } s=s_1\ldots s_k

1891: \end{array}

1892: \right\}

1893: $$

1894: (Notice that since $\dlen(k)>1+\log k$, the $x_i$'s are indeed in 

1895: the range of the function $f_s$.)  Clearly, this relation 

1896: is polynomial-time recognizable. 

1897: To see that this relation is evasive, notice that for any fixed 

1898: $k$-bit seed $s = s_1 \ldots s_k$, we have 

1899: $$\Pr_{\f}[\f(i,s_i)=f_s(i,s_i)\mbox{ for }i=1\ldots k] 

1900:   = 2^{-\rlen(k)\cdot k}$$ 

1901: Hence, the probability that there exists a seed $s$ 

1902: for which $\f(i,s_i)=f_s(i,s_i)$ holds, for $i=1,...,k$,

1903: is at most $2^k \cdot 2^{-\rlen(k)\cdot k} \leq 2^{-k}$.  

1904: It follows that

1905: $$\Pr_{\f}[\exists x_1,...,x_k\;

1906:            \left((x_1, \ldots, x_k), (\f(x_1),\ldots,\f(x_k))\right)

1907:            \in R^{\cal F}]\leq 2^{-k}$$ 

1908: However, the corresponding multi-invocation restricted \corInty\ condition 

1909: does not hold: 

1910: For any $s = s_1 \ldots s_k\in \bitset^k$, setting $x_i = (i,s_i)$

1911: we get $((x_1,...,x_k),(f_s(x_1),...,f_s(x_k)))\in R^{\cal F}$. 

1912: 

1913: To rule out the case $\rlen(k) = 1$, we redefine $R^{\cal F}$ so 

1914: that $((x_1,...,x_{2k}),(f_s(x_1),...,f_s(x_{2k})))\in R^{\cal F}$ if 

1915: $x_i=(i,s_i)$ for $i=1,...,k$ and $x_i=(i,0)$ for $i=k+1,...,2k$. 

1916: \end{proof}

1917: 

1918: 

1919: \paragraph{Discussion:} 

1920: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

1921: Propositions~\ref{no-impl2}, \ref{no-impl3} and~\ref{no-impl4} 

1922: demonstrate that there is only a very narrow margin in which 

1923: strict correlation-intractability may be used. 

1924: Still, even ensembles that are (strict) correlation-intractable

1925: with respect to relations of a-priori bounded total length 

1926: (of input-output sequences) may be useful in some applications. 

1927: Typically, this may hold in applications 

1928: where number of invocations of the cryptosystem is a-priori bounded

1929: (or where the security of the system depends only on an a-priori 

1930: bounded partial history of invocations; e.g., the current one).

1931: We note that the Fiat-Shamir heuristic 

1932: for transforming interactive identification protocols into

1933: signature schemes~\cite{FiSh86} does not fall into the above category, 

1934: since the function's seed needs to be fixed with the public key, 

1935: and used for signing polynomially many messages, 

1936: where the polynomial is not a-priori known.

1937: 

1938: \subsection{Correlation intractability for given, polynomial-time

1939: relations}%\label{discuss.sec}

1940: In all our negative results, the evasive relation demonstrating

1941: that a certain function ensemble is not correlation-intractable

1942: is more complex than the function ensemble itself.

1943: A natural restriction on correlation-intractability is to require

1944: that it holds only for relations recognizable within certain

1945: fixed polynomial time bounds (or some fixed space bound), and 

1946: allowing the function ensemble

1947: to have a more complex polynomial-time evaluation algorithm.

1948: We stress that, 

1949: in both the definition of evasiveness and correlation-intractability,

1950: the adversary that generates the inputs to the relation

1951: is allowed arbitrary (polynomial) running time; this time may be larger

1952: than both the time to evaluate the function ensemble 

1953: and the time to evaluate the relation. 

1954: Such a restricted notion of correlation-intractability

1955: may suffice for some applications, and it would be interesting to

1956: determine whether function ensembles satisfying it do exist. 

1957: Partial results in this direction were obtained by Nissim~\cite{kobbi}

1958: and are described next:

1959: 

1960: \BP[\cite{kobbi}] 

1961: Let $\dlen,\rlen: \intfnc$ be arbitrary length functions, with 

1962: $k\geq\rlen(k)\cdot(\dlen(k)+\omega(\log k))$.% 

1963: \footnote{\

1964: Recall that $(\dlen,\rlen)$-restricted correlation-intractable ensembles

1965: exist for $k\geq2^{\dlen(k)}\cdot\rlen(k)$; see Footnote~\ref{d-log.fn}.}

1966: Then, for every binary relation $R$ that is evasive with respect to 

1967: $(\dlen,\rlen)$ and recognizable in polynomial-time, 

1968: there exists a function ensemble ${\cal F}^R=\{f_s\}$

1969: that is correlation-intractable with respect to $R$;

1970: that is, for every $\dlen$-respecting probabilistic

1971: polynomial-time machine $M$ it holds that

1972: \[\Pr_{s\in\bitset^k}[x\gets M(s),\;\;(x,f_s(x))\in R] = \negl(k)\]

1973: \label{Nissim.prop1} 

1974: \EP 

1975: We note that the postulated construction uses a seed length

1976: that is longer than $\dlen+\rlen$. Thus, this positive result

1977: capitalizes on both restrictions discussed above

1978: (i.e., both the length and the complexity restrictions). 

1979: \medskip 

1980: 

1981: \begin{proof}

1982: Let $t=\dlen(k)+\omega(\log k)$.

1983: For every seed $s=(s_1,...,s_t)\in\bitset^{t\cdot \rlen(k)}$,

1984: we define $f_s:\bitset^{\dlen(k)}\to\bitset^{\rlen(k)}$

1985: so that $f_{s_1,...,s_t}(x)$ equals $s_i$

1986: if $i$ is the smallest integer such that $(x,s_i)\not\in R$. 

1987: In case $(x,s_i)\in R$ holds for all $i$'s,

1988: we define $f_{s_1,...,s_t}(x)$ arbitrarily.

1989: 

1990: \def\Gk{S_k}

1991: Let $R(x)\eqdef\{y:(x,y)\in R\}$, 

1992: and $\Gk\eqdef\{x\in\bitset^{\dlen(k)}: |R(x)|\leq 2^{\rlen(k)}/2 \}$ 

1993: (S stands for ``Small image''). 

1994: Since $R$ is evasive, 

1995: it is infeasible to find an $x\in\bitset^{\dlen(k)}$ not in $\Gk$.

1996: Thus, for every probabilistic polynomial-time $M$,

1997: $\Pr_{s\in\bitset^k}[M(s)\not\in \Gk]=\negl(k)$. 

1998: On the other hand, the probability that such $M(s)$

1999: outputs an $x\in \Gk$ so that $(x,f_{s}(x))\in R$

2000: is bounded above by\footnote{\

2001: For the first inequality,

2002: we use the fact that if there exists an $i$ such that $(x,s_i)\not\in R$

2003: then $(x,f_{s}(x))\not\in R$.} 

2004: \begin{eqnarray*} 

2005: \Pr_{s\in\bitset^k}[\exists x\in \Gk\;\;\mbox{\rm s.t. }\;(x,f_{s}(x))\in R]

2006: &\leq&\Pr_{s\in\bitset^k}[\exists x\in \Gk\,\forall i\;\; (x,s_i)\in R] \\

2007: &\leq&|\Gk|\cdot\max_{x\in \Gk}

2008:            \left\{\Pr_{s}[\forall i\;\; (x,s_i)\in R]\right\} \\

2009: &\leq& 2^{\dlen(k)}\cdot(1/2)^t \;=\;  \negl(k)

2010: \end{eqnarray*} 

2011: Combining the two cases, the proposition follows. 

2012: \end{proof}

2013: 

2014: Considering the notion of multi-invocation correlation-intractability

2015: when restricting the complexity of the relation (and allowing the

2016: function ensemble to be more complex), Nissim has obtained

2017: another impossibility result \cite{kobbi}: 

2018: 

2019: \BP[\cite{kobbi}]

2020: There exists an evasive relation $R$ that 

2021: is recognizable in polynomial-time

2022: so that no function ensemble ${\cal F}=\{f_s\}$ 

2023: is multi-invocation correlation-intractable with respect to $R$;

2024: that is, for every function ensemble ${\cal F}=\{f_s\}$ 

2025: there exists a polynomial-time machine $M$ such that

2026: $$

2027: \Pr_s\left[(x_1,...,x_t) \gets M(s)\,;\ \;

2028:    ((x_1,...,x_t),(f_s(x_1),...,f_s(x_t))\!\in\!R\;\right]\;\;=\;\;1

2029: $$

2030: Furthermore, for some universal polynomial $p$, 

2031: which is independent of ${\cal F}$, it holds that $t<p(|x_1|)$. 

2032: \label{Nissim.prop2} 

2033: \EP

2034: We stress that the above assertion includes even function ensembles 

2035: that have (polynomial-time) evaluation algorithms of running time 

2036: greater than the time it takes to recognize $t$-tuples of corresponding 

2037: length is the relation. Furthermore, it includes function ensembles

2038: having seeds of length exceeding the total length of pairs in the

2039: relation. 

2040: 

2041: \medskip\noindent{\bf Proof Sketch:}

2042: We follow the ideas underlying the proof of Theorem~\ref{sign.thm}.

2043: Specifically, using the universal machine $M_{\cal U}$

2044: and the algorithms ($\prv$ and $\ver$) of a CS-proof system,

2045: we consider a relation $R$ that contains pairs of binary sequences, 

2046: so that $((x,\pi,q_1...,q_{m}),(y,\phi,a_1...,a_{m}))\in R$ if 

2047: these strings describe an accepting execution of the CS-verifier 

2048: with respect to machine $M_{\cal U}$. That is, we require that the 

2049: following conditions hold:

2050: \BE

2051: \item 

2052: All the strings $y,\phi,a_1...,a_{m}$ have the same length. Below we 

2053: denote this length by $\rlen$, $|y| =|\phi| =|a_1| =\cdots =|a_{m}| =\rlen$. 

2054: 

2055: \item 

2056: The string $\pi$ is an alleged CS-proof for the assertion that the 

2057: machine $M_{\cal U}$ accepts the input $(x,y)$ within $t(n)=n^{\log n}$ 

2058: steps, where $n\eqdef|x|+|y|$. 

2059: 

2060: \item

2061: Given access to an oracle that on queries $q_i$ returns answers $a_i$, 

2062: and given security parameter $n+\rlen$ 

2063: and input $w = (\vect{M_{\cal U}}, (x,y),t(n))$, 

2064: the CS verifier $\ver$ accepts the CS-proof $\pi$ 

2065: after querying the oracle on $q_1 \ldots q_m$ (in this order),

2066: and obtaining the corresponding answers $a_1 \ldots a_m$. 

2067: 

2068: (Here we use the fact that the verifier is deterministic,

2069: and thus its queries are determined by its input and the answers

2070: to previous queries.) 

2071: \EE

2072: 

2073: Recall that, by definition, $m$ is bounded by a fixed polynomial

2074: in $n$. In fact, in Micali's construction~\cite{Mi94}, $m$ is 

2075: poly-logarithmic in $n$. 

2076: We comment that, assuming the existence

2077: of suitable collision-intractable hash functions, 

2078: one may obtain $m=1$ (cf.~\cite{NaNi99}.  

2079: In addition, one may need to make some minor modification

2080: in the above construction.)

2081: 

2082: 

2083: As in the proof of Theorem~\ref{sign.thm}, 

2084: using the computational soundness of CS-proofs,

2085: it can be shown that the above relation is evasive. 

2086: By the additional efficiency conditions of CS-proofs,

2087: it follows that the relation is recognizable in polynomial-time.

2088: On the other hand, as in the proof of Theorem~\ref{sign.thm}, 

2089: for every function ensemble ${\cal F}^i=\{f^i_s\}$

2090: there exists a polynomial-time adversary $A$,

2091: that on input $s$ produces a sequence $(x,\pi,q_1,...,q_{m})$ so that 

2092: $(

2093:  (x,\pi,q_1,...,q_{m}),(f^i_s(x),f^i_s(\pi),f^i_s(q_1),...,f^i_s(q_{m}))

2094:   ) \in R$. 

2095: This is done as follows:

2096: First $A$ sets $x=\langle i,s\rangle$, $y=f_s^i(x)$, and $n\eqdef|x|+|y|$. 

2097: Next, $A$ constructs a CS-proof that indeed $M_{\cal U}$ accepts $(x,y)$ 

2098: within $n^{\log n}$ steps,

2099: and sets $\pi$ to equal this proof. 

2100: (This step takes time polynomial in the evaluation time of $f_s^i(x)$.)

2101: Note that since $(x,y)$ is indeed accepted by $M_{\cal U}$

2102: (in less than $n^{\log n}$ steps), 

2103: the verifier accept $\pi$ as a proof no matter how the oracle is

2104: determined (since perfect completeness holds). 

2105: Finally, the adversary invokes the verifier

2106: (on input consisting mainly of $(x,y)$ and $\pi$), and (by emulating 

2107: the oracle) determines interactively the oracle queries and answers

2108: of the verifier; that is, for every $j=1,...,m$, the adversary

2109: determines the $j^\th$ query made by the verifier,

2110: sets $q_{j}$ to equal this query, and provides the verifier

2111: with the answer $f^i_s(q_{j})$. \qqed 

2112: 

2113: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

2114: \section{Conclusions}

2115: \label{sec-conclusions}

2116: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

2117: The authors  have different opinions regarding the Random Oracle Methodology. 

2118: Rather than trying to strike a mild compromise,

2119: we prefer to present our disagreements in the most controversial form. 

2120: 

2121: \subsection{Ran's Conclusions}

2122: 

2123: Real-life cryptographic applications are complex objects. On top of the

2124: ``cryptographic core,'' these applications typically involve 

2125: numerous networking protocols,  several other applications,

2126: user-interfaces, and in fact also an entire operating-system.

2127: The security of an application depends on the security of all these

2128: components operating in unison. Thus, in principle, the best way to gain

2129: assurance in the security of a cryptographic application is to analyze

2130: it as a single unit, bones and feathers included.

2131: 

2132: However, analyzing an entire system is prohibitively complex.

2133: Moreover, we often feel that the ``essence'' of a cryptographic

2134: application

2135: can be presented in a relatively simple way without getting into many 

2136: details, which, we feel, are ``extraneous'' to the actual security.

2137: Consequently, we often make  {\em abstractions} of a cryptographic

2138: application by leaving many details ``outside the model''. 

2139: Nonetheless, some caution is needed when making abstractions:

2140: While good abstractions are important and useful, bad abstractions can 

2141: be dangerous and misleading. Thus, it is crucial to make sure that

2142: one uses a sound abstraction, or one that helps to distinguish between

2143: good and bad applications.

2144: 

2145: One popular abstraction is to treat computers in a network as interactive 

2146: Turing machines who run one specific (and relatively simple) algorithm, and

2147: assume that delivery of messages is done simply by having one machine

2148: write values on the tapes of another machine. We are then satisfied with

2149: defining and analyzing security of a protocol in this abstract model. In

2150: other words, this abstraction implicitly uses the following methodology 

2151: (which I'll call the ``Interactive Turing machine methodology''): Design 

2152: and analyze a protocol in the ``idealized system'' (i.e., using Turing

2153: machines). Next, come up with an ``implementation'' of the idealized

2154: protocol by adding the components that deal with the networking

2155: protocols, the operating system, the user interfaces, etc. Now, ``hope''

2156: that the implementation is indeed secure.

2157: 

2158: We widely believe that this methodology is sound, in the sense that

2159: if an idealized protocol is secure then there {\em exist} secure

2160: implementations of it. Furthermore, security of an idealized protocol

2161: is a good predictor for the feasibility of finding a good implementation

2162: to it.  (Of course, finding secure implementations to secure idealized

2163: protocols is a far-from-trivial task, and there is probably no single 

2164: automatic method for securely implementing any idealized protocol. But

2165: this does not undermine the soundness of the 

2166: ``Interactive Turing machine methodology''.)

2167: 

2168: The Random Oracle Methodology is, in essence, another proposed abstraction 

2169: of cryptographic applications. It too proposes to define and analyze 

2170: security of protocols in an idealized model, then perform some 

2171: transformation that is ``outside the formal model'', and now ``hope'' that 

2172: the resulting implementation is secure. At first glance

2173: it looks like a great 

2174: abstraction: It does away with specific implementation issues of

2175: ``cryptographic hash functions'' and concentrates on designing protocols

2176: assuming that an ``ideal hash function'' is available. Indeed,

2177: protocols that were 

2178: designed using this methodology are remarkably simple and efficient,

2179: while resisting all known attacks. 

2180: 

2181: However, as shown in this work, and in sharp contrast to the

2182: ``Interactive Turing machine methodology'', the Random Oracle 

2183: Methodology is not sound. Furthermore, it is a bad predictor to the 

2184: security of implementations: Not only do there {\em exist}

2185: idealized protocols that have no secure implementations, practically 

2186: {\em any} idealized protocol can be slightly ``tweaked'' so that the

2187: tweaked protocol remains just  as secure in the idealized model, 

2188: but has no secure implementations. This leaves us no choice but

2189: concluding that, in spite of its apparent successes, the Random Oracle 

2190: Methodology  is a bad abstraction of protocols for the purpose of analyzing

2191: security.

2192: 

2193: \paragraph{The loss of reductions to hard problems.}

2194: The above argument should provide sufficient motivation to be wary of

2195: security analyses in the \ROM.

2196: Nonetheless, let us highlight the following additional 

2197: disturbing aspect of such analysis.

2198: 

2199: One of the great contributions of complexity-based modern cryptography, 

2200: developed in the past quarter of a century, is the ability to base the

2201: security of many varied protocols on a small number of well-defined

2202: and well-studied complexity assumptions. Furthermore, typically the

2203: proof of security of a protocol provides us with  a method for

2204: transforming adversary that breaks the security of the said protocol

2205: into an adversary that refutes one of the well-studied assumptions. 

2206: In light of our inability to prove security of protocols from scratch,

2207: this methodology provides us with the ``next best'' evidence for the

2208: security of protocols.

2209: 

2210: The Random Oracle Methodology does away with these advantages.

2211: Assume that an idealized protocol $A$ is proven secure in the

2212: \ROM\ based on, say, the Diffie-Hellman assumption, and that someone

2213: comes up with a way to break  % some implementation of $A$, or even 

2214: {\em any implementation} of $A$. This does

2215: not necessarily mean that it is now possible to break Diffie-Hellman!

2216: Consequently, the reducibility of the security of $A$ to the hardness of

2217: Diffie-Hellman is void. This brings us back to a situation

2218: where the security of each protocol is a ``stand-alone'' problem

2219: and is, in essence, unrelated to the hardness of known problems.

2220: 

2221: 

2222: \paragraph{Possible alternative directions.}

2223: In spite of its shortcomings, the Random Oracle Methodology seems 

2224: to generate simple and efficient protocols against which no attacks are 

2225: known. One possible direction towards providing formal 

2226: justification for some

2227: of these protocols is to identify useful, 

2228: special-purpose properties of the random oracle, which can be also 

2229: provided by a fully specified function (or function ensemble)  

2230: and so yield secure implementations of certain useful ideal systems. 

2231: First steps in this direction were taken in \cite{Ca97,CMR98,GHR99}.

2232: Hopefully, future works will push this direction further.

2233: 

2234: 

2235: \subsection{Oded's Conclusions}

2236: My starting point is that within the domain of science, 

2237: every deduction requires a rigorous justification.%

2238: \footnote{\ 

2239: This does not disallow creative steps committed

2240: in the course of research, without proper justification. 

2241: Such unjustified steps are the fuel of progress. 

2242: What I refer to are claims that are supposed to reflect valid facts.

2243: Such claims should be fully justified, or offered as conjectures.} 

2244: In contrast, unjustified deductions should not be allowed;

2245: especially not in a subtle research area such as Cryptography. 

2246: Furthermore, one should refrain from making statements that are

2247: likely to mislead the listener/reader, such as claiming a

2248: result in a restricted model while creating the impression 

2249: that it holds also in a  less restricted model. 

2250: The presentation of such a result should clearly state 

2251: the restrictions under which it holds, 

2252: and refrain from creating the impression that the result

2253: extends also to a case where these restrictions are waived

2254: (unless this is indeed true (and one can prove it)). 

2255: Needless to say, it is perfectly {\sc ok} to conjecture that 

2256: a restricted result extends also to a case when these restrictions 

2257: are waived, but the stature of such a statement (as a conjecture) 

2258: should be clear.

2259: 

2260: The above abstract discussion directly applies to security in the \ROM.

2261: Deducing that the security of a scheme in the \ROM\/ 

2262: means anything about the security of its implementations,

2263: without proper justification, is clearly wrong.%

2264: \footnote{\ Using the \ROM\/ as a justification to the feasibility

2265: of meeting some security requirements is even ``more wrong''.}  

2266: This should have been clear also before the current work.

2267: It should have also been clear that no proper justification 

2268: of deduction from security in the \ROM\/ to security

2269: of implementations has been given (so far).

2270: The contributions of the current work are two-fold:

2271: \BE

2272: \item %Correlation Intractability {sec-unpredict}

2273: This work uncovers inherent difficulties in the project of 

2274: providing conditions that would allow 

2275: (justifiable) deduction from security in

2276: the \ROM\/ to security of implementations. 

2277: Such a project could have proceeded by identifying properties 

2278: that characterize proofs of security in the \ROM,

2279: and (justifiably) deducing that the such schemes maintain their security 

2280: when implemented with ensembles satisfying these properties. 

2281: The problem with this project is that correlation intractability

2282: should have been (at the very least) one of these properties,

2283: but (as we show) no function ensemble can satisfy it. 

2284: \item %Failure {sec-insecure}

2285: As stated above, deducing that the security of a scheme in the \ROM\/

2286: means anything about the security of its implementations,

2287: without proper justification, is clearly wrong.

2288: The current work presents concrete examples 

2289: in which this unjustified deduction leads to wrong conclusions.

2290: That is, it is shown that not only that unjustified deduction

2291: regarding the \ROM\/ {\em {\sc may} lead to wrong conclusions},

2292: but rather than in some cases {\sc indeed} this unjustified

2293: deduction {\em {\sc does} lead to wrong conclusions}.

2294: Put in other words, if one needs a concrete demonstration 

2295: of the dangers of unjustified deduction when applied to the \ROM,

2296: then this work provides it. % I personally did not need it. 

2297: \EE

2298: 

2299: \paragraph{The bottom-line:}

2300: It should be clear that the Random Oracle Methodology

2301: is not sound; that is, the mere fact that a scheme is secure in

2302: the \ROM\/ cannot be taken as evidence (or indication) to

2303: the security of (possible) implementations of this scheme. 

2304: Does this mean that the \ROM\/ is useless?

2305: Not necessarily: it may be useful as a test-bed (or as a sanity check).% 

2306: \footnote{\

2307: This explains the fact the Random Oracle

2308: Methodology is in fact used in practice. 

2309: In also explains why many reasonable schemes, 

2310: the security of which is still an open problem,

2311: are secure in the \ROM: 

2312: good suggestions should be expected to pass a sanity check.} 

2313: Indeed, if the scheme does not perform well on the test-bed

2314: (resp., fails the sanity check) then it should be dumped. 

2315: But one should {\em not}\/ draw wrong conclusions from the mere fact

2316: that a scheme performs well on the test-bed

2317: (resp., passes the sanity check). 

2318: In summary, the Random Oracle Methodology is actually 

2319: a method for ruling out {\em some}\/ insecure designs, 

2320: but this method is not ``complete'' 

2321: (i.e., it may fail to rule out insecure designs).%

2322: \footnote{\ 

2323: Would I, personally, endorse this method 

2324: is a different question. My answer is very much time-sensitive:

2325: Given the current misconceptions regarding the \ROM, 

2326: I would suggest not to include, in currently published work, 

2327: proofs of security in the \ROM.

2328: My rationale is that the dangers of misconceptions

2329: (regarding such proofs) seem to out-weight 

2330: the gain of demonstrating that the scheme passed a sanity check.

2331: I hope that in the future such misconceptions will be less

2332: prevailing, at which time it would be indeed recommended to

2333: report on the result of a sanity check.} 

2334: 

2335: \subsection{Shai's Conclusions}

2336: The negative results in this work (and in particular Theorems~\ref{sign.thm} 

2337: and~\ref{encrypt.thm}) leave me with an uneasy feeling: adopting 

2338: the view that a good theory should be able to explain ``the real 

2339: world'', I would have liked theoretical results that explain the 

2340: apparent success of the random oracle methodology in devising useful, 

2341: seemingly secure, cryptographic schemes. (Indeed, this was one of the 

2342: original motivations for this work.) 

2343: Instead, in this work we show that security of cryptographic schemes 

2344: in the {\ROM} does not necessarily imply security in ``the real world''. 

2345: Trying to resolve this apparent mismatch, one may come up with several 

2346: different explanations. Some of those are discussed below:

2347: \BI

2348: \item 

2349: The current success of this methodology is due to pure luck: all the 

2350: current schemes that are proven secure in the {\ROM}, happen to be secure 

2351: also in the ``real world'' for no reason.   However, our ``common sense'' 

2352: and sense of esthetics must lead us to reject such explanation. 

2353: 

2354: \item 

2355: The current apparent success is a mirage: some of the schemes that are 

2356: proven secure in the {\ROM} are not really secure, and attacks on them 

2357: may be discovered in the future. 

2358: 

2359: This explanation seems a little more attractive than the previous one. 

2360: After all, a security proof in the {\ROM} eliminates a broad class of 

2361: potential attacks (i.e., the ones that would work also in the {\ROM}), 

2362: and in many cases it seems that attacks of this type are usually the 

2363: ones that are easier to find.  Hence, it makes sense that if there exists 

2364: a ``real life'' attack on a scheme which is secure in the {\ROM}, it may 

2365: be harder -- and take longer -- to find this attack. 

2366: Still, the more time passes without published attacks against ``real 

2367: life'' schemes which are proven secure in the {\ROM}, the less likely 

2368: this explanation would become. 

2369: 

2370: \item 

2371: Another possible explanation is that the random oracle methodology 

2372: works for the current published schemes, due to some specific features 

2373: of these schemes that we are yet to identify.  That is, maybe it is 

2374: possible to identify interesting classes of schemes, for which security 

2375: in the {\ROM} implies the existence of a secure implementation.%

2376: \footnote{One particularly silly example are schemes that do not use the 

2377: oracle.  Another, more interesting example, are schemes that only use 

2378: the ``perfect one-way'' property of the oracle; see \cite{Ca97,CMR98}. 

2379: }\  

2380: 

2381: Identifying such interesting classes, and proving the above implication, 

2382: is an important -- and seemingly hard -- research direction.  (In fact, 

2383: it even seems to be hard to identify classes of schemes for which this 

2384: implication makes a reasonable computational assumption.) 

2385: To appreciate the difficulty in proceeding towards this goal, recall 

2386: that the techniques in the work can be used to ``tweak'' almost any 

2387: cryptographic scheme into one which is secure in the {\ROM} but has 

2388: no secure implementation.  Hence, any classification as above must 

2389: be refined enough to separate the original scheme (for which we want 

2390: to prove that security in the {\ROM} implies security in the real world) 

2391: from the ``tweaked'' one (for which this implication does not hold). 

2392: \EI

2393: 

2394: My bottom line is that at the present time, the random oracle methodology 

2395: seems to be a very useful ``engineering tool'' for devising schemes. 

2396: As a practical matter, I would much rather see today's standards built 

2397: around schemes which are proven secure in the {\ROM}, than around 

2398: schemes for which no such proofs exist. 

2399: The results in this paper, however, must serve as a warning that 

2400: security proof in the {\ROM} can never be thought of as the end of 

2401: the road.  Proofs in the {\ROM} are useful in that they eliminate a 

2402: broad class of attacks, but they do not imply that other attacks cannot 

2403: be found. 

2404: 

2405: In terms of scientific research, our works clearly demonstrate that 

2406: the random oracle methodology is not sound in general.  My feeling is 

2407: that our understanding of the relations between the {\ROM} and the 

2408: ``real world'' is very limited.  As I said above, it would be very 

2409: interesting to identify special cases in which the random oracle 

2410: methodology is sound.  Similarly, it would be interesting to see other, 

2411: ``less artificial'', examples where this methodology fails. 

2412: 

2413: 

2414: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

2415: \section*{Acknowledgments}

2416: We wish to thank Silvio Micali for enlightening discussions. 

2417: We thank Clemens Holenstein for uncovering a flaw in the 

2418: proof of \prpref{no-impl4} in an earlier version of this paper. 

2419: Special thanks to Kobbi Nissim for telling us about his related results

2420: (i.e., Propositions~\ref{Nissim.prop1} and~\ref{Nissim.prop2}) 

2421: and permitting us to include them in this write-up. 

2422: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

2423: 

2424: \bibliographystyle{abbrv}

2425: \begin{thebibliography}{10}

2426: 

2427: \bibitem{BeRo93}

2428: M.~Bellare and P.~Rogaway.

2429: \newblock Random oracles are practical: a paradigm for designing efficient

2430:   protocols.

2431: \newblock In {\em 1st Conference on Computer and Communications Security},

2432:   pages 62--73. ACM, 1993.

2433: 

2434: \bibitem{BeRo96}

2435: M.~Bellare and P.~Rogaway.

2436: \newblock The exact security of digital signatures: How to sign with rsa and

2437:   rabin.

2438: \newblock In {\em Advances in Cryptology - {EUROCRYPT}'96}, volume 1070 of {\em

2439:   Lecture Notes in Computer Science}, pages 399--416. Springer-Verlag, 1996.

2440: 

2441: \bibitem{BlMi84}

2442: M.~Blum and S.~Micali.

2443: \newblock How to generate cryptographically strong sequences of pseudo-random

2444:   bits.

2445: \newblock {\em {SIAM Journal on Computing}}, 13:850--864, 1984.

2446: 

2447: \bibitem{Ca97}

2448: R.~Canetti.

2449: \newblock Towards realizing random oracles: Hash functions that hide all

2450:   partial information.

2451: \newblock In {\em Advances in Cryptology - {CRYPTO}'97}, volume 1294 of {\em

2452:   Lecture Notes in Computer Science}, pages 455--469. Springer-Verlag, 1997.

2453: 

2454: \bibitem{CGH98}

2455: R. Canetti, O. Goldreich and S. Halevi. 

2456: The Random Oracle Methodology, Revisited.

2457: \newblock In {\em Proceedings of the 30th Annual ACM Symposium on the Theory of

2458:   Computing},  Dallas, TX, May 1998. ACM.

2459: 

2460: \bibitem{CMR98}

2461: R.~Canetti, D.~Micciancio and O.~Reingold.

2462: \newblock Perfectly one-way probabilistic hashing.

2463: \newblock In {\em Proceedings of the 30th Annual ACM Symposium on the Theory of

2464:   Computing}, pages 131--140, Dallas, TX, May 1998. ACM.

2465: 

2466: \bibitem{Da87}

2467: I.~Damg{\aa}rd.

2468: \newblock Collision free hash functions and public key signature schemes.

2469: \newblock In {\em Advances in Cryptology - {EUROCRYPT}'87}, volume 304 of {\em

2470:   Lecture Notes in Computer Science}, pages 203--216. Springer-Verlag, 1987.

2471: 

2472: \bibitem{magic}

2473: C.~Dwork, M.~Naor, O.~Reingold, and L.~Stockmeyer.

2474: \newblock Magic functions.

2475: \newblock In {\em 40th Annual Symposium on Foundations of Computer Science},

2476:   pages 523--534. IEEE, 1999.

2477: 

2478: \bibitem{FiSh86}

2479: A.~Fiat and A.~Shamir.

2480: \newblock How to prove yourself. practical solutions to identification and

2481:   signature problems.

2482: \newblock In {\em Advances in Cryptology - {CRYPTO}'86}, volume 263 of {\em

2483:   Lecture Notes in Computer Science}, pages 186--189. Springer-Verlag, 1986.

2484: 

2485: \bibitem{GHR99}

2486: R. Gennaro, S. Halevi and T. Rabin. Secure Hash-and-Sign Signatures Without

2487: the Random Oracle.

2488: \newblock In {\em Advances in Cryptology - {EUROCRYPT}'99}, volume 1592 of {\em

2489:   Lecture Notes in Computer Science}, pages 123--139. Springer-Verlag, 1999.

2490: 

2491: \bibitem{G93} O.~Goldreich.

2492: \newblock A Uniform Complexity Treatment of Encryption and Zero-Knowledge.

2493: \newblock {\em Journal of Cryptology}, Vol.~6, No.~1, pages 21--53, 1993.

2494: 

2495: \bibitem{G99} O.~Goldreich.

2496: \newblock {\em Encryption Schemes -- fragments of a chapter}.

2497: \newblock December 1999.

2498: \newblock Available from

2499:           {\tt http://www.wisdom.weizmann.ac.il/$\sim$oded/foc-book.html}

2500: 

2501: \bibitem{ggm86}

2502: O.~Goldreich, S.~Goldwasser, and S.~Micali.

2503: \newblock How to construct random functions.

2504: \newblock {\em Journal of the ACM}, 33(4):210--217, 1986.

2505: 

2506: \bibitem{GK}

2507: O.~Goldreich, and H.~Krawczyk.

2508: \newblock On the Composition of Zero-Knowledge Proof Systems.

2509: \newblock {\em SIAM Journal on Computing}, 25(1):169--192, 1996. 

2510: 

2511: \bibitem{GoMi84}

2512: S.~Goldwasser and S.~Micali.

2513: \newblock Probabilistic encryption.

2514: \newblock {\em Journal of Computer and System Sciences}, 28(2):270--299, April

2515:   1984.

2516: 

2517: \bibitem{gmr88}

2518: S.~Goldwasser, S.~Micali, and R.~Rivest.

2519: \newblock A digital signature scheme secure against adaptive chosen-message

2520:   attacks.

2521: \newblock {\em SIAM Journal of Computing}, 17(2):281--308, Apr. 1988.

2522: 

2523: \bibitem{GuQu88}

2524: L.~Guillou and J.~Quisquater.

2525: \newblock A practical zero-knowledge protocol fitted to security

2526:   microprocessors minimizing both transmission and memory.

2527: \newblock In {\em Advances in Cryptology - {EUROCRYPT}'88}, volume 330 of {\em

2528:   Lecture Notes in Computer Science}, pages 123--128. Springer-Verlag, 1988.

2529: 

2530: \bibitem{HaTa99}

2531: S.~Hada and T.~Tanaka.

2532: \newblock A relationship between one-wayness and correlation intractability.

2533: \newblock In {\em The 2nd

2534:   International Workshop on Practice and Theory in Public Key Cryptography

2535:   (PKC'99)}, volume 1560 of {\em Lecture Notes in Computer Science}, pages

2536:   82--96, Japan, March 1999. Springer-Verlag.

2537: 

2538: \bibitem{ImRu89}

2539: R.~Impagliazzo and S.~Rudich.

2540: \newblock Limits on the provable consequences of one-way permutations.

2541: \newblock In {\em Proceedings of the 21st Annual {ACM} Symposium on Theory of

2542:   Computing}, pages 44--61, Seattle, WA, May 1989. ACM.

2543: 

2544: \bibitem{Ki92}

2545: J.~Kilian.

2546: \newblock A note on efficient zero-knowledge proofs and arguments.

2547: \newblock In {\em Proceedings of the 24th Annual ACM Symposium on the Theory of

2548:   Computing}, pages 723--732. ACM, May 1992.

2549: 

2550: \bibitem{Mi94}

2551: S.~Micali.

2552: \newblock {CS} proofs.

2553: \newblock In {\em 35th Annual Symposium on Foundations of Computer Science

2554:   ("FOCS'94")}, pages 436--453. IEEE, 1994.

2555: 

2556: \bibitem{NaNi99}

2557: M.~Naor and K.~Nissim.

2558: \newblock Computationally sound proofs: Reducing the number of random oracle

2559:   calls.

2560: \newblock manuscript, 1999.

2561: 

2562: \bibitem{ny89}

2563: M.~Naor and M.~Yung.

2564: \newblock Universal one-way hash functions and their cryptographic

2565:   applications.

2566: \newblock In {\em Proceedings of the 21st Annual {ACM} Symposium on Theory of

2567:   Computing}, pages 33--43, 1989.

2568: 

2569: \bibitem{kobbi} K.~Nissim. 

2570: \newblock Two results regarding correlation intractability. 

2571: \newblock Manuscript, 1999.

2572: 

2573: \bibitem{Ok92}

2574: T.~Okamoto.

2575: \newblock Provably secure and practical identification scheme and corresponding

2576:   signature scheme.

2577: \newblock In {\em Advances in Cryptology - {CRYPTO}'92}, volume 740 of {\em

2578:   Lecture Notes in Computer Science}, pages 31--53. Springer-Verlag, 1992.

2579: 

2580: \bibitem{PoSt96}

2581: D.~Pointcheval and J.~Stern.

2582: \newblock Security proofs for signature schemes.

2583: \newblock In {\em Advances in Cryptology - {EUROCRYPT}'96}, volume 1070 of {\em

2584:   Lecture Notes in Computer Science}, pages 387--398. Springer-Verlag, 1996.

2585: 

2586: \bibitem{ro90}

2587: J.~Rompel.

2588: \newblock One-way functions are necessary and sufficient for secure signatures.

2589: \newblock In {\em Proceedings of the 22nd Annual {ACM} Symposium on Theory of

2590:   Computing}, pages 387--394, 1990.

2591: 

2592: \bibitem{Sc91}

2593: C.~Schnorr.

2594: \newblock Efficient signature generation by smart cards.

2595: \newblock {\em {Journal of Cryptology}}, 4(3):161--174, 1991.

2596: 

2597: \bibitem{yao82a}

2598: A.~C. Yao.

2599: \newblock Theory and applications of trapdoor functions.

2600: \newblock In {\em 23rd Annual Symposium on Foundations of Computer Science},

2601:   pages 80--91. IEEE, Nov. 1982.

2602: 

2603: \end{thebibliography}

2604: 

2605: 

2606: \end{document} 

2607: 

2608: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

2609: %%%    END DOCUMENT    %%%    END DOCUMENT    %%%    END DOCUMENT    %%% 

2610: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

2611: 

2612: