Auf einen Blick

  • Ziel: Authentizität, Integrität und Nichtabstreitbarkeit einer Nachricht sicherstellen.
  • Prinzip: Signieren mit privatem Schlüssel, Verifizieren mit öffentlichem Schlüssel (spiegelbildlich zu RSA-Verschlüsselung).
  • RSA-Signatur: $s = H(m)^{d} \bmod n$, Verifikation $s^{e} \bmod n \stackrel{?}{=} H(m)$.
  • Immer den Hash signieren! Direktes Signieren von $m$ öffnet Angriffe wegen der multiplikativen Homomorphie von RSA.
  • PKI: X.509-Zertifikate, Root-CA → Zwischen-CA → Endnutzer bilden die Chain of Trust; Widerruf via CRL/OCSP.

Kernkonzepte

1. Was leistet eine digitale Signatur?

Eine digitale Signatur ist das kryptographische Pendant zur handschriftlichen Unterschrift. Sie garantiert drei Eigenschaften:

  • Authentizität: Die Nachricht stammt vom Besitzer des privaten Schlüssels.
  • Integrität: Die Nachricht wurde nach dem Signieren nicht verändert.
  • Nichtabstreitbarkeit (Non-Repudiation): Der Signierer kann später nicht bestreiten, die Nachricht unterschrieben zu haben, da nur er den privaten Schlüssel kennt.

Im Gegensatz zu einem MAC (Message Authentication Code) mit symmetrischem Schlüssel, den beide Parteien kennen, bietet nur die asymmetrische Signatur echte Nichtabstreitbarkeit.

2. RSA-Signatur (Signieren & Verifizieren)

Die RSA-Signatur nutzt dieselben Schlüssel wie RSA-Verschlüsselung, aber mit vertauschten Rollen:

Signieren (durch Alice mit ihrem privaten Schlüssel $d$):

$$s = H(m)^{d} \bmod n$$

