After the reviews from Eurocrypt 2013
(http://hyperelliptic.org/tanja/nonuniformreviews.txt, also posted
anonymously as http://pastebin.com/BxQkkq6y) we made huge changes to
this paper. This is the svn diff output (limited to TeX files for
sections; also, some lines are removed from the output for anonymity)
between our Eurocrypt 2013 submission and our Crypto 2013 submission.
Note that this is more than 2000 lines.
Shortly after the Crypto 2013 submission we made various further edits,
mainly to analyze the new formalization of collision resistance but also
to add several small clarifications at various points in the paper.
Those further edits aren't shown here.
Index: intro.tex
===================================================================
 intro.tex (revision 87)
+++ intro.tex (revision 178)
@@ 21,8 +21,8 @@
The first part is a concrete definition of what it means for a cipher or a MAC to be secure.
We quote from the classic paper \cite[Section 1.3]{2000/bellarecbc}
by Bellare, Kilian, and Rogaway:
the PRPinsecurity of a cipher such as AES
(denoted ``$\Adv_{\AES}^{\prp}(q',t)$'')
+the PRP``insecurity'' of a cipher such as AES
+(denoted ``$\Adv_{\AES}^{\prp}(q',t')$'')
is defined as the ``maximum,
over all adversaries
restricted to $q'$ inputoutput examples
@@ 36,14 +36,12 @@
(denoted ``$\Adv_{{\CBC^m}\hbox{}{\AES}}^{\prf}(q,t)$'')
is defined similarly,
using a uniform random function rather than a uniform random permutation.
These definitions have become completely standard,
except for a minor change in notation:
``the $(q,t)$security of AES is at most $\epsilon$''
is usually abbreviated ``AES is $(q,t,\epsilon)$secure''.
The second part of the answer is
a concrete security theorem bounding the insecurity of AESCBCMAC
in terms of the insecurity of AES.
+in terms of the insecurity of AES,
+or more generally the insecurity of $F$CBCMAC
+in terms of the insecurity of $F$ for any $\ell$bit block cipher $F$.
Specifically,
here is the main theorem of \cite{2000/bellarecbc}:
``for any integers $q,t,m\ge 1$,
@@ 120,16 +118,44 @@
into an AES security conjecture and a CBCMAC security proof
drastically simplifies the cryptanalyst's job.
The same pattern can be found throughout the literature on provable concrete security.
+The same threepart pattern has
+(as illustrated by Appendix~\ref{literature})
+become completely standard
+throughout the literature on concrete ``provable security''.
+First part:
+The insecurity of $X${\dash}where $X$ is a primitive such as AES or RSA,
+or a higherlevel protocol such as AESCBCMAC or RSAPSS{\dash}is defined as
+the maximum, over all algorithms $A$ (``attacks'') that cost at most $C$,
+of the probability (or advantage in probability) that $A$ succeeds in breaking $X$.
+This insecurity is explicitly a function of the cost limit $C$;
+typically $C$ is separated into
+(1) a time limit $t$ and
+(2) a limit $q$ on the number of oracle queries.
+Note that this function depends implicitly on how the ``cost'' of an algorithm is defined.
+
+Often ``the $(q,t)$insecurity of $X$ is at most $\epsilon$''
+is abbreviated ``$X$ is $(q,t,\epsilon)$secure''.
+Many papers prefer the more concise notation
+and do not even mention the insecurity function.
+We emphasize, however, that this is merely a superficial change in notation,
+and that both of the quotes in this paragraph refer to exactly the same situation:
+namely, the nonexistence of algorithms that cost at most $(q,t)$
+and that break $X$ with probability more than $\epsilon$.
+
+Second part:
Concrete ``provable security''
theorems state that the insecurity of a complicated object
is bounded in terms of the insecurity of a simpler object;
+theorems state that the insecurity (or security) of a complicated object
+is bounded in terms of the insecurity (or security) of a simpler object.
+Often these theorems require restrictions on the types of attacks allowed
+against the complicated object:
for example,
Bellare and Rogaway in \cite{1995/bellareoaep} showed that RSAOAEP
has similar security to RSA against generichash attacks
(attacks in the ``randomoracle model'').
+
+Third part:
The insecurity of a wellstudied primitive such as AES or RSA1024
is then conjectured to match the success probability of the best attack known.
+is conjectured to match the success probability of the best attack known.
For example,
Bellare and Rogaway in \cite[Section 1.4]{1996/bellaresigs},
evaluating the concretesecurity of RSAFDH and RSAPSS,
@@ 143,10 +169,9 @@
in attacking these primitives.

\subheading{Contributions of this paper}
+\subheading{Primary contribution of this paper}
Our primary goal in this paper is to convincingly undermine
all of the standard security conjectures discussed above.
+all of the standard security conjectures reviewed above.
Specifically,
Sections \ref{aes}, \ref{ecc}, \ref{dsa}, and \ref{rsa}
show{\dash}assuming standard, amply tested heuristics{\dash}%
@@ 157,14 +182,15 @@
the insecurity of AES, NIST P256, DSA3072, and RSA3072,
according to the standard concretesecurity definitions,
reaches essentially 100\% for a time bound considerably below $2^{128}$.
The conjectures by Bellare, Kilian, and Rogaway in
+The conjectures by Bellare and Rogaway in
\cite[Section 1.4]{1996/bellaresigs},
\cite[Section 3.6]{2005/bellareintro},
\cite[Section 3.2]{2006/bellarehmac},
etc.~are false for every reasonable assignment of the unspecified constants.
The same ideas show that there {\it exist\/} highprobability attacks
against AESCBCMAC, RSAPSS, RSAOAEP, and thousands of other ``provably secure'' protocols,
+against AESCBCMAC, RSA3072PSS, RSA3072OAEP,
+and thousands of other ``provably secure'' protocols,
in each case taking considerably less than $2^{128}$ time.
It is not clear that similar attacks exist against {\it every\/} such protocol in the literature,
since in some cases the security reductions are unidirectional,
@@ 173,10 +199,10 @@
We do not claim that this reflects any actual security problem
with AES, NIST P256, DSA3072, and RSA3072,
or with the higherlevel protocols built on top of these primitives.
+or with higherlevel protocols built from these primitives.
On the contrary!
It is clear that these attacks {\it exist},
but we conjecture that any fast {\it construction\/} of these attacks
+Our constructions of these attacks are very slow;
+we conjecture that any {\it fast\/} construction of these attacks
has negligible probability of success.
Users have nothing to worry about.
@@ 198,30 +224,87 @@
Our secondary goal in this paper is to articulate a recommended rescue strategy.
Appendix~\ref{salvage}
analyzes several possible responses to the existence of these attacks:
\begin{itemize}
\item Circle the wagons: abandon the conjectures but preserve the definitions.
\item Switch the definitions to the NAND metric.
\item Switch the definitions to the $AT$ metric.
\item Add effectivity to the definitions.
\item Add uniformity to the definitions.
\end{itemize}
We recommend switching to the $AT$ metric, adding effectivity,
and refactoring theorems to simplify further changes.
Stating and proving new definitions and theorems will require considerable effort,
but we think that the attacks amply justify this effort.
+\subheading{Secondary contribution of this paper}
+Our secondary goal in this paper is to propose a rescue strategy:
+a new way to define security{\dash}a definition that restores, to the maximum extent possible,
+the attractive threepart security arguments described above.
+All of the gaps considered in this paper come from errors in quantifying feasibility.
+Each of the highprobability attacks presented in this paper
+(1) has a cost $t$ according to the standard definitions,
+but (2) is obviously infeasible,
+even for an attacker able to carry out a ``reasonable'' algorithm
+that costs $t$ according to the same definitions.
+The formalization challenge is to say exactly what ``reasonable'' means.
+Our core objective here
+is to give a new definition that accurately captures
+what is actually feasible for attackers.
\subheading{Priority dates and credits}
+This accuracy has two sides.
+First, the formally defined set of algorithms must be large enough.
+Security according to the definition does not imply actual security
+if the definition ignores algorithms that are actually feasible.
+Second, the formally defined set of algorithms must be small enough.
+One cannot conjecture security on the basis of cryptanalysis
+if infeasible attacks ignored by cryptanalysts
+are misdeclared to be feasible by the security definition.
+
+We actually analyze four different ideas for modifying the notion of feasibility
+inside existing definitions:
+(1) switching the definitions from the RAM metric used in \cite{2000/bellarecbc}
+to the NAND metric, an ``alternative'' mentioned in \cite{2000/bellarecbc};
+(2) switching the definitions to the $AT$ metric,
+a standard hardwaredesign metric
+formally defined by Brent and Kung in \cite{1981/brentareatime} in 1981;
+(3) adding constructivity to the definitions,
+by a simple trick that we have not seen before (see Appendix~\ref{salvageeffectivity});
+and
+(4) adding uniformity to the definitions.
+Readers unfamiliar with the RAM, NAND, and $AT$ metrics
+should see Appendix~\ref{cost}
+for a summary and pointers to the literature.
+
+Ultimately we recommend the second and third modifications
+as producing much more accurate models of actual feasibility.
+We also recommend refactoring theorems to simplify further changes,
+whether those changes are for even better accuracy or for other reasons.
+We recommend against the first and fourth modifications.
+Full details of our analysis appear in Appendix~\ref{salvage};
+the NAND and $AT$ analyses for individual algorithms
+appear in Sections~\ref{aes}, \ref{ecc}, \ref{dsa}, and \ref{rsa}.
+Appendix~\ref{faq} is a frequentlyaskedquestions list,
+serving a role for this paper
+comparable to the role that a traditional index serves for a book.
+
+These two modifications have several positive consequences.
+Incorrect conjectures in the literature regarding the concrete security
+of primitives such as AES can
+be replaced by quite plausible conjectures using the new definitions.
+Our impression is that
+{\it most\/} of the proof ideas in the literature are compatible with the new definitions,
+modulo quantitative changes,
+so {\it most\/} concretesecurity theorems in the literature can be replaced
+by meaningful concretesecurity theorems using the new definitions.\footnote
+{We do not claim that {\it all\/} proofs can be rescued,
+and it is even possible that some theorems will have to be abandoned entirely.
+Some troublesome examples have been pointed out by Koblitz and Menezes
+in \cite{2012/koblitz} and \cite{2012/koblitznonuniformity}.
+Our experience indicates, however, that such examples are unusual.
+For example, there is nothing troublesome about the CBCMAC proof or the FDH proof;
+these proofs simply need to be placed in a proper framework
+of meaningful definitions, conjectures, and theorem statements.}
+The conjectures and theorems together will produce exactly the desired conclusions
+regarding the concrete security of protocols such as AESCBCMAC.
+
+
+\subheading{Priority dates; credits; new analyses}
On 20 March 2012 we publicly announced the trouble
with the standard AES conjectures;
on 17 April 2012 we publicly announced the trouble
with the standard NIST P256, DSA3072, and RSA3072 conjectures.
The lowprobability case of the AES trouble was observed independently
by Koblitz and Menezes and announced earlier in March 2012;
further credits to Koblitz and Menezes appear in Appendix~\ref{koblitz}.
+further credits to Koblitz and Menezes appear below.
We are not aware of previous publications
disputing the standard concretesecurity conjectures.
@@ 232,11 +315,11 @@
and new algorithm improvements in Sections~\ref{ecc}, \ref{dsa}, and \ref{rsa};
our improvements are critical for beating $2^{128}$ in Section~\ref{rsa}.
In Sections~\ref{aes}, \ref{ecc}, and \ref{dsa}
the previous techniques were already adequate
to disprove the standard $2^{128}$ concretesecurity conjectures,
+the standard techniques were already adequate
+to (heuristically) disprove the standard $2^{128}$ concretesecurity conjectures,
but as far as we know we were the first to point out these contradictions.
We do not think the contradictions were obvious;
in many cases the techniques were published decades {\it before\/} the conjectures!
+in many cases the standard techniques were published decades {\it before\/} the conjectures!
Index: koblitz.tex
===================================================================
 koblitz.tex (revision 87)
+++ koblitz.tex (revision 178)
@@ 1,5 +1,4 @@
\section{Appendix: Credits to Koblitz and Menezes}\label{koblitz}

This paper was triggered by a 23 February 2012 paper \cite{2012/koblitz},
in which Koblitz and Menezes objected to the nonconstructive nature
of Bellare's security proof \cite{2006/bellarehmac} for NMAC.
@@ 35,3 +34,13 @@
between one algorithm cost metric and another,
and we raise the possibility of eliminating the difficulties
by carefully selecting a cost metric.
+
+Readers who find these topics interesting
+may also be interested in the followup paper \cite{2012/koblitznonuniformity},
+especially the detailed discussion in \cite[Section 2]{2012/koblitznonuniformity}
+of ``two examples where the nonuniform model led researchers astray''.
+See also Appendices
+\ref{uniformvsconstructive},
+\ref{nonuniformitypurelyasymptotic},
+and \ref{nonuniformitydefinition}
+of our paper for further comments on the concept of nonuniformity.
Index: aes.tex
===================================================================
 aes.tex (revision 87)
+++ aes.tex (revision 178)
@@ 16,21 +16,32 @@
\subheading{Breaking AES with MD5}\label{aesmd5}
We begin with a lowprobability attack that does not use any precomputations.
+We begin with an attack that does not use any precomputations.
+This attack is feasible, and in fact quite efficient;
+its success probability is low, but not nearly as low as one might initially expect.
+This is a warmup for the highersuccessprobability attack
+of Section~\ref{aesbigprecomp}.
Let $P$ be a uniform random permutation of the set $\setof{0,1}^{128}$.
+Let $P$ be a uniform random permutation of the set $\setof{0,1}^{128}$;
+we label elements of this set in littleendian form as integers $0,1,2,\ldots$
+without further comment.
The pair $(P(0),P(1))$ is nearly a uniform random $256$bit string:
it avoids $2^{128}$ strings of the form $(x,x)$
but is uniformly distributed among the remaining $2^{256}2^{128}$ strings.
If $k$ is a uniform random $128$bit string
then the pair $(\AES_k(0),\AES_k(1))$ is a highly nonuniform random $256$bit string.
+then the pair $(\AES_k(0),\AES_k(1))$ is a highly nonuniform random $256$bit string,
+obviously limited to far fewer than $2^{256}$ possibilities.
One can reasonably guess that
an easy way to distinguish this from $(P(0),P(1))$
+an easy way to distinguish this string from $(P(0),P(1))$
is to feed it through MD5 and inspect the first bit of the result.
The success probability of this attack is far below $1$,
+The success probability of this attack{\dash}%
+the absolute difference between its average output for input $(\AES_k(0),\AES_k(1))$
+and its average output for input $(P(0),P(1))${\dash}%
+is far below $1$,
but it is almost certainly above $2^{80}$,
and therefore many orders of magnitude above $2^{128}$.
+See Appendix~\ref{verif} for relevant computer experiments.
To understand why this works,
imagine replacing the first bit of MD5
@@ 66,7 +77,8 @@
but it would be astonishing for MD5 to interact with AES
in such a way as to spoil this attack.
More likely is that there are some collisions in $k\mapsto (\AES_k(0),\AES_k(1))$;
but any such collisions will tend to push $\delta$ away from $0$, helping the attack.
+but such collisions are rare unless AES is deeply flawed,
+and in any event will tend to push $\delta$ away from $0$, helping the attack.
\subheading{Precomputing larger success probabilities}\label{aesbigprecomp}
@@ 100,11 +112,11 @@
There are $2^{3\cdot 2^{2n}}$ choices of $(3\cdot 2^{2n})$bit strings $s$,
and $2^{3\cdot 2^{2n}}$ is considerably larger than $\exp(2^{2n+1})$,
so presumably at least one of these values of $s$
will have $D_s$ has success probability at least ${\approx}2^{n64}$.
+will have $D_s$ having success probability at least ${\approx}2^{n64}$.
Similar comments apply to essentially any shortkey cipher.
There almost certainly {\it exists\/} a $(3\cdot 2^{2n})$bit string $s$
such that the following simple attack achieves insecurity ${\approx}2^{nK/2}$,
+such that the following simple attack achieves success probability ${\approx}2^{nK/2}$,
where $K$ is the number of bits in the cipher key:
query $2K$ bits of ciphertext, append $s$, and hash the result to $1$ bit.
@@ 114,7 +126,7 @@
It grows more quickly in the $AT$ metric:
storing the $3\cdot 2^{2n}$ bits of $s$ uses area at least $3\cdot 2^{2n}$,
and even a heavily parallelizable hash function
will take time $\Theta(2^n)$ simply to communicate across this area,
+will take time proportional to $2^n$ simply to communicate across this area,
for a total cost proportional to $2^{3n}$.
In each metric there are also lowerorder terms
reflecting the cost of hashing per bit;
@@ 123,10 +135,9 @@
\subheading{Iteration}\label{aesiteration}
High levels of insecurity are more efficiently achieved
+Large success probabilities are more efficiently achieved
by a different type of attack that iterates, e.g.,
the function $f_7:\setof{0,1}^{128}\to\setof{0,1}^{128}$ defined by $f_7(k)=\AES_k(0)\oplus 7$,
where $7$ is represented in littleendian binary form.
+the function $f_7:\setof{0,1}^{128}\to\setof{0,1}^{128}$ defined by $f_7(k)=\AES_k(0)\oplus 7$.
Choose an attack parameter $n$.
Starting from $f_7(k)$,
@@ 144,9 +155,9 @@
etc.
If $n$ is not too large (see the next paragraph)
then there are close to $2^{2n}$ different keys here.
The computation involves $\le 2^n$ initial iterations;
+The computation involves ${\le}2^n$ initial iterations;
$2^n$ table lookups;
and, in case of a match, $\le 2^n$ iterations to recompute $f_7^{2^nj}(i)$.
+and, in case of a match, ${\le}2^n$ iterations to recompute $f_7^{2^nj}(i)$.
The {\it precomputation\/} performs many more iterations,
but this precomputation is only the cost of {\it finding\/} the algorithm,
not the cost of {\it running\/} the algorithm.
@@ 216,8 +227,8 @@
the precomputation covers $2^{2n}U$ keys instead of just $2^{2n}$ keys.
To avoid excessive chain collisions one must limit $2^n$
to $2^{K/3}U^{1/3}$;
the attack then finds each key with probability $2^{K/3}U^{1/3}$,
with a cost of $2^{K/3}U^{1/3}$ per key,
+the attack then finds each key with probability $2^{2n}U/2^K=2^{K/3}U^{1/3}$,
+with a cost of $2^n=2^{K/3}U^{1/3}$ per key,
a factor of $U^{2/3}$ better than handling each key separately.
Finding each key with high probability costs $2^{2K/3}U^{2/3}$ per key.
@@ 228,14 +239,16 @@
taking time on the scale of $2^n$,
but the $2^n U$ precomputed keys occupy area $2^n U$,
for a total cost on the scale of $2^{2n} U$,
i.e., $2^{2n}$ per key.
Precomputation again has only a small benefit.
There is still a benefit in success probability from handling $U$ keys together:
achieving success probability $p$ costs essentially $(2^K/U)p$.
+i.e., $2^{2n}$ per key, for success probability $2^{2n}U/2^K$ per key.
+Note that one can carry out the precomputation
+using essentially the same area and time.
+There is a large benefit from handling $U$ keys together{\dash}%
+finding all $U$ keys costs essentially $2^K$, i.e., $2^K/U$ per key{\dash}%
+but this benefit exists whether or not precomputation costs are taken into account.
\subheading{Comparison}
We summarize the insecurity established by the best attacks discussed above.
+We summarize the insecurity established by the best attacks presented above.
Achieving success probability $p$ against $U$ keys costs
\begin{itemize}
\item
@@ 265,21 +278,22 @@
\cite[Section 3.6]{2005/bellareintro} and \cite[Section 3.2]{2006/bellarehmac}
were made, they were already inconsistent with known attacks.
The iteration idea was introduced by Hellman in \cite{1980/hellman} for the special case $U=1$.
+The iteration idea
+was introduced by Hellman in \cite{1980/hellman} for the special case $U=1$.
Many subsequent papers have explored variants and refinements of Hellman's attack,
including the easy generalization to larger $U$.
Hellman's goal was to attack many keys
for a lower cost than attacking each key separately;
+for a lower RAM cost than attacking each key separately;
Hellman advertised a ``cost per solution'' of $2^{2K/3}$
using a precomputed table of size $2^{2K/3}$.
The generalization to larger $U$ achieves the same goal at lower cost,
but the special case $U=1$ remains of interest as a nonuniform singlekey attack.
Koblitz and Menezes in \cite{2012/koblitz}
recently considered the family of attacks $D_s$.
+recently considered a family of attacks analogous to $D_s$.
They explained that there should be
a short string $s$ where $D_s$ has success probability at least $\approx 2^{K/2}$,
and analyzed the consequences for provable concrete secretkey security.
+and analyzed some consequences for provable concrete secretkey security.
However, they did not analyze higher levels of insecurity.
Replacing $D_s$ with a more structured family of attacks,
@@ 288,14 +302,14 @@
(See, for example,
\cite[Section 7]{2009/dodismac},
which says that this is ``well known in complexity theory''.)
De, Trevisan, and Tulsiani in \cite{2009/de}
+De, Trevisan, and Tulsiani in \cite{2010/de}
proved cost ${\approx}2^K p^2$, for both the RAM metric and the NAND metric,
for any insecurity level $p$.
A lucid discussion of the gap between these attacks and exhaustive search
appears in \cite[Section 1]{2009/de},
but without any discussion of the resulting trouble
+appears in \cite[Section 1]{2010/de},
+but without any analysis of the resulting trouble
for the literature on provable concrete secretkey security,
and without any discussion of possible fixes.
+and without any analysis of possible fixes.
Biham, Goren, and Ishai in \cite[Section 1.1]{2008/bihamweak}
pointed out that Hellman's attack
Index: ecc.tex
===================================================================
 ecc.tex (revision 87)
+++ ecc.tex (revision 178)
@@ 14,6 +14,8 @@
a hyperelliptic curve,
a torus,
etc.)~does not stop the attack.
+We focus on NIST P256 for both concreteness and practical relevance,
+as in the previous section.
@@ 102,6 +104,9 @@
observe that each new step has chance $2^{t}$ of reaching a distinguished point,
and chance $O(2^{2t}/\ell)=O(2^{t})$ of reaching one
of the previous $O(2^{2t})$ points represented by the database.
+Computer experiments reported in \cite{2012/bernsteincuberoot},
+as a followup to this paper,
+show that all the $O$ constants here are reasonably close to $1$.
Now consider a walk starting from $aP+bQ$.
This walk has chance approximately $1/e$ of continuing for at least $2^t$ steps.
@@ 166,9 +171,13 @@
None of these papers noticed any implications for provable security,
and none of them went beyond the RAM metric.
After we released a preprint of this paper in June 2012,
a followup paper \cite{2012/bernsteincuberoot} by Bernstein and Lange
experimentally verified our algorithm,
+experimentally verified the algorithm stated above,
improved it to $1.77\cdot \sqrt[3]{\ell}$ additions using $\sqrt[3]{\ell}$ distinguished points,
extended it to DLPs in intervals (using slightly more additions),
and showed constructive applications in various protocols.
Index: dsa.tex
===================================================================
 dsa.tex (revision 87)
+++ dsa.tex (revision 178)
@@ 44,7 +44,7 @@
The same is true for $h_2$;
overall the attack requires between $2^{107.85}$ and $2^{108.85}$ iterations,
depending on $2^{3071}/p$.
Batch trial division, discussed in detail in Section~\ref{rsa},
+Batch trial division, analyzed in detail in Section~\ref{rsa},
finds the $y$smooth values among many choices of $h_1$
at very low cost in both the RAM metric and the NAND metric.
This attack is much slower in the $AT$ metric.
Index: rsa.tex
===================================================================
 rsa.tex (revision 87)
+++ rsa.tex (revision 178)
@@ 37,7 +37,7 @@
For example,
with parameters $m=2^{256}$, $d=7$, $H=2^{55}$, and $y=2^{50}$,
the attack factors integers between $2^{1792}$ and $2^{2048}$.
Parameter selection is discussed later in more detail.
+Parameter selection is analyzed later in more detail.
The following three paragraphs explain how the attack handles $N$.
Write $N$ in radix $m$:
@@ 55,7 +55,7 @@
to emphasize two important ways that this attack differs from conventional NFS:
first, conventional NFS chooses $m$ as a function of $N$, while this attack does not;
second,
conventional NFS computes $R$ by sieving all pairs $(a,b)$
+conventional NFS computes $R$ by sieving all pairs $(a,b)$ with $H\le a\le H$ and $0:<0cm,0.007cm>::
+\xy <0.009cm,0cm>:<0cm,0.009cm>::
(600,0)="origin";
(650,0) *{\llap{\strut $1$}};
+(650,150) *{\llap{\strut $2^{K/4}$}};
+(600,150) *{+};
+(650,300) *{\llap{\strut $2^{K/2}$}};
+(600,300) *{+};
+(650,450) *{\llap{\strut $2^{3K/4}$}};
+(600,450) *{+};
(650,600) *{\llap{\strut $2^K$}};
(650,300) *{\llap{\strut \txt{Cost}}};
+(850,300) *{\llap{\strut \txt{Cost}}};
(600,600)="yaxis";
(600,50) *{\strut \txt{$1/2^K$}};
+(600,50) *{\strut \txt{$2^{K}$}};
+(450,0) *{+};
+(450,50) *{\strut \txt{$2^{3K/4}$}};
+(300,0) *{+};
+(300,50) *{\strut \txt{$2^{K/2}$}};
+(150,0) *{+};
+(150,50) *{\strut \txt{$2^{K/4}$}};
(0,50) *{\strut \txt{$1$}};
(0,0)="xaxis";
(300,50) *{\strut \txt{Success probability}};
+(300,150) *{\strut \txt{Success probability}};
"origin"; "yaxis" **@{};
"origin"; "xaxis" **@{};
(600,0); (0,600) **[green]@{};
@@ 37,24 +51,31 @@
\label{aesgraph}
\end{figure}

\begin{figure}[h]
$$\vbox{
\xy <0.007cm,0cm>:<0cm,0.007cm>::
(600,0)="origin";
(650,0) *{\llap{\strut $1$}};
(650,300) *{\llap{\strut $\sqrt{\ell}$}};
(650,150) *{\llap{\strut \txt{Cost}}};
(600,300)="yaxis";
(600,50) *{\strut \txt{$1/\ell$}};
(0,50) *{\strut \txt{$1$}};
(0,0)="xaxis";
(300,50) *{\strut \txt{Success probability}};
+\xy <0.009cm,0cm>:<0cm,0.009cm>::
+(0,0)="origin";
+(50,0) *{\llap{\strut $1$}};
+(50,150) *{\llap{\strut $\ell^{1/4}$}};
+(0,150) *{+};
+(50,300) *{\llap{\strut $\ell^{1/2}$}};
+(250,150) *{\llap{\strut \txt{Cost}}};
+(0,300)="yaxis";
+(0,50) *{\strut \txt{$\ell^{1}$}};
+(150,50) *{\strut \txt{$\ell^{3/4}$}};
+(150,0) *{+};
+(300,50) *{\strut \txt{$\ell^{1/2}$}};
+(300,0) *{+};
+(450,50) *{\strut \txt{$\ell^{1/4}$}};
+(450,0) *{+};
+(600,50) *{\strut \txt{$1$}};
+(600,0)="xaxis";
+(300,150) *{\strut \txt{Success probability}};
"origin"; "yaxis" **@{};
"origin"; "xaxis" **@{};
(600,0); (0,200) **[red]@{};
(600,0); (0,300) **[blue]@{};
+"origin"; (600,200) **[red]@{};
+"origin"; (600,300) **[blue]@{};
\endxy
}$$
\caption{Cost summary of discretelogarithm attacks for a group of size $\ell$.
@@ 69,3 +90,4 @@
}
\label{eccgraph}
\end{figure}
+
Index: literature.tex
===================================================================
 literature.tex (revision 0)
+++ literature.tex (revision 178)
@@ 0,0 +1,152 @@
+\setcounter{section}{11}
+
+\section{Appendix: Literature samples
+}\label{literature}
+
+To collect data regarding standard practice
+in the literature on provable concrete security,
+we scanned the proceedings of Crypto 2012,
+searching for concrete security definitions and claims of provable concrete security.
+This appendix reports the results of this scan.
+
+Most of the ``provable security'' papers
+do {\it not\/} prove anything about concrete security.
+Some use informationtheoretic security notions
+that cannot be broken by any amount of attacker computation;
+the majority use purely asymptotic security notions
+such as ``every probabilistic polynomialtime adversary
+has negligible success probability''.
+
+There are, however, five provableconcretesecurity papers.
+Each of these five papers
+explicitly claims to ``show'' or ``prove'' or ``guarantee''
+bounds that involve the ``security'' (or ``insecurity'' or ``Adv'')
+of some cryptographic systems.
+Proving such bounds
+obviously requires a quantitative definition of the ``security'' of a system;
+the central question here is what definitions the papers are actually using.
+
+Inspection of these papers{\dash}see below for details{\dash}%
+suggests that it is completely standard to use definitions
+that express exactly the following situation:
+there does not exist an algorithm that
+breaks the system with probability above $\epsilon$
+while satisfying specified limits on ``time'', queries, etc.
+{\it None\/} of the five papers deviate from this standard.
+Three of the papers explicitly state new definitions
+that follow this standard.
+The other two papers use a classic special case,
+namely PRP ``security'', without defining it;
+after many years of papers repeating the same definition of PRP ``security''{\dash}a
+settled definition that also follows this standard{\dash}%
+the reader is forced to assume that these two papers are also using that definition.
+
+\subheading{Details}
+The five papers are as follows,
+in the same order that they appear on Springer's web site.
+
+Jager, Kohlar, Sch\"age, and Schwenk in \cite{2012/jager}
+give a ``formal proof that [one version of TLSDHE] is a secure authenticated
+key exchange protocol'',
+define ``the notion of authenticated and confidential
+channel establishment'',
+and prove that a particular protocol
+``forms a secure ACCE protocol''.
+\cite[Definition 2]{2012/jager}
+defines an encryption scheme to be $(t,\epsilon)$``secure''
+if ``all adversaries $A$ running in time at most $t$''
+have success probability at most $\epsilon$;
+similar definitions continue throughout the paper.
+\cite[Theorem 1]{2012/jager}
+assumes that various primitives are $(t,\epsilon)$``secure''
+and concludes that ``any adversary'' that $(t',\epsilon')$breaks a particular protocol
+with ``$t\approx t'$'' must have $\epsilon'\le\cdots$.
+This is trivially equivalent to a conclusion that the protocol is $(t',\epsilon')$``secure''
+under the definitions in the paper.
+
+Bellare, Ristenpart, and Tessaro in \cite[Section 2]{2012/bellaremultiinstance}
+define a ``$(t,q,q_c)$adversary''
+as an algorithm that ``runs in time $t$ and makes at most $q[i]$ encryption queries
+of the form $\cdots$ and makes at most $q_c$ corruption queries''
+and then define $\Adv^{{\rm uku}}_{{\rm SE},m}(t,q,q_c)$
+as the maximum advantage among ``all $(t,q,q_c)$adversaries''.
+\cite[Theorem 1]{2012/bellaremultiinstance}
+bounds ``$\Adv^{{\rm uku}}_{{\rm SE},m}(t,q,q_c)$''
+relative to another similarly defined insecurity function.
+
+Hoang, Morris, and Rogaway in \cite[Section 4]{2012/hoang}
+briefly discuss the ``complexitytheoretic interpretation''
+of an informationtheoretic result.
+They do not state a formal theorem
+but they say that ``the PRPsecurity of $E$ is the PRFsecurity of $F$ minus [something small]''.
+The paper neither gives nor cites a definition of ``the PRPsecurity of $E$'',
+so (as above) the reader is forced to assume
+that the paper reuses the definition given in many previous papers,
+referring to a low success probability of all algorithms
+subject to specified limits on time and queries.
+Similar comments apply to \cite[Section 5]{2012/hoang},
+which asserts that one is ``guaranteed''
+that attacks have a success probability of ``less than $10^{10}$''
+plus the ``insecurity'' of AES.
+
+Landecker, Shrimpton, and Terashima in \cite[page 16]{2012/landecker}
+say that ``the bulk of the paper is dedicated to showing that''
+the proposed ``CLRW2 TBC'' is ``a strong tweakablePRP'' under various hypotheses,
+one hypothesis being that the underlying cipher $E$ ``is a secure strongPRP''.
+The paper neither gives nor cites a definition of ``secure strongPRP'',
+so (as above) the reader is again forced to assume the standard definition.
+This assumption is consistent with the formulation of
+the ``main technical result'' of the paper, \cite[Theorem 1]{2012/landecker},
+which hypothesizes that $A$ is ``an adversary asking a total of $q$ queries to its oracles,
+these of total length $\mu$, and running in time $t$',
+and concludes that ``there exists an adversary $B$ using the same resources''
+whose success probability has a particular lower bound
+in terms of the success probability of $A$.
+The {\it existence\/} of an algorithm with specified success probability, time, etc.~is
+exactly what is logically required to prove insecurity under the standard definition.
+
+Hofheinz and Jager in \cite[Theorem 5]{2012/hofheinz}
+state, under various hypotheses,
+that a particular system is ``$(\epsilon,t,\mu,q)$INDCCA secure''.
+This means, by \cite[Definition 5]{2012/hofheinz},
+that ``there exists no adversary''
+that $(\epsilon,t)$breaks the $(\mu,q)$INDCCA security of the system,
+i.e., there exists no adversary ``that runs in time $t$ and wins with probability $1/2+\epsilon$''
+using $\mu$ public keys and $q$ queries.
+
+\subheading{Controversy}
+An earlier version of this paper, predating the scan described in this appendix,
+had already asserted that such definitions are completely standard.
+This assertion was based on what we had seen in many papers over many years,
+and we did not expect it to be controversial.
+In response we encountered
+a puzzling claim that such definitions are ``not widespread'' and that, as a result,
+most provableconcretesecurity papers do not fall into the gaps that we have identified.
+
+It was of course possible that our earlier selection of papers was biased by our own interests,
+but this new literature sample has no obvious bias
+and makes the ``not widespread'' claim quite difficult to believe.
+If such definitions are ``not widespread''
+then why are they used in all five
+of the provableconcretesecurity papers at a recent IACR flagship conference{\dash}%
+papers from
+Bellare,
+Hoang,
+Hofheinz,
+Jager,
+Kohlar,
+Landecker,
+Morris,
+Ristenpart,
+Rogaway,
+Sch\"age,
+Schwenk,
+Shrimpton,
+Terashima,
+and
+Tessaro?
+It is of course {\it still\/} possible that these five papers
+are not representative of
+standard practice in the literature as a whole,
+but we think that anyone making such a claim
+is required to supply a considerable volume of evidence.
Index: faq.tex
===================================================================
 faq.tex (revision 87)
+++ faq.tex (revision 178)
@@ 1,6 +1,7 @@
\setcounter{section}{16}
\section{Appendix: Frequently asked questions}\label{faq}
+\section{Appendix: Frequently asked questions
+}\label{faq}
This appendix answers several questions that we have been asked
regarding this paper.
@@ 9,12 +10,12 @@
\subheadingnodot{In the real world, an attack is applied to many targets.
Doesn't this make the precomputation effectively free?}
No, not in general.
The fallacy here is addressed in Section \ref{salvage}.1.1.
+The fallacy here is addressed in Appendix \ref{salvage}.1.1.
\subheadingnodot{Aren't we simply making the user safer
if we underestimate attack cost by ignoring precomputation?}
No.
The fallacy here is addressed in Section \ref{salvage}.1.2.
+The fallacy here is addressed in Appendix \ref{salvage}.1.2.
\subheadingnodot{Why are you analyzing the cost of precomputation in these attacks?
Didn't you just say that this cost is irrelevant to the security definitions?}
@@ 23,8 +24,12 @@
and $2^{170}$ for the NIST P256 attack)
is critical for understanding the realworld inapplicability of the attacks.
We recommend fixing the security definitions to take this cost into account;
see Sections~\ref{salvageeffectivity} and \ref{salvagerecommendations}.
+see Appendices~\ref{salvageeffectivity} and \ref{salvagerecommendations}.
+\subheadingnodot{I don't understand how MD5 could possibly break AES. Are you sure?}
+Yes. The analysis is easy, using standard heuristics,
+and is backed by the computer experiments reported in Appendix~\ref{verif}.
+
\subheadingnodot{If one special precomputation is enough
to completely break AES,
isn't that serious enough that the metric should capture it?}
@@ 33,50 +38,148 @@
But the difficulty of carrying out the precomputation is also important,
and is ignored in the standard security definitions.
We propose taking all of these features into account.
See Section \ref{salvagerecommendations}.
+See Appendix \ref{salvagerecommendations}.
\subheadingnodot{ What... is the airspeed velocity of an unladen swallow?}
What do you mean? An African or European swallow?
+\subheadingnodot{Sorting costs $n\log_2 n$. How can you take a metric seriously if it says that sorting costs $n^{1.5}$?}
+The best reported results for the energy consumption of sorting \cite{2012/nybergsortbenchmark}
+are 43700 items sorted per joule for $10^{10}$ 100byte items,
+and 9700 items sorted per joule for $10^{12}$ 100byte items.
+The ratio $43700/9700$ is $4.5$,
+and the chip evolution reviewed in Appendix~\ref{costat}
+can be expected to improve the small sort by a larger factor than the large sort,
+pushing the ratio up towards $10$.
+For comparison,
+the ratio $(\log_2 10^{12})/(\log_2 10^{10})$ is only $1.2$,
+obviously understating the heavy communication costs of sorting.
+See \cite{1995/bilardi} for a more detailed analysis
+of physical constraints upon algorithm performance.
+\subheadingnodot{I spend time $A$ setting up my area$A$ hardware,
+plus time $T$ waiting for the results.
+Isn't $A+T$ my actual cost?}
+If you have $n$ processing cores, each carrying out a series of $n$ separate computations,
+then you have carried out $n^2$ computations and used energy proportional to $n^2$,
+but $A+T$ is only linear in $n$.
+The RAM metric avoids this pathology
+by imposing an unrealistic prohibition upon parallel computations,
+but it falls prey to other pathologies.
+
\subheadingnodot{Isn't your $AT$ metric simply a reinvention of Wiener's fullcost metric?}
It's not {\it our\/} $AT$ metric.
The $AT$ metric has decades of history in algorithm analysis,
and more than a decade of history in cryptanalytic algorithm analysis;
see, e.g., \cite{1981/brentareatime} and \cite{2001/bernsteinnfscircuit}.
Wiener's 2004 fullcost metric
appears to be equivalent to the $VT$ metric analyzed in, e.g.,
Preparata's 1983 paper \cite{1983/preparata}.
+Wiener's 2004 fullcost metric \cite{2004/wienerfullcost}
+appears to be equivalent to the $VT$ metric analyzed in the 1983 papers
+\cite{1983/rosenberg} and \cite{1983/preparata}.
+See \ref{faq3d} for further analysis of $VT$.
\subheadingnodot{The world is threedimensional! Isn't $VT$ a more realistic metric than $AT$?}
+\label{faq3d}
The world is threedimensional,
but power consumption and heat dissipation are twodimensional.
A modern billiontransistor CPU is much more like a $32000\times 32000$ square
+A modern billiontransistor CPU is much more like a $32768\times 32768$ square
than a $1024\times 1024\times 1024$ cube;
``threedimensional'' manufacturing technology is limited to a small number of layers.
+``threedimensional'' manufacturing technology is limited to a small number of layers
+(e.g., a flat $4\times 16384\times 16384$ box).
Similarly, a ``threedimensional'' computer cluster
actually provides orders of magnitude faster communication
within twodimensional chips than it does between chips.
+
At a larger scale,
each square meter of the earth's atmosphere receives at most $1361$ watts from the sun,
+each square meter of the Earth's atmosphere receives at most $1361$ watts from the Sun,
so one cannot hope to sustain an $A$squaremeter computer
that consumes more than $1361A$ watts,
no matter what the computer technology is.
Shifting energy through time, as illustrated by oil drilling,
can temporarily violate this maximum but evidently is not sustainable;
similar comments apply to shifting energy around the earth's surface.
+A threedimensional $VT$optimized computer
+does not have enough surface area to receive and dissipate the energy it uses,
+and if one tries to ``spread it out'' to give room for more energy
+then one ends up with $VT$ cost matching $AT$ cost.
+One might argue that it is possible to temporarily violate the $1361A$ maximum
+by shifting energy through time, as illustrated by oil drilling,
+or similarly by shifting energy around the Earth's surface,
+but this argument ignores the energy cost of the shifting mechanisms.
\subheadingnodot{Have you considered constructivity?}
Yes. Constructivity is another name for effectivity,
which is analyzed in Section~\ref{salvageeffectivity}.
We recommend a specific strategy for incorporating effectivity into security definitions.
+Furthermore,
+threedimensional designs pose severe {\it temperature\/} problems
+even if enough energy magically becomes available at the surface of the computer.
+Increasing the size of a $VT$optimized design,
+while still providing the energy needed for each bit operation,
+requires a corresponding increase in
+the amount of power that passes from the surface {\it through\/} each point of the design.
+This is incompatible with the temperature limits
+that are needed for adequate error correction
+in any physical system for computation.
+This is true even for limited threedimensional systems
+that use only one layer for transistors and the rest for wires:
+wires require energy proportional to their length.
\subheadingnodot{When you say that the algorithms are nonuniform, aren't you really trying to say that the algorithms are nonconstructive?}
Almost all of the algorithms we discuss are nonuniform:
they require different precomputations for different targets.
Almost all of the algorithms we discuss are {\it also\/} nonconstructive.
These are not the same concept.
+We have checked that the $AT$ analyses of highprobability attacks in this paper
+would produce the same results if $AT$ were replaced by $VT$,
+so the criterion of avoiding these ``pathologies'' is equally served by $AT$ and by $VT$,
+but $AT$ is much more accurate in modeling physical reality.
\subheadingnodot{Isn't ``nonuniformity'' a purely asymptotic concept?}
+\subheadingnodot{Doesn't the physical reality actually say that each computation is $O(1)$?}
+Quite possibly, yes.
+We recommend Aaronson's exposition in \cite{2006/aaronson}
+of a physics argument concluding that the
+``maximum number of bits that could ever be used in a computation in the physical world''
+is about $10^{122}$, inversely proportional to the cosmological constant.
+The two major steps in the argument are as follows.
+First, trying to pack information too densely
+would violate the BekensteinHawking bound (see, e.g., \cite{1981/bekenstein}),
+which states that the entropy inside a spherical region of space
+is at most $1/4$ of the surface area (not volume) of the region measured in Planck units.
+Second, as observed by Bousso in \cite{2000/bousso},
+information located too far away
+is forced by the nonzero cosmological constant
+to accelerate away so quickly as to become unobservable.
+
+This bound on the number of bits used by a computation
+implies that every terminating physical computation
+has overwhelming probability of terminating
+within a particular constant number of bit operations.
+Standard asymptotic complexity classes
+such as P, BPP, BQP, etc.~have no logical connection to such short computations.
+Aaronson's only suggestions for allowing
+a physical realization of the standard complexity classes
+are to switch to an imaginary alternate universe in which the cosmological constant is zero,
+or a sequence of imaginary alternate universes with cosmological constant converging to zero.
+
+Fortunately,
+these asymptotic issues
+also have no logical connection to concrete security questions
+such as the security of AES128, NIST P256, DSA3072, and RSA3072.
+This paper focuses almost exclusively on concrete security questions,
+with asymptotics appearing only occasionally as inspiration.
+For example,
+Section~\ref{rsaasymp} briefly analyzes the asymptotics of one algorithm,
+but this is merely a warmup
+for the concrete analysis of the same algorithm in Section~\ref{rsaconcrete}.
+
+
+\subheadingnodot{What{\ldots} is the airspeed velocity of an unladen swallow?}
+What do you mean? An African or European swallow?
+
+\subheadingnodot{Have you considered effectivity?}
+Yes. Effectivity is another name for constructivity,
+which is analyzed in Appendix~\ref{salvageeffectivity}.
+We recommend a specific strategy (which appears to be new)
+for incorporating a quantitative form of constructivity into security definitions.
+
+\subheadingnodot{When you say that the algorithms are nonuniform, aren't you really trying to
+say that the algorithms are nonconstructive?}\label{uniformvsconstructive}
+Almost all of the algorithms we present are nonuniform:
+for example, the RSA attack requires different precomputations
+for sufficiently different modulus sizes,
+and the ECC attack requires different precomputations for different curves.
+Almost all of the algorithms we present are {\it also\/} nonconstructive,
+i.e., very hard to find;
+see Appendix~\ref{salvageeffectivity} for a quantitative formalization of this intuition.
+Nonuniformity and nonconstructivity are not the same concept.
+
+\subheadingnodot{Isn't ``nonuniformity'' a purely asymptotic
+concept?}\label{nonuniformitypurelyasymptotic}
No.
Consider, for example, a theorem proving that for each $512$bit string $s$
there is a fast algorithm $A$ that,
@@ 85,19 +188,55 @@
Consider a stronger theorem proving that there is a fast algorithm $A$ that,
given $512$bit strings $s$ and $t$ as input,
prints collisions in the $512$bitto$128$bit function $x\mapsto \MDfive(s,t,x)$.
The difference betwen these theorems
+The difference between these theorems
is precisely in the amount of uniformity imposed on $A$.
There are no asymptotics here.
\subheadingnodot{I see books defining ``nonuniform'' algorithms
specifically as families of circuits, one circuit for each input size.
Isn't this definition completely standard?}
This is one type of nonuniformity but not the only type;
one can partition inputs by size but one can also partition inputs in many other ways.
Consider, for example,
Shor's discussion in \cite[Section 2]{2001/shor} of the ``additional uniformity condition''
required to define the complexity class BQP.
+\subheadingnodot{My favorite textbook defines ``nonuniform'' algorithms
+specifically as families of polynomialsize circuits, one circuit for each input size,
+and defines ``uniform'' algorithms specifically as polynomialtime algorithms.
+Aren't these definitions completely standard?}\label{nonuniformitydefinition}
+Yes, these are two quite standard uses of the word ``uniform'',
+and often the only uses described in introductory textbooks,
+the same way that many introductory mathematics textbooks define ``small''
+as comparing real numbers in the usual ordering.
+However,
+the complexity literature actually uses the name ``uniform''
+for a much wider range of definitions,
+the same way that the mathematics literature uses ``small''
+for a much wider range of definitions.
+Example 1:
+Consider Goldreich's discussion in \cite{2009/goldreich}
+of the ``amount of nonuniformity'' in a circuit family.
+This is a quantitative metric (the length of an advice string),
+easily capturing the introductory notions of ``uniform'' (advice limited to 0)
+and ``nonuniform'' (no limit on the advice)
+but also allowing analysis of intermediate amounts of uniformity.
+
+Example 2:
+Consider Katz's discussion in \cite{2011/katz}
+of ``logspaceuniform'' families of circuits.
+Compared to the introductory polytimeuniform concept,
+logspaceuniform restricts nonuniformity in another dimension,
+different from the length of an advice string.
+
+Example 3:
+Consider Shor's discussion in \cite[Section 2]{2001/shor}
+of the ``additional uniformity condition''
+used to define the complexity class BQP:
+a condition on families of real numbers used as constants in algorithms,
+yet another dimension of uniformity.
+
+Example 4:
+Consider Koiran's comment in \cite[Section 6]{2007/koiran}
+that the ``only difference between VPSPACE$^0$ and uniform VPSPACE$^0$
+is the nonuniformity of the coefficient function;
+VPSPACE is even more nonuniform since arbitrary constants are allowed''.
+
+\subheadingnodot{?} 42.
+
\subheadingnodot{Isn't the hashing attack in Section~\ref{aes}
outperformed by the linearcryptanalysis approach of De, Trevisan, and Tulsiani?}
No.
@@ 128,29 +267,92 @@
\cite[Section 3.6]{2005/bellareintro},
\cite[Section 3.2]{2006/bellarehmac},
etc.
+Rogaway begins \cite{2006/rogaway} by describing ``The FoundationsofHashing Dilemma''
+with no indication that the dilemma extends beyond hashing.
+\subheadingnodot{These AES128 and NIST P256 and DSA3072 and RSA3072 issues
+are just quantitative, right?}
+Yes, they're ``just'' quantitative,
+but getting the quantitative details right has always been a major theme of
+the concretesecurity literature.
+This paper is aiming at large gaps that affect wide portions of the literature;
+for comparison,
+the gaps in many wellknown ``tightness'' papers
+are quantitatively smaller and apply to much narrower portions of the literature.
+
+Bellare, Desai, Jokipii, and Rogaway wrote in \cite{1997/bellareconcrete}
+that when reductions are loose
+``one must use a larger security parameter to be safe, reducing efficiency.
+Thus, in the end, one pays for inefficient reductions in either assurance or running time.''
+Our attacks against AES128, NIST P256, et al.~show that there is an even larger loss of
+``either assurance or running time'' from a flaw in the standard security definitions:
+specifically, an inaccurate model of the set of algorithms available to the attacker.
+
+\subheadingnodot{Doesn't Rogaway's ``human ignorance'' model already solve these definitional problems?}
+No.
+Stinson in \cite{2001/stinson} proposed studying explicit hashfunction reductions
+as a workaround for the difficulties of defining collision resistance,
+and Rogaway in \cite{2006/rogaway} gave examples of nontrivial theorems following this proposal;
+in Appendix~\ref{salvagerecommendations} we review these proposals
+and recommend further modularization of such theorems.
+However, this line of work
+does nothing to solve the problem of finding a realistic formalization of the statement
+``SHA512 is collisionresistant''{\dash}a problem that remains unsolved today
+(but see Appendix~\ref{salvageeffectivity}).
+Similarly, this line of work
+ does nothing to solve the problem of finding a realistic formalization of statements such as
+``NIST P256 is secure''{\dash}a problem that was incorrectly believed
+to be solved many years ago and that is shown in this paper to be much more subtle.
+
+\subheadingnodot{Are you saying that the $AT$ metric fixes everything?}
+No.
+Appendix~\ref{salvageat} evaluates switching to the $AT$ metric;
+our analyses suggest that this switch fixes essentially all pathologies
+{\it except\/} in one corner case.
+Appendix~\ref{salvageeffectivity} evaluates adding constructivity;
+our analyses suggest that this fixes some corner pathologies.
+Appendix~\ref{salvagerecommendations} recommends both of these changes,
+and also recommends modularizing theorems to accommodate further changes.
+
\subheadingnodot{Are you seriously suggesting
redoing all the security definitions and proofs in the literature
to use effectivity and the $AT$ metric?}
+to use constructivity and the $AT$ metric?}\label{faqseriously}
Yes.
A few theorems are already factored
in the way we recommend in Section~\ref{salvagerecommendations},
+in the way we recommend in Appendix~\ref{salvagerecommendations},
but the vast majority of definitions and theorems require new work.
Tightness will often change dramatically
(see, e.g., the repeatedqueries discussion in Section~\ref{salvagenand}),
and it is important to actually do the work for each theorem
so that users know what security guarantees they are actually being provided.
Some proofs,
such as the ``coinfixing'' proofs criticized in \cite{2012/koblitz},
will not survive the transition.
+will not survive the transition to constructivity.
+Our impression is that most proofs in the literature are constructive,
+but tightness will often change dramatically
+(see, e.g., the comments on repeated queries in Appendix~\ref{salvagenand}),
+imposing surprisingly small limits on the number of queries that can be tolerated
+before a proof becomes vacuous
+and raising the question of whether there are tighter proof strategies.
+If a proof {\it has\/} been checked
+then the best way to record this fact is as a new theorem,
+so that users know what security guarantees they are actually being provided.
+\subheadingnodot{Can't we just assume that $AT$ theorems will look the same as current theorems?}
+No.
+See \ref{faqseriously}.
+\subheadingnodot{Can't we just assume that constructive theorems will look the same as current theorems?}
+No, not always.
+See \ref{faqseriously}.
+
+\subheadingnodot{How do you expect authors to learn how to do $AT$ algorithm analyses?}
+The $AT$ metric is used in thousands of papers.
+We recommend the classic paper \cite{1981/brentareatime} for definitions
+and for illustrative algorithmanalysis examples.
+
\subheadingnodot{Isn't it inappropriate to switch definitions and start writing papers
using the new definitions?}
There are ample precedents for this.
For example,
Newtonian physics was replaced when it was discovered to be a poor model of reality.
We briefly discuss a much closer example from mathematics.
+We briefly review a much closer example from mathematics.
In the 19th century,
Kronecker questioned the significance of proofs of existence that are not {\it effective},
@@ 158,7 +360,8 @@
The classic example is the BolzanoWeierstrass theorem,
which states that an infinite sequence of real numbers $x_0,x_1,\ldots\in[0,1]$
(more generally, a sequence of elements of a compact topological space)
has an infinite subsequence that converges.
The critical observation in the usual proof is
that there must be infinitely many $i$ with $x_i\in [0,0.5]$,
@@ 181,9 +384,18 @@
However, the introduction of ``constructive mathematics''
showed that one {\it can\/} formalize mathematics in a way that
gives different meanings to these two notions,
disallowing the BolzanoWeierstrass proof
+disallowing the BolzanoWeierstrass proof (and theorem)
while preserving more explicit mathematical proofs.
This is part of the background for our quantitative approach to effectivity.
+This is part of the background for our quantitative approach to constructivity.

\subheadingnodot{?} 42.
+\subheadingnodot{I told you $X$ in my last review. Why didn't you change your paper?}
+Chances are excellent that we did add something to our paper in response to your review,
+either to comment positively on $X$ or to explain why $X$ is incorrect.
+In many cases we've added FAQ entries
+to help you find the answer.
+If you still haven't found the answer,
+please look for comments on your review in the following anonymous web page:
+\showurl{http://pastebin.com/BxQkkq6y}
Index: verif.tex
===================================================================
 verif.tex (revision 0)
+++ verif.tex (revision 178)
@@ 0,0 +1,115 @@
+\setcounter{section}{21}
+
+\section{Appendix: Verification that MD5 breaks AES}\label{verif}
+
+For each $8$bit string $k$
+define $E_k(p)=\AES_{k,0}(p)$,
+where $k,0$ means $k$ zeropadded to $128$ bits.
+This cipher $E$ is a scaleddown version of AES.
+
+Consider the following very fast attack,
+a scaleddown version of the simple attack described in Section~\ref{aesmd5}:
+take $16$ bits of ciphertext,
+zeropad to $128$ bits,
+feed the result through MD5,
+and take the first bit of the result
+(specifically, the bottom bit of the first byte of the result).
+
+This attack outputs $1$ for exactly $32949$ out of all $65536$ $16$bit strings:
+i.e., the average attack output against a uniform random function
+is $32949/65536\approx 0.502762$.
+If this attack is applied to the first $16$ bits of $E_k(0)$
+then it outputs $1$ for exactly $114$ out of the $256$ keys $k$;
+i.e., the average attack output against $E$ is $114/256\approx 0.445312$.
+The success probability of the attack against $E$
+is, by definition, the absolute value of the difference of these two averages,
+namely $3765/65536\approx 0.057449$.
+
+Table~\ref{veriftable} displays the results of similar experiments
+for $K$bit ciphers for a range of values of $K$.
+In each case $2K$ bits of ciphertext are zeropadded to $128$ bits and fed through MD5.
+The table is consistent with the theory
+that the success probability of the attack drops as roughly $1/\sqrt{2^K}$,
+and very far from consistent with the naive theory
+that all very fast attacks have success probability dropping as $1/2^K$.
+
+\begin{table}[t]
+\centerline{
+\begin{tabular}{rrrrrrr}
+\noalign{\hrule}
+$K$&uniform&&cipher&&success\phantom{?}&scaled\phantom{?}\\
+\noalign{\hrule}
+1&1&0.250000\phantom{?}&0&0.000000&0.250000\phantom{?}&0.353553\phantom{?}\\
+2&7&0.437500\phantom{?}&4&1.000000&0.562500\phantom{?}&1.125000\phantom{?}\\
+3&27&0.421875\phantom{?}&4&0.500000&0.078125\phantom{?}&0.220971\phantom{?}\\
+4&117&0.457031\phantom{?}&6&0.375000&0.082031\phantom{?}&0.328125\phantom{?}\\
+5&491&0.479492\phantom{?}&21&0.656250&0.176758\phantom{?}&0.999893\phantom{?}\\
+6&2038&0.497559\phantom{?}&37&0.578125&0.080566\phantom{?}&0.644531\phantom{?}\\
+7&8195&0.500183\phantom{?}&64&0.500000&0.000183\phantom{?}&0.002072\phantom{?}\\
+8&32949&0.502762\phantom{?}&114&0.445312&0.057449\phantom{?}&0.919189\phantom{?}\\
+9&131279&0.500790\phantom{?}&245&0.478516&0.022274\phantom{?}&0.504003\phantom{?}\\
+10&524921&0.500604\phantom{?}&498&0.486328&0.014276\phantom{?}&0.456818\phantom{?}\\
+11&2098847&0.500404\phantom{?}&1029&0.502441&0.002037\phantom{?}&0.092197\phantom{?}\\
+12&8389411&0.500048\phantom{?}&2020&0.493164&0.006884\phantom{?}&0.440563\phantom{?}\\
+13&33555992&0.500023\phantom{?}&4063&0.495972&0.004052\phantom{?}&0.366706\phantom{?}\\
+14&134215688&0.499992\phantom{?}&8070&0.492554&0.007439\phantom{?}&0.952152\phantom{?}\\
+15&536855969&0.499986\phantom{?}&16399&0.500458&0.000472\phantom{?}&0.085383\phantom{?}\\
+16&2147481189&0.499999\phantom{?}&32644&0.498108&0.001892\phantom{?}&0.484228\phantom{?}\\
+17&?&0.500000?&65347&0.498558&0.001442?&0.522044?\\
+18&?&0.500000?&131291&0.500835&0.000835?&0.427734?\\
+19&?&0.500000?&261618&0.498997&0.001003?&0.726442?\\
+20&?&0.500000?&523667&0.499408&0.000592?&0.606445?\\
+21&?&0.500000?&1048417&0.499924&0.000076?&0.109795?\\
+22&?&0.500000?&2097213&0.500015&0.000015?&0.029785?\\
+23&?&0.500000?&4193272&0.499877&0.000123?&0.356316?\\
+24&?&0.500000?&8386407&0.499869&0.000131?&0.537354?\\
+25&?&0.500000?&16776146&0.499968&0.000032?&0.184718?\\
+26&?&0.500000?&33552224&0.499967&0.000033?&0.269531?\\
+27&?&0.500000?&67108562&0.499998&0.000002?&0.026068?\\
+28&?&0.500000?&134239208&0.500080&0.000080?&1.311035?\\
+29&?&0.500000?&268434302&0.499998&0.000002?&0.049805?\\
+30&?&0.500000?&536878982&0.500008&0.000008?&0.246277?\\
+31&?&0.500000?&1073756269&0.500007&0.000007?&0.311711?\\
+32&?&0.500000?&2147489600&0.500001&0.000001?&0.090820?\\
+\noalign{\hrule}
+\end{tabular}
+}
+\medskip
+\caption{Success probability of MD5
+as an attack against zeropadded $K$bit AES keys.
+``Uniform'' is the number of $2K$bit strings $s$
+such that $\bits_1\MDfive(s,0)=1$,
+where $s,0$ means $s$ zeropadded to $128$ bits
+and $\bits_1$ means the first bit.
+The subsequent column is ``uniform'' divided by $2^{2K}$.
+``Cipher'' is the number of $K$bit strings $k$
+such that $\bits_1\MDfive(\bits_{2K}\AES_{k,0}(0),0)=1$,
+where $\bits_{2K}$ means the first $2K$ bits.
+The subsequent column is ``cipher'' divided by $2^{K}$.
+``Success'' is the success probability of the attack:
+the absolute difference between ``uniform'' divided by $2^{2K}$
+and ``cipher'' divided by $2^K$.
+``Scaled'' is ``success'' times $\sqrt{2^K}$.
+``?'' means that ``uniform'' was not computed but was estimated to be $2^{2K}/2$.
+}
+\label{veriftable}
+\end{table}
+
+The analysis in Section~\ref{aesmd5}
+states that (if $K$bit keys
+do not produce surprisingly frequent collisions in $2K$ bits of ciphertext)
+replacing MD5 with a uniform random function
+would have probability approximately $1\erf(x\sqrt{2})$
+of producing an attack whose success probability is at least $x/\sqrt{2^K}$;
+e.g., probability approximately $0.31731$
+of producing an attack whose success probability is at least $0.5/\sqrt{2^K}$,
+and probability approximately $0.98404$
+of producing an attack whose success probability is at least $0.01/\sqrt{2^K}$.
+With this replacement,
+the second average described above
+is the average of $2^K$ independent uniform random bits
+and thus has a bellcurve distribution of width roughly $1/\sqrt{2^K}$,
+while the first average
+is the average of $2^{2K}$ independent uniform random bits
+and thus has a much narrower bellcurve distribution of width roughly $1/2^K$,
+so the difference will almost always be on the scale of $1/\sqrt{2^K}$.