signatur:start
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen RevisionVorhergehende ÜberarbeitungNächste Überarbeitung | Vorhergehende Überarbeitung | ||
signatur:start [2023/12/04 10:05] – [Digitale Signatur] Martin Pabst | signatur:start [2023/12/06 07:50] (aktuell) – Martin Pabst | ||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
====== Digitale Signatur ====== | ====== Digitale Signatur ====== | ||
- | ===== Kryptographische Hashfunktion ===== | ||
- | <WRAP center round info 80%> | ||
- | Eine **Kryptographische Hashfunktion** ist ein Algorithmus, | ||
- | Die derzeit am häufigsten verwendet Hashfunktion ist **SHA**. Eine weitere sehr bekannte - aber veraltete und als unsicher eingestufte - Hashfunktion ist **md5**. Hier eine [[http:// | ||
- | </ | ||
- | |||
- | ==== Anwendung: Speichern von Passwörtern als salted hash ==== | ||
- | <WRAP center round info 80%> | ||
- | Immer wieder kommt es zu erfolgreichen Hackerangriffen gegen Server großer Firmen, wie beispielsweise [[https:// | ||
- | Damit Hacker auch bei Vollzugriff auf einen Server keinen Zugriff auf Passwörter erlangen können, speichert man diese nicht im Klartext, sondern als **salted hash**. Das funktioniert folgendermaßen: | ||
- | {{ : | ||
- | {{ : | ||
- | Aus den **salted hash**-Werten, | ||
- | </ | ||
- | |||
- | <WRAP center round todo 60%> | ||
- | Warum ist das **salt** nötig? Es würde doch reichen, die Hashes der Passwörter zu speichern? \\ \\ | ||
- | //**Tipp:** Recherchieren Sie zur Beantwortung dieser Frage, was " | ||
- | </ | ||
- | |||
- | |||
- | ===== Digitale Signatur ===== | ||
<WRAP center round info 80%> | <WRAP center round info 80%> | ||
Zweck der Signatur ist es, nachzuweisen, | Zweck der Signatur ist es, nachzuweisen, | ||
Zeile 34: | Zeile 12: | ||
<WRAP center round info 80%> | <WRAP center round info 80%> | ||
- | Zweck der Signatur ist es, nachzuweisen, | + | Das obige Verfahren |
- | \\ \\ | + | |
- | Der **RSA-Algorithmus** kann so **abgewandelt** werden, dass mit dem **privaten** Schlüssel **verschlüsselt** und mit dem **öffentlichen** Schlüssel **entschlüsselt** wird. Ein Absender könnte einen Text also digital signieren, indem er ihn mit seinem privaten Schlüssel verschlüsselt. Falls es dem Empfänger gelingt, den verschlüsselten Text mit dem öffentlichen Schlüssel des Senders zu entschlüsseln, | + | |
- | * man den Text als Klartext versenden möchte, der auch ohne Schlüssel lesbar ist und | + | |
- | * die Entschlüsselung mit dem RSA-Algorithmus sehr rechenintensiv ist. | + | |
Man geht daher wie folgt vor: | Man geht daher wie folgt vor: | ||
- | * a) Der Sender erzeugt mithilfe einer kryptographischen Hashfunktion | + | * a) Der Sender erzeugt mithilfe einer kryptographischen Hashfunktion |
- | * b) Der Sender verschlüsselt | + | * b) Der Sender verschlüsselt |
- | * c) Der Empfänger entschlüsselt | + | * c) Der Empfänger entschlüsselt |
- | * d) Der Empfänger berechnet | + | * d) Der Empfänger berechnet |
- | * e) Der Empfänger vergleicht hash1 und hash2. Stimmen sie überein, so weiß er, dass der Text vom Sender stammt. | + | * e) Der Empfänger vergleicht hash1 und hash2. Stimmen sie überein, so weiß er, dass der Text vom Sender stammt |
+ | |||
+ | {{ : | ||
</ | </ | ||
+ | |||
+ | |||
signatur/start.1701684321.txt.gz · Zuletzt geändert: 2023/12/04 10:05 von Martin Pabst