Verifizieren (durch Bob mit Alice' öffentlichem Schlüssel $(e, n)$):

$$s^{e} \bmod n \stackrel{?}{=} H(m)$$

Bob berechnet also selbst den Hash der empfangenen Nachricht und vergleicht ihn mit dem entschlüsselten Signaturwert. Ist die Gleichung erfüllt, ist die Signatur gültig.

Warum funktioniert das mathematisch?
Wegen $ed \equiv 1 \pmod{\varphi(n)}$ gilt $\left(H(m)^{d}\right)^{e} = H(m)^{ed} \equiv H(m) \pmod{n}$ – die gleiche Struktur wie bei RSA-Verschlüsselung, nur die Reihenfolge von privat/öffentlich ist getauscht.

3. Warum wird der Hash signiert – und nicht die Nachricht selbst?

  • Performance: RSA ist langsam. Ein 512-Byte-Text signieren wäre teuer, ein 32-Byte-Hash ist schnell.
  • Größenbeschränkung: RSA kann nur Zahlen $< n$ verarbeiten – lange Nachrichten würden auf mehrere Blöcke aufgeteilt werden müssen.
  • Sicherheit gegen Existential Forgery: RSA ist multiplikativ homomorph: $s(m_1) \cdot s(m_2) \equiv s(m_1 \cdot m_2) \pmod{n}$. Ohne Hashen könnte ein Angreifer aus zwei legitimen Signaturen eine dritte gültige Signatur für $m_1 \cdot m_2$ konstruieren.

In der Praxis wird zusätzlich ein Padding-Schema wie RSASSA-PSS verwendet, das Zufälligkeit einführt und die Sicherheit weiter erhöht.

4. DSA und ECDSA

DSA (Digital Signature Algorithm): Ein von der NIST standardisiertes Signaturverfahren, das auf der Schwierigkeit des diskreten Logarithmus (DLP) in $\mathbb{Z}_p^*$ basiert. Anders als RSA kann DSA nur signieren, nicht verschlüsseln.

ECDSA (Elliptic Curve DSA): Dieselbe Idee wie DSA, aber auf elliptischen Kurven. Vorteil: deutlich kürzere Schlüssel bei gleicher Sicherheit (z.B. 256-Bit-ECDSA ≈ 3072-Bit-RSA).

Verfahren Basisproblem Typische Schlüssellänge
RSA-SignaturFaktorisierung2048 – 4096 Bit
DSADLP in $\mathbb{Z}_p^*$2048 – 3072 Bit
ECDSADLP auf elliptischen Kurven256 – 521 Bit

5. Zertifikate, PKI und Chain of Trust

Ein X.509-Zertifikat ist eine standardisierte Datenstruktur, die einen öffentlichen Schlüssel an eine Identität (z.B. eine Domain oder eine Person) bindet. Die Bindung wird von einer Zertifizierungsstelle (Certificate Authority, CA) signiert.

Ein Zertifikat enthält typischerweise:

  • Subject (Inhaber, z.B. CN=dhbw.de)
  • Issuer (ausstellende CA)
  • öffentlicher Schlüssel des Subjects
  • Gültigkeitszeitraum (Not Before / Not After)
  • Seriennummer, Signaturalgorithmus, Erweiterungen
  • Signatur der CA über all das

Public Key Infrastructure (PKI): Hierarchische Struktur aus Root-CA, Zwischen-CAs und Endnutzer-Zertifikaten:

Root-CA (self-signed, im OS/Browser-Truststore vorinstalliert) └── Zwischen-CA (von Root-CA signiert) └── Endnutzer-Zertifikat (von Zwischen-CA signiert)

Der Client prüft die Chain of Trust, indem er jedes Zertifikat mit dem öffentlichen Schlüssel des Ausstellers verifiziert – bis er bei einer Root-CA landet, der er von Haus aus vertraut.

6. Zertifikatswiderruf: CRL und OCSP

Ein Zertifikat kann kompromittiert oder ungültig geworden sein, bevor sein Ablaufdatum erreicht ist. Zwei Mechanismen adressieren das:

  • CRL (Certificate Revocation List): Von der CA regelmäßig herausgegebene, signierte Liste widerrufener Seriennummern. Nachteil: kann groß werden und ist nicht immer aktuell.
  • OCSP (Online Certificate Status Protocol): Online-Statusabfrage der CA (oder eines OCSP-Responders) für eine einzelne Seriennummer. Vorteil: aktueller als CRLs. Erweiterung: OCSP Stapling, bei dem der Server die OCSP-Antwort selbst mitliefert.

7. Signatur vs. MAC

Eigenschaft MAC (symmetrisch) Digitale Signatur (asymmetrisch)
Schlüssel1 gemeinsamer SchlüsselSchlüsselpaar (privat/öffentlich)
Integritätjaja
Authentizitätnur zwischen den Parteienöffentlich prüfbar
Nichtabstreitbarkeitnein (beide kennen Schlüssel)ja
Performancesehr schnelllangsam

Merksätze

Merksatz 1 – Rollen tauschen
Bei der Signatur wird mit dem privaten Schlüssel signiert und mit dem öffentlichen verifiziert – exakt umgekehrt zur Verschlüsselung.
Merksatz 2 – Immer hashen
Sign the hash, not the message. Wegen der multiplikativen Homomorphie von RSA ist direktes Signieren der Nachricht unsicher.
Merksatz 3 – Nur Signatur = Nichtabstreitbarkeit
Ein MAC schützt Integrität, aber der Sender kann bestreiten, weil beide Parteien den Schlüssel kennen. Nur eine digitale Signatur ist nachweisbar an genau eine Person gebunden.
Merksatz 4 – Vertrauen ist eine Kette
Ein Zertifikat ist so vertrauenswürdig wie die Kette bis zur Root-CA. Ein einziger kompromittierter Aussteller in der Kette bricht das gesamte Vertrauen.
Merksatz 5 – Kollision = Signaturbruch
Findet ein Angreifer $H(m_1) = H(m_2)$, überträgt sich jede gültige Signatur für $m_1$ automatisch auf $m_2$. Deshalb sind kollisionsresistente Hashes (SHA-2/SHA-3) Pflicht.
Merksatz 6 – eIDAS
Die EU unterscheidet einfache, fortgeschrittene und qualifizierte elektronische Signaturen (QES). Nur die QES ist der handschriftlichen Unterschrift rechtlich gleichgestellt.

🧮 Rechenaufgaben mit Lösung

Klick auf eine Aufgabe, um den vollständigen Lösungsweg zu sehen.

R1 · RSA-Signatur berechnen ($s = h^{d} \bmod n$)
Gegeben ist das RSA-Schlüsselpaar aus Kapitel 5: $n = 143$, $e = 7$, $d = 103$. Alice möchte einen Hashwert $h = 10$ signieren. Berechne die Signatur $s$.

Lösungsweg

Wir berechnen $s = 10^{103} \bmod 143$ per Square-and-Multiply. Zerlege $103$ binär:

$$103 = 64 + 32 + 4 + 2 + 1 = (1100111)_2$$

Berechne die Quadrat-Potenzen von $10$ mod $143$:

PotenzWert mod 143Rechnung
$10^{1}$10
$10^{2}$100$10 \cdot 10 = 100$
$10^{4}$133$100^2 = 10000 = 69 \cdot 143 + 133$
$10^{8}$100$133^2 = 17689 = 123 \cdot 143 + 100$
$10^{16}$133$100^2 \bmod 143 = 133$
$10^{32}$100$133^2 \bmod 143 = 100$
$10^{64}$133$100^2 \bmod 143 = 133$

Nun die relevanten Bits kombinieren $(64 + 32 + 4 + 2 + 1)$:

10^103 ≡ 10^64 · 10^32 · 10^4 · 10^2 · 10^1 (mod 143) ≡ 133 · 100 · 133 · 100 · 10 (mod 143) Zwischenschritte: 133 · 100 = 13300 ≡ 13300 − 92·143 = 13300 − 13156 = 144 ≡ 1 (mod 143) 1 · 133 = 133 (mod 143) 133 · 100 = 13300 ≡ 1 (mod 143) 1 · 10 = 10 (mod 143)

Ergebnis:

$s = 10^{103} \bmod 143 = 10$

Anmerkung: Da $10 \in \mathbb{Z}_{143}^*$ und $\varphi(143) = 120$ mit $103 \equiv 103 \pmod{120}$ ist, ergibt sich rechnerisch derselbe Wert. Die Signatur ist $s = 10$.

R2 · Signatur verifizieren
Bob erhält eine Nachricht $m$ und die zugehörige Signatur $s = 10$ von Alice ($n=143$, $e=7$). Er berechnet $h' = H(m) = 10$. Verifiziere die Signatur.

Lösungsweg

Verifikationsbedingung: $s^{e} \bmod n \stackrel{?}{=} h'$, also $10^{7} \bmod 143 \stackrel{?}{=} 10$.

Square-and-Multiply mit $7 = (111)_2 = 4 + 2 + 1$:

PotenzWert mod 143
$10^{1}$10
$10^{2}$100
$10^{4}$133
10^7 = 10^4 · 10^2 · 10^1 (mod 143) = 133 · 100 · 10 (mod 143) = (133 · 100) · 10 (mod 143) = 1 · 10 (mod 143) ← weil 133 · 100 ≡ 1 = 10 (mod 143)

$s^{e} \bmod n = 10 = h'$ — die Gleichung ist erfüllt.

Signatur gültig ✓

Ist $s^{e} \bmod n \neq h'$, ist die Signatur ungültig – entweder wurde $m$ verändert oder $s$ manipuliert.

R3 · Multiplikativer Angriff ohne Hash
Alice signiert direkt zwei Nachrichten ohne Hash: $s_1 = m_1^{d} \bmod n$ und $s_2 = m_2^{d} \bmod n$. Zeige, dass Mallory daraus eine gültige Signatur für $m_1 \cdot m_2$ konstruieren kann. Rechne mit $n=143$, $d=103$, $m_1 = 5$, $m_2 = 7$.

1. RSA ist multiplikativ homomorph

$$s_1 \cdot s_2 = m_1^{d} \cdot m_2^{d} = (m_1 \cdot m_2)^{d} \pmod{n}$$

Das heißt: Das Produkt zweier legitimer Signaturen ist selbst wieder eine gültige Signatur – nämlich für das Produkt der Nachrichten.

2. Zahlenbeispiel

Berechne $s_1 = 5^{103} \bmod 143$ und $s_2 = 7^{103} \bmod 143$ (ausgewählte Zwischenergebnisse):

5^103 mod 143 = 125 → s_1 7^103 mod 143 = 123 → s_2

Mallory bildet daraus:

s_forged = s_1 · s_2 mod 143 = 125 · 123 mod 143 = 15375 mod 143 = 15375 − 107·143 = 15375 − 15301 = 74

Kontrolle: Was ist die legitime Signatur für $m_1 \cdot m_2 = 35$?

35^103 mod 143 = 74 ✓ (gleicher Wert)
Mallory kann ohne Kenntnis von $d$ die gültige Signatur $s = 74$ für die Nachricht $m = 35$ berechnen.

Konsequenz

Ohne Hashen liefert RSA existential forgery: Der Angreifer produziert eine gültige Signatur für eine Nachricht, die Alice nie unterschrieben hat. Durch das Hashen ($s = H(m)^{d}$) bricht die Homomorphie zusammen, weil $H$ nicht multiplikativ ist: $H(m_1 \cdot m_2) \neq H(m_1) \cdot H(m_2)$ in aller Regel.

R4 · Zertifikatskette – wie viele Verifikationen?
Root-CA A signiert das Zertifikat der Zwischen-CA B. B signiert das Endnutzer-Zertifikat C. Der Client vertraut A direkt. Wie viele Signaturverifikationen führt der Client aus, um C zu vertrauen?

Lösungsweg

Die Chain of Trust wird von unten nach oben (oder umgekehrt) validiert:

1) Cert(C) wurde von B signiert → Client prüft: Verify_pubkey(B) über Cert(C) ← Verifikation #1 2) Cert(B) wurde von A signiert → Client prüft: Verify_pubkey(A) über Cert(B) ← Verifikation #2 3) Cert(A) ist im Truststore → keine Verifikation nötig, nur Trust-Anchor-Prüfung
Der Client führt 2 Signaturverifikationen durch (A→B und B→C) und vertraut A direkt.

