From 24cfab0b55c3c585d6889f3a8a0e1526fce23f0a Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Wed, 19 Jan 2022 18:00:06 +0000 Subject: [PATCH] Add reference to [BCGGMTV2014] when discussing an example of an incorrect security claim. Signed-off-by: Daira Hopwood --- protocol/protocol.tex | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/protocol/protocol.tex b/protocol/protocol.tex index 437db263..56e46d82 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -3752,9 +3752,9 @@ In this respect the abstractions play a similar rôle to that of a type system ( add a form of redundancy to the specification that helps to express the intent. Each property is a claim that may be incorrect (or that may be insufficiently precisely stated to -determine whether it is correct). An example of an incorrect security claim occurs in the \Zerocash protocol: -the instantiation of the \noteCommitment scheme used in \Zerocash failed to be \binding at the intended -security level (see \crossref{internalh}). +determine whether it is correct). An example of an incorrect security claim occurs in the \Zerocash protocol +\cite{BCGGMTV2014}: the instantiation of the \noteCommitment scheme used in \Zerocash failed to be \binding +at the intended security level (see \crossref{internalh}). Another hazard that we should be aware of is that abstractions can be ``leaky'': an instantiation may impose conditions on its correct or secure use that are not captured by the abstraction's interface and semantics.