# IES Fragenkatalog

* Ist CTR-Mode CCA secure?

* Wofür steht AEAD?

* Warum sind die Schemes GCM oder EAX online, obwohl beide Encrypt-then-MAC verwenden?

* Warum ist CBC-Mac unsicher wenn keine feste Länge verwendet und keine Länge prepended wird?

* Wie funktioniert SIV?

* Wie lang ist die Nonce bei dem AEAD Modus OCB und wieso?

* Welches AEAD-Scheme würden Sie der Bundeswehr empfehlen, wenn es auf einem Microcontroller ausgefürht werden soll?
<details><summary>Antwort</summary>
Doppelfangfrage! Deutsche Behörden richten sich nach dem BSI und der BSI empfiehlt nur eine symmetrische Verschlüsselung: AES -> https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.pdf?__blob=publicationFile&v=10
Für den Betriebsmodus kommt dann z.B. GCM in frage.
Für Microcontroller ist eine AEAD Verschlüsselung wie ASCON zu empfehlen. -> https://competitions.cr.yp.to/caesar-submissions.html
</details>

* Warum ist "unauthenticated Diffie-Hellman" nicht sicher? (MITM)

* Warum bietet der RSA key exchange keine perfect forward secrecy?

* Warum bietet Diffie-Hellmann kein PFS?

* Warum bieten TLS 1.2 Session tickets kein PFS?

* Welche zwei Möglichkeiten besehen zur "session resumption" bei TLS 1.2? (Wie funktionieren sie?)

* Warum wird bei Fortuna immer nachdem random bytes generiert wurden ein neuer Key erstellt?
<details><summary>Antwort</summary>
Damit selbst wenn der interne State geleakt wird, die letzten Schlüssel nicht errechnet werden können (Kind of Forward Secrecy)
</details>

* Warum wird bei Fortuna zwei mal gehashed, wenn ein neuer Key erstellt wird?
<details><summary>Antwort</summary>
- Da im originalen Paper SHA2 verwendet wird, und somit lenght extension Attacken kompensiert werden können<br/>
- Wenn eine gescheite Hashfunktion verwendet wird (SHA3, BLAKE, o. Ä.) reicht es aus einmal zu hashen
</details>

* Warum wird in TLS 1.3 immer noch eine ChangeCipherSpec message geschickt?
<details><summary>Antwort</summary>
Für den Middlebox support (ossification).
</details>

* Erkläre Collision resistant, pre-image resistance und second-pre-image resistance.
---

#### Warum ist CTR mit wiederholdender Nonce nicht CPA Secure?
A sendet an Orakel
-> m1 mit 0^L(n)
-> m2 mit 1^L(n)
und erhält ein c.
Orakel verschlüsselt nur eines der beiden Nachrichten.
A sendet nochmals m1 und erhält ein c'
A sagt, c' ist m1, ansonsten m2

#### Warum ist CTR nicht CCA Secure?
A sendet an Orakel
-> m1 = 0^L
-> m2 = 1^L
und erhält ein c.
Idee: XOR Operation von Plaintext XOR Nonce Counter ausnutzen
A konstruiert ein c' mit = 10^L-1 XOR c
c' an Orakel geschickt und bekommt ein Ergebnis m zurück
Wenn m = 100000...0 -> dann m1
Wenn m = 011111...1 -> dann m2

#### Warum ist CBC Mode mit vorhersagbarer IV nicht CPA sicher?

Es gilt: IV1 bekannt. IV2 ist das predicted IV
Idee: XOR Operation von CBC überlisten mit vorhergesagtem IV
1) Zwei Nachrichten (m1 XOR IV1; m2 XOR IV1; m1!=m2) an das Orakel schicken.
Ein Ciphertext kommt zurück, den man zu m1 oder m2 zuordnen muss.
2) Nachricht m1 XOR IV2 an Orakel schicken und Antwort analysieren
3) Ist m1 XOR IV1 identisch mit dem Cipertext aus 2),
dann ist m1 die verschlüsselte Nachricht, ansonsten m2.

#### Warum ist CBC Mode nicht CCA Secure ?

Given:
PPT Adversary A,
Message m1 = 0^L(n) || 0^L(n),
Message m2 = 1^L(n) || 1^L(n),
Message x = 1 || 0^2*L(n)-1,
Ciphertext c, Plaintext p.
(Nachricht m1, aus Nullen bestehend, und m2, aus Einsen bestehend,
werden in zwei gleich große Blöcke aufgesplittet,
Message x -> Erstes Bit ist 1, restliche Null)
Steps: 1) Send m1,m2 to Oracle and get Ciphertext c back from it
2) Define a c“ = c XOR x (Idee ist, nur das erste Bit zu flippen)
3) Send c“ to Oracle and get Plaintext p“ back
4) Im zweiten Block nachschauen, ob 0^L(n)-1 oder 1^L(n)-1 vorhanden und ob ein Bit geflippt wurde.
Mithilfe der Hamming Distanz nachschauen, ob für m1 oder m2 der Wert 1 angezeigt wird
Therefore, CBC is not CCA Secure.

#### Warum ist das Zip Cryptosystem nicht CPA Secure?

PPT adversary = A
message 1 = m[1]
message 2 = m[2]
ciphertext = c

m[1] = 0^l(n)*4
m[2] = E_AES(random_key, 0^l(n)*4)

A ---- m[1], m[2] ---> Orakel
A <------- c --------- Orakel

b = { l c <= n/2: m[1]
{ l c > n/2: m[2]

Idee: Ein Kompressionsystem sollte eine Reihe von Nullen effizient komprimieren können.

Wenn l c <= n/2 ist dann wurde m[1] verschlüsselt. Andernfalls wurde m[2] verschlüsselt.
Demnach ist das ZIP-Cryptosystem nicht CPA secure.

#### Warum ist ECB nicht EAV sicher?
ECB verschlüsselt jeden Block einzeln und konkateniert
->Rückschlüsse auf Klartext möglich (Siehe Linux Pinguin)

#### Warum ist CTR mit halbierten Zahlenraum für Nonce CPA Sicher?
Verfahren ändert sich nicht, nur der Zahlenraum für den Zähler
wird halbiert -> Zähler braucht nicht so lange um auf null zu kommen
->nicht ideal, funktioniert trotzdem

Wat??????
+1
+1
+2