Du befindest dich hier: FSI Informatik » Prüfungsfragen und Altklausuren » Hauptstudiumsprüfungen » Lehrstuhl 13 » PPCryptoCur Exam 2020-10-21 (Übersicht)
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen der Seite angezeigt.
Beide Seiten, vorherige ÜberarbeitungVorherige ÜberarbeitungNächste Überarbeitung | Vorherige Überarbeitung | ||
pruefungen:hauptstudium:ls13:ppcryptocur-2020-10-21 [21.10.2020 14:54] – Marcel[Inf] | pruefungen:hauptstudium:ls13:ppcryptocur-2020-10-21 [21.10.2020 15:09] (aktuell) – Marcel[Inf] | ||
---|---|---|---|
Zeile 14: | Zeile 14: | ||
* active collaboration in lecture/ | * active collaboration in lecture/ | ||
* two weeks preparation directly before the exam of 4-5 hours per day (without weekends) | * two weeks preparation directly before the exam of 4-5 hours per day (without weekends) | ||
+ | * I read through my lecture notes and the official script (which is still work-in-progress) in parallel. As the script was still work-in-progress, | ||
* I focussed very much on relating all privacy-preserving techniques, on knowing (i) very well all models (e.g. RingCT) (ii) pretty good general ideas on the constructions and ingredients (e.g. zero-knowledge proofs, how RingCT can be instantiated, | * I focussed very much on relating all privacy-preserving techniques, on knowing (i) very well all models (e.g. RingCT) (ii) pretty good general ideas on the constructions and ingredients (e.g. zero-knowledge proofs, how RingCT can be instantiated, | ||
* 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 " | + | * The exam is fair, but notably, also covers a wide range of topics. Some questions are " |
- | * The exam is always | + | * Exam by Prof. Schröder |
===== Exam ===== | ===== Exam ===== | ||
Zeile 29: | Zeile 30: | ||
> RingCT. In contrast to BTC, it provides three main advantages: (i) ring signatures, (ii) stealth addresses, (iii) hidden amounts. I elaborated on every point with at least 3-4 sentences saying how it's *not* (or badly) done in BTC and with what consequences and how it's done in RingCT. Roughly: | > RingCT. In contrast to BTC, it provides three main advantages: (i) ring signatures, (ii) stealth addresses, (iii) hidden amounts. I elaborated on every point with at least 3-4 sentences saying how it's *not* (or badly) done in BTC and with what consequences and how it's done in RingCT. Roughly: | ||
+ | > | ||
+ | > * ad (i): in BTC a TX with exactly 10 senders contains exactly those 10 senders in plaintext. In RingCT, you can provide 100 putative senders, of which, say, 90 are just " | ||
> | > | ||
> * ad (ii): in BTC, if you want someone to pay you, you have to publish your BTC address. The same holds true if you want to run, say, a donation campaign. Then, on the blockchain everyone can see who donated to you, and that's bad. Hence, it's recommended to always freshly generate receival addresses, but that's impossible with donation campaigns. Hence, RingCT offloads that fresh generation thing onto the sender via stealth addresses. | > * ad (ii): in BTC, if you want someone to pay you, you have to publish your BTC address. The same holds true if you want to run, say, a donation campaign. Then, on the blockchain everyone can see who donated to you, and that's bad. Hence, it's recommended to always freshly generate receival addresses, but that's impossible with donation campaigns. Hence, RingCT offloads that fresh generation thing onto the sender via stealth addresses. | ||
> | > | ||
+ | > * ad (iii): in BTC, transferred amounts are public. In RingCT, they are hidden. | ||
* You mentioned some great ideas. Let's dive into that and start with something simple: The BTC blockchain only contains addresses. What's so privacy-invading about that? | * You mentioned some great ideas. Let's dive into that and start with something simple: The BTC blockchain only contains addresses. What's so privacy-invading about that? | ||
Zeile 45: | Zeile 49: | ||
> 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/ | > 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/ | ||
- | * In RingCT, | + | * 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, | ||
+ | > 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 68: | Zeile 77: | ||
* Why cannot we have perfect hiding and perfect binding at the same time? | * Why cannot we have perfect hiding and perfect binding at the same time? | ||
- | | + | |
> See https:// | > See https:// | ||
Zeile 89: | Zeile 98: | ||
* How does a (non-interactive) signature of knowledge work? How can it be secure without any communication/ | * How does a (non-interactive) signature of knowledge work? How can it be secure without any communication/ | ||
- | > 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. [note: sometimes, we can get a secure scheme with Fiat-Shamir even without the ROM assumption, see https:// |
* We covered many different privacy-preserving techniques in the lecture: CoinJoin, CoinShuffle, | * We covered many different privacy-preserving techniques in the lecture: CoinJoin, CoinShuffle, |