# Matthew Green - To Schnorr and Beyond (Highlights) ![rw-book-cover|256](https://matthewdgreen.files.wordpress.com/2023/10/image-1.png) ## Metadata **Review**:: [readwise.io](https://readwise.io/bookreview/34852324) **Source**:: #from/readwise #from/reader **Zettel**:: #zettel/fleeting **Status**:: #x **Authors**:: [[Matthew Green]] **Full Title**:: To Schnorr and Beyond **Category**:: #articles #readwise/articles **Category Icon**:: 📰 **URL**:: [blog.cryptographyengineering.com](https://blog.cryptographyengineering.com/2023/10/06/to-schnorr-and-beyond-part-1/) **Host**:: [[blog.cryptographyengineering.com]] **Highlighted**:: [[2023-12-02]] **Created**:: [[2023-12-02]] ## Note 1. What is the main problem with the initial identification protocol proposed in the document? 2. How does Peggy respond to Victor's challenge in the identification protocol? 3. How does the document address the security concern of Victor running the protocol with Peggy multiple times? ## Highlights - Why do we accept this tiny probability of an impersonator succeeding? It turns out that this is basically unavoidable for any identification protocol. This is because the number of bits Peggy sends to Victor must be finite, and we already said there must exist at least one “successful” response that will make Victor accept. Hence there clearly exists an adversary who just *guesses* the right strings and gets lucky very ocasionally. ([View Highlight](https://read.readwise.io/read/01hgmmj4gmkm4ajeebpkhvyjm6)) ^635098443 - If the protocol was fully non-interactive (meaning, it consists of exactly one message from Peggy to Victor) then Victor could later “replay” his recorded message to some other Verifier, thus convincing that person that he is actually Peggy. ([View Highlight](https://read.readwise.io/read/01hgmmmt3sxhzr473n7gn5v472)) ^635098559 - While interaction is generally required, in some instances we can seemingly “sneak around” this requirement by “extracting a challenge from the environment.” For example, real-world protocols will sometimes ‘bind’ the identification protocol to metadata such as a timestamp, transaction details, or the Verifier’s name. ([View Highlight](https://read.readwise.io/read/01hgmmp7gbfxv7tyeykfc7ns3t)) ^635098828