Allgemein: Bei einer Kette der Länge $n$ (inkl. Root) sind $n-1$ Signaturverifikationen nötig.

R5 · Kollisions-Angriff auf Signaturen
Mallory findet zwei verschiedene Nachrichten $m_1$ (harmlos) und $m_2$ (bösartig) mit $H(m_1) = H(m_2)$. Wie führt Mallory einen Angriff durch, und welche Sicherheitseigenschaft von $H$ ist verletzt?

Ablauf des Angriffs

1) Mallory konstruiert m_1 = harmloser Vertrag und m_2 = bösartiger Vertrag mit H(m_1) = H(m_2). 2) Mallory bittet Alice, m_1 zu signieren. Alice sieht m_1 und signiert: s = H(m_1)^d mod n 3) Mallory publiziert (m_2, s) statt (m_1, s). 4) Bob verifiziert: s^e mod n = H(m_1) = H(m_2) = H(m_2) ✓ Signatur ist "gültig" für m_2 !
Ergebnis: Mallory hat eine gültige Signatur von Alice über eine Nachricht $m_2$, die sie nie unterschrieben hat.

Welche Eigenschaft ist verletzt?

Kollisionsresistenz von $H$. Diese verlangt, dass es praktisch unmöglich ist, zwei verschiedene $m_1, m_2$ mit $H(m_1) = H(m_2)$ zu finden.

