Du befindest dich hier: FSI Informatik » Prüfungsfragen und Altklausuren » Hauptstudiumsprüfungen » Lehrstuhl 13 » PPCryptoCur Exam 2020-10-21

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen der Seite angezeigt.

Link zu der Vergleichsansicht

Beide Seiten, vorherige ÜberarbeitungVorherige Überarbeitung
Nächste Überarbeitung		Vorherige Überarbeitung
Nächste ÜberarbeitungBeide Seiten, nächste Überarbeitung
pruefungen:hauptstudium:ls13:ppcryptocur-2020-10-21 [21.10.2020 14:53] – Marcel[Inf]pruefungen:hauptstudium:ls13:ppcryptocur-2020-10-21 [21.10.2020 15:02] – Marcel[Inf]
Zeile 17: Zeile 17:
     * I skipped almost all proofs altogether. One of the few proofs I looked at was the one for the binding and hiding properties of the Pedersen commitment scheme.     * I skipped almost all proofs altogether. One of the few proofs I looked at was the one for the binding and hiding properties of the Pedersen commitment scheme.
   * Evaluation   * Evaluation
-    * The exam is fair, but notably, also covers a wide range of topics. Some questions are "soft" in the sense that they ask, say, why BTC does not provide privacy, how DoS is possible with decentral mixing protocols, how that can be avoided (it cannot), or what trusted setup assumptions mean philosophically. Then, other questions are more technical. Overall, it's a good mix of both and you need to be fluent in both. +    * The exam is fair, but notably, also covers a wide range of topics. Some questions are "soft" in the sense that you can answer them without having a deep understanding of the technicalities and formalisms. For instance, those questions include "why does BTC not provide privacy", "how is DoS handled with decentral mixing protocols", "how can such DoS be avoided", and what trusted setup assumptions mean philosophically. On the other hand, other questions require a pretty good understanding of the technicalities. Overall, it's a good mix of both intuition, high-level ideas and formalisms. And you need to be fluent in both to ace (pass?) the exam. 
-    * The exam is always started with the question "What did you like the most?" And this is an invitation for you as the student to freely deliver a well-learnt topic.+    * Exam by Prof. Schröder always start with their question "What did you like the most?". And this is an invitation for you as the student to freely deliver a well-learnt topic in <= 3min.
  
 ===== Exam ===== ===== Exam =====
Zeile 45: Zeile 45:
 > Use mixing services. Either centralized (centralized mixer, TumbleBit) or decentralized ones (CoinJoin, CoinShuffle). Centralized mixers [note: this does *not* include TumbleBit] inherently need to be a TTP, can steal your coins and/or leak your identity. Decrentralized ones build upon peer-to-peer protocols. But in CoinJoin all participants still learn about the input/output address pair mapping. At least no coins can be stolen anymore thanks to how BTC transactions work and how transaction inputs need to be signed. Or use a currency that was made with privacy-preservation in mind, e.g. RingCT. > Use mixing services. Either centralized (centralized mixer, TumbleBit) or decentralized ones (CoinJoin, CoinShuffle). Centralized mixers [note: this does *not* include TumbleBit] inherently need to be a TTP, can steal your coins and/or leak your identity. Decrentralized ones build upon peer-to-peer protocols. But in CoinJoin all participants still learn about the input/output address pair mapping. At least no coins can be stolen anymore thanks to how BTC transactions work and how transaction inputs need to be signed. Or use a currency that was made with privacy-preservation in mind, e.g. RingCT.
  
-  * In RingCT, what are stealth addresses more precisely?+  * What happens in those decentral mixing protocols if one party just stops responding? 
 + 
 +> Indeed, DoS is a problem found in all privacy-preserving techniques that require active participation by others. By contrast, in ZeroCoin, RingCT, and ZeroCash such participation by others is not required and you can choose your anonymity set yourself. 
 +> In the decentral protocols, there is no much you can do to avoid DoS. Certainly you can stop interacting with specific BTC addresses. But then, their users just generate tons of fresh ones. Certainly you can stop interacting with specific IP addresses. But then, they might as well possess a botnet with tons of different IP addresses. 
 + 
 +  * Let's step up to RingCT. Can you elaborate on stealth addresses?
  
 > With SKAccGen you create `(msk, mpk)` and from `mpk` senders can derive a `pk`. If senders do that honestly, `pk` cannot be linked back to `mpk`. But if you possess the `msk`, you can scan the blockchain and for matching `pk`s (that have been derived from `mpk`), you can derive the corresponding `sk` to have the money at your disposal. > With SKAccGen you create `(msk, mpk)` and from `mpk` senders can derive a `pk`. If senders do that honestly, `pk` cannot be linked back to `mpk`. But if you possess the `msk`, you can scan the blockchain and for matching `pk`s (that have been derived from `mpk`), you can derive the corresponding `sk` to have the money at your disposal.
Zeile 83: Zeile 88:
 > By requiring the existence of an extractor that given a prover and a statement stmt outputs a (putative) witness fulfilling the following property: if that prover was able to convince the (honest) verifier, then the witness output by the extractor is in fact a witness for the statement stmt being in the relation R. R is the NP relation in the usual definitions of ZKP-related concepts. Importantly, the extractor is given oracle access to the prover and can also rewind it. Something that isn't doable in practice and hence this extractability notion actually makes sense. [note: I said this paragraph purely orally and that sufficed. I don't think they want you to know the exact notation or learn the typesetting of definitions by heart.] > By requiring the existence of an extractor that given a prover and a statement stmt outputs a (putative) witness fulfilling the following property: if that prover was able to convince the (honest) verifier, then the witness output by the extractor is in fact a witness for the statement stmt being in the relation R. R is the NP relation in the usual definitions of ZKP-related concepts. Importantly, the extractor is given oracle access to the prover and can also rewind it. Something that isn't doable in practice and hence this extractability notion actually makes sense. [note: I said this paragraph purely orally and that sufficed. I don't think they want you to know the exact notation or learn the typesetting of definitions by heart.]
  
-> For non-interactive protocols we also formalize this by the existence of an extractor. How can this work for non-interactive protocols? For interactive ones, it's clearer: you have this rewinding technique.+  * For non-interactive protocols we also formalize this by the existence of an extractor. How can this work for non-interactive protocols? For interactive ones, it's clearer: you have this rewinding technique.
  
-  * The extractor can control the common reference string crs or some trapdoor - depends on the exact formalization of ZKP-related concepts, though. [note: Prof. Schröder here just repeated a question of mine; namely that question I had asked days before on the course forum and there got the very same reply I answered, too.]+> The extractor can control the common reference string crs or some trapdoor - depends on the exact formalization of ZKP-related concepts, though. [note: Prof. Schröder here just repeated a question of mine; namely that question I had asked days before on the course forum and there got the very same reply I answered, too.]
  
-> How does a (non-interactive) signature of knowledge work? How can it be secure without any communication/challenges by the verifier?+  * How does a (non-interactive) signature of knowledge work? How can it be secure without any communication/challenges by the verifier?
  
-  * We often have an interactive protocol that we then transform via the Fiat-Shamir transform. There, we replace the challenges by the verifier (that all need to be public-coin) by hashes of all previous messages. This is then guaranteed to be secure in the ROM.+> We often have an interactive protocol that we then transform via the Fiat-Shamir transform. There, we replace the challenges by the verifier (that all need to be public-coin) by hashes of all previous messages. This is then guaranteed to be secure in the ROM.