diff options
| -rw-r--r-- | sem4/sec/t4/opg.md | 74 |
1 files changed, 74 insertions, 0 deletions
diff --git a/sem4/sec/t4/opg.md b/sem4/sec/t4/opg.md new file mode 100644 index 0000000..e865e57 --- /dev/null +++ b/sem4/sec/t4/opg.md @@ -0,0 +1,74 @@ +# Opgave 1 + +> In encryption using block-cipher, what potential problem can occur when using Electronic Code Book? Using Cipher Block Chaining? + +## Electronic Code Book + +Her er problemet at to beskeder med den samme key giver det samme output. +Derfor kan man pludselig se at to beskeder er det samme ud fra cipher. +Dette er et problem med tekst eller billeder der tit er det samme. + +## Cipher Block Chaining + +Her er problemet at man ikke kan komme ind i midten af en besked, da man mangler data fra den sidste. +Langsommere da messages afhænger af hinnanden. + +Angribere kan pille i bits med den næste besked. + +# Opgave 2 + +> Assume that two parties know each other’s public keys. +> If one message is sent from A to B, what can be verified? + +Hvis beskeden er signed af med A's private key kan B check om beskeden virkelig +stammer fra A (her går man ud fra at det kun er A der har A's private key). + +Hvis beskeden er krypteret med B's public key kan B være sikker på at ingen andre +har læst beskeden (her går man igen ud fra at ingen kender B's private key). + +> If two messages are exchanges, what can be verified? + +Hvis der er to beskeder altså A -> B og B -> A, kan A sikre sig at B har +modtaget ens besked. +B ved til gengæld ikke om dens besked kom ordenligt igennem. + +# Opgave 3 + +> With Diffie-Hellman key exchange is a man-in-the-middle attack possible? + +Ja det kan man godt, diffie helman viser kun hvordan jo kan blive enige om en fælles key +men ikke hvordan de ved at de snakker til den rigtige. +Derfor kan man som mellemmand lade som om man er B for A og A for B. + +# Opgave 4 + +> Assume the following scenario: A and B both have the knowledge of a secret key K (e.g. pre-shared). +> They communicate over an unsecure channel. +> Define a protocol (by writing down a message sequence chart) in which A and B use the pre-shared key K to mutually authenticate each other and to agree on a common session key (different from the long-term pre-shared key K). +> Try to keep the number of exchanged messages as low as possible. + +``` + ┌─┐ ┌─┐ + │A│ │B│ + └┬┘ └┬┘ + │ Tilfældig challenge CA │ + │───────────────────────────────────────>│ + │ │ + │E(K, Tilfældig key KB + E(KB, CA)) + CB │ + │<───────────────────────────────────────│ + │ │ + │ E(K, Tilfældig key KA + E(KA, CB)) │ + │───────────────────────────────────────>│ + │ │ + ╔═╧════════════════════════════════════════╧═╗ + ║Shared key KT generes med KB xor KA ░║ + ╚════════════════════════════════════════════╝ + │A│ │B│ + └─┘ └─┘ +``` + +Her sikrer man ved challenges at A og B er den rigtige og ikke en mellemmand. +KB og KA krypteres med K for at sikre at de ikke bliver læst samt kryptere man +CA og CB med de tilfældige keys for at sikre at de har det samme. + +[Kilde til figur](http://www.plantuml.com/plantuml/png/ROv13e9034NtFSLVEX4km8BG4bSivG94AX278HdGw8MyY1UpP3OktBM_hw-jrgsBsttsn7af1Th9Npzltqy3BcFdlOP1KJD9NdA1qw79Vf6Rlj08Zlj0CkESiwQM9FkB2oUS3HVdA2oROdbeX2L2vx6BsYTnYq63HbqnMsHtdaj4mwIXnxv6bLNs-XS0) |