Deshalb sind Hash-Verfahren wie MD5 (kollisionsangreifbar seit 2004) und SHA-1 (angreifbar seit 2017) für Signaturen nicht mehr zulässig. Standard ist heute mindestens SHA-256.

R6 · Kleine RSA-Signatur mit anderem Hash
Gegeben $n = 143$, $e = 7$, $d = 103$. Signiere den Hashwert $h = 42$ und verifiziere anschließend.

Signieren: $s = 42^{103} \bmod 143$

PotenzWert mod 143Rechnung
$42^{1}$42
$42^{2}$49$42^2 = 1764 = 12 \cdot 143 + 48$ — Korrektur: $1764 − 12 \cdot 143 = 1764 − 1716 = 48$
$42^{2}$48korrigiert: $48$
$42^{4}$16$48^2 = 2304 = 16 \cdot 143 + 16$
$42^{8}$113$16^2 = 256 = 1 \cdot 143 + 113$
$42^{16}$42$113^2 = 12769 = 89 \cdot 143 + 42$
$42^{32}$48$42^2 \bmod 143 = 48$ (siehe oben)
$42^{64}$16$48^2 \bmod 143 = 16$

$103 = 64 + 32 + 4 + 2 + 1$:

42^103 ≡ 42^64 · 42^32 · 42^4 · 42^2 · 42^1 (mod 143) ≡ 16 · 48 · 16 · 48 · 42 (mod 143) Schritt für Schritt: 16 · 48 = 768 ≡ 768 − 5·143 = 768 − 715 = 53 (mod 143) 53 · 16 = 848 ≡ 848 − 5·143 = 848 − 715 = 133 (mod 143) 133 · 48 = 6384 ≡ 6384 − 44·143 = 6384 − 6292 = 92 (mod 143) 92 · 42 = 3864 ≡ 3864 − 27·143 = 3864 − 3861 = 3 (mod 143)
$s = 42^{103} \bmod 143 = 3$

