Search for: All records

A proof system is publicly verifiable, if anyone, by looking at the transcript of the proof, can be convinced that the corresponding theorem is true. Public verifiability is important in many applications since it allows to compute a proof only once while convincing an unlimited number of verifiers. Popular interactive proof systems (e.g., 𝛴 -protocols) protect the witness through various properties (e.g., witness indistinguishability (WI) and zero knowledge (ZK)) but typically they are not publicly verifiable since such proofs are convincing only for those verifiers who contributed to the transcripts of the proofs. The only known proof systems that are publicly verifiable rely on a non-interactive (NI) prover, through trust assumptions (e.g., NIZK in the CRS model), heuristic assumptions (e.g., NIZK in the random oracle model), specific number-theoretic assumptions on bilinear groups or relying on obfuscation assumptions (obtaining NIWI with no setups). In this work we construct publicly verifiable witness-indistinguishable proof systems from any 𝛴 -protocol, based only on the existence of a very generic blockchain. The novelty of our approach is in enforcing a non-interactive verification (thus guaranteeing public verifiability) while allowing the prover to be interactive and talk to the blockchain (this allows us to circumvent the need of strong assumptions and setups). This opens interesting directions for the design of cryptographic protocols leveraging on blockchain technology. 

“Break-glass” is a term used in IT healthcare systems to denote an emergency access to private information without having the credentials to do so. In this paper we introduce the concept of break-glass encryption for cloud storage, where the security of the ciphertexts – stored on a cloud – can be violated exactly once, for emergency circumstances, in a way that is detectable and without relying on a trusted party. Detectability is the crucial property here: if a cloud breaks glass without permission from the legitimate user, the latter should detect it and have a proof of such violation. However, if the break-glass procedure is invoked by the legitimate user, then semantic security must still hold and the cloud will learn nothing. Distinguishing that a break-glass is requested by the legitimate party is also challenging in absence of secrets. In this paper, we provide a formalization of break-glass encryption and a secure instantiation using hardware tokens. Our construction aims to be a feasibility result and is admittedly impractical. Whether hardware tokens are necessary to achieve this security notion and whether more practical solutions can be devised are interesting open questions.