Verifizieren: $s^{e} \bmod n = 3^{7} \bmod 143$

3^1 = 3 3^2 = 9 3^4 = 81 3^7 = 3^4 · 3^2 · 3^1 = 81 · 9 · 3 = 2187 2187 mod 143 = 2187 − 15·143 = 2187 − 2145 = 42 ✓

Verifikation liefert $42 = h$ — die Signatur ist gültig.

Signatur $(s = 3)$ gültig für $h = 42$ ✓
R7 · Nachweis der Verifikationsgleichung
Zeige mathematisch, warum aus $s = H(m)^{d} \bmod n$ folgt, dass $s^{e} \equiv H(m) \pmod n$ – ausgehend von der RSA-Schlüsselbedingung $ed \equiv 1 \pmod{\varphi(n)}$.

Beweisführung

Voraussetzung: e · d ≡ 1 (mod φ(n)) ⇒ es existiert k ∈ ℤ mit e · d = 1 + k · φ(n) Berechne s^e mod n: s^e = (H(m)^d)^e = H(m)^(e·d) = H(m)^(1 + k·φ(n)) = H(m) · (H(m)^φ(n))^k Nach Satz von Euler gilt für ggT(H(m), n) = 1: H(m)^φ(n) ≡ 1 (mod n) Damit: s^e ≡ H(m) · 1^k ≡ H(m) (mod n) ✓
Die Verifikationsgleichung $s^{e} \equiv H(m) \pmod{n}$ ist mathematisch garantiert.

Für die Randfälle $\gcd(H(m), n) \neq 1$ funktioniert das Argument über den chinesischen Restsatz weiterhin – siehe RSA-Kapitel.

Übungsfragen

F1 Warum wird nicht die Nachricht, sondern der Hash signiert?
Drei Gründe: (1) Performance – RSA ist teuer, ein 32-Byte-Hash zu signieren ist deutlich schneller als eine mehrseitige Nachricht. (2) Größenbeschränkung – RSA verarbeitet nur Zahlen $< n$; ohne Hash müsste die Nachricht in Blöcke aufgeteilt werden. (3) Sicherheit: RSA ist multiplikativ homomorph, d.h. $s(m_1) \cdot s(m_2) \equiv s(m_1 \cdot m_2) \pmod{n}$. Ohne Hash kann ein Angreifer aus zwei gültigen Signaturen eine dritte für ein Produkt fälschen (existential forgery). Ein kryptographischer Hash zerstört diese Homomorphie, weil $H(m_1 \cdot m_2) \neq H(m_1) \cdot H(m_2)$.
F2 Was ist der Unterschied zwischen einer Signatur und einem MAC?
Ein MAC ist symmetrisch: Sender und Empfänger teilen einen geheimen Schlüssel. Er sichert Integrität und Authentizität zwischen diesen zwei Parteien. Bestreitet der Sender später, die Nachricht erzeugt zu haben, kann der Empfänger es nicht beweisen – schließlich könnte er selbst den MAC berechnet haben. Eine digitale Signatur ist asymmetrisch: Der Sender signiert mit seinem privaten Schlüssel, den nur er kennt. Jeder kann mit dem öffentlichen Schlüssel prüfen. Damit erhält man zusätzlich Nichtabstreitbarkeit und öffentliche Nachprüfbarkeit. Dafür ist die Signatur deutlich langsamer.
F3 Was ist ein X.509-Zertifikat?
Ein X.509-Zertifikat ist eine standardisierte, von einer CA signierte Datenstruktur, die einen öffentlichen Schlüssel an eine Identität bindet. Es enthält u.a. Subject (Inhaber), Issuer (CA), Public Key, Gültigkeitszeitraum, Seriennummer, Signaturalgorithmus, Erweiterungen (z.B. Subject Alternative Names) und die Signatur der CA über all diese Felder. X.509 wird u.a. in TLS/HTTPS, S/MIME, Code-Signing und VPN verwendet.
F4 Wozu dient die Vertrauenskette (Chain of Trust)?
Sie erlaubt es, Vertrauen skalierbar zu delegieren. Statt jedem Endnutzer einzeln zu vertrauen, vertraut ein Client nur wenigen Root-CAs (im Truststore). Die Root-CA signiert Zwischen-CAs, diese signieren Endnutzer-Zertifikate. Der Client verifiziert die Kette Schritt für Schritt bis zu einer bekannten Root und muss so nur einige Dutzend Root-Zertifikate kennen, um Millionen von Endzertifikaten zu prüfen.
F5 Was passiert, wenn der private Schlüssel einer CA kompromittiert wird?
Katastrophal: Alle von dieser CA (und ihren untergeordneten Zertifikaten) ausgestellten Zertifikate werden potenziell wertlos, weil ein Angreifer beliebige gefälschte Zertifikate ausstellen könnte. Konsequenzen: (1) Die CA muss ihr eigenes Zertifikat sofort widerrufen und aus den Truststores der Browser/Betriebssysteme entfernt werden. (2) Alle ausgestellten Zertifikate müssen neu ausgestellt und die alten widerrufen werden (CRL/OCSP). (3) Reputationsschaden – siehe DigiNotar 2011, das nach einer Kompromittierung insolvent ging. Deshalb werden Root-CA-Schlüssel offline in HSMs unter strengen Zeremonien gehalten.
F6 Was ist OCSP und wann wird es benötigt?
OCSP (Online Certificate Status Protocol) ist ein Protokoll zur Online-Statusabfrage einzelner Zertifikate. Ein Client fragt den OCSP-Responder der ausstellenden CA: "Ist Zertifikat mit Seriennummer $X$ noch gültig?" und erhält eine signierte Antwort (good / revoked / unknown). OCSP wird benötigt, wenn ein Zertifikat vor Ablauf widerrufen wurde (z.B. wegen Schlüsselverlust, Kompromittierung, Fehlausstellung). Vorteil gegenüber CRLs: aktueller und kleiner. Nachteil: zusätzliche Latenz und Privacy-Problem (die CA sieht, welche Sites der Client besucht) – gelöst durch OCSP Stapling, bei dem der Server die Statusantwort selbst mitliefert.
F7 Warum bietet RSA-Signatur mit reinem $H(m)$ (ohne PSS) potenzielle Angriffsvektoren?
Beim textbook RSA ohne Padding gilt die multiplikative Homomorphie: Aus zwei gültigen Signaturen $s_1, s_2$ lässt sich $s_1 \cdot s_2 \bmod n$ berechnen – eine gültige Signatur für $H(m_1) \cdot H(m_2) \bmod n$. Ein Angreifer, der den Hashwert für ein solches Produkt konstruieren kann, kann Signaturen fälschen (existential forgery). Weiterhin fehlt Zufälligkeit: gleiche Nachrichten erzeugen identische Signaturen (deterministisch), was Replay-Analysen erleichtert. RSASSA-PSS löst beide Probleme durch Probabilistic Signature Scheme-Padding: Es fügt einen zufälligen Salt und eine Mask Generation Function (MGF) ein, sodass jede Signatur einzigartig und beweisbar sicher ist (im Random-Oracle-Modell).
F8 Was ist eine qualifizierte elektronische Signatur (eIDAS)?
eIDAS (EU-Verordnung Nr. 910/2014) unterscheidet drei Stufen elektronischer Signaturen: einfach (jede Form, z.B. gescannte Unterschrift), fortgeschritten (eindeutig dem Unterzeichner zugeordnet, unter alleiniger Kontrolle des Signaturschlüssels, Änderungen sind erkennbar) und qualifiziert (QES). Die QES erfüllt zusätzlich: Erstellung mit einer qualifizierten Signaturerstellungseinheit (QSCD, z.B. Smartcard, HSM) und Basis auf einem qualifizierten Zertifikat eines gelisteten Vertrauensdienstanbieters. Nur die QES ist in der EU der handschriftlichen Unterschrift rechtlich gleichgestellt und damit z.B. für notariell zu unterzeichnende Dokumente zulässig.
F9 Warum ist DSA nicht deterministisch – und was ist RFC 6979?
Bei jedem Signaturvorgang wählt DSA (und ECDSA) einen frischen zufälligen Wert $k$. Wird $k$ wiederverwendet oder ist vorhersehbar, kann der private Schlüssel aus zwei Signaturen mathematisch rekonstruiert werden – berühmt bei Sonys PS3-Hack 2010. RFC 6979 definiert ein deterministisches Verfahren: $k$ wird per HMAC aus Nachricht und privatem Schlüssel abgeleitet. Dadurch entfällt der Bedarf an einem sicheren Zufallszahlengenerator zur Signaturzeit, ohne dass die Sicherheit reduziert wird.
F10 Warum ist ECDSA in Praxis oft RSA vorzuziehen?
Bei gleicher Sicherheitsstufe hat ECDSA deutlich kürzere Schlüssel und Signaturen (256 Bit ECDSA ≈ 3072 Bit RSA). Das bedeutet: schnellere Signaturerzeugung, weniger Bandbreite (relevant in TLS-Handshakes, Blockchain, IoT), weniger Speicher auf constrained devices (Smartcards, Embedded). Nachteile: komplexere Mathematik, historisch anfällig für schlechte Zufallszahlengeneratoren (siehe F9), und mögliche Patentprobleme bei manchen Kurven. In der Praxis werden gut geprüfte Kurven wie secp256r1 (NIST P-256), Curve25519 und secp256k1 (Bitcoin) verwendet.
F11 Wie unterscheidet sich eine Signatur von einer Verschlüsselung mit demselben RSA-Schlüsselpaar?
Nur die Rollen der Schlüssel sind vertauscht: Verschlüsselung nutzt den öffentlichen Schlüssel des Empfängers ($c = m^{e} \bmod n$) und wird mit dessen privatem entschlüsselt. Signatur nutzt den privaten Schlüssel des Senders ($s = H(m)^{d} \bmod n$) und wird mit dessen öffentlichem verifiziert. In der Praxis warnt jede Krypto-Bibliothek davor, denselben Schlüssel für beide Zwecke zu verwenden – man nutzt getrennte Schlüsselpaare, teils sogar getrennte Algorithmen (z.B. RSA-OAEP zum Verschlüsseln, RSASSA-PSS zum Signieren).
F12 Was ist der Unterschied zwischen einer Signatur und einer Zertifizierung?
Eine Signatur bindet ein Dokument (bzw. dessen Hash) an einen Signierer. Eine Zertifizierung ist ein Spezialfall der Signatur: Eine CA signiert das Zertifikat (also den öffentlichen Schlüssel plus Identitätsdaten) eines anderen Nutzers. Damit bestätigt sie: "Ich habe geprüft, dass dieser Public Key wirklich zu dieser Identität gehört." Ohne diese Zertifizierung wäre ein öffentlicher Schlüssel nur eine Zahlenreihe – man wüsste nicht, wem er gehört. Zertifizierung ist somit die Grundlage, um asymmetrische Kryptographie skalierbar einsetzen zu können.