• Hallo liebe Userinnen und User,

    nach bereits längeren Planungen und Vorbereitungen sind wir nun von vBulletin auf Xenforo umgestiegen. Die Umstellung musste leider aufgrund der Serverprobleme der letzten Tage notgedrungen vorverlegt werden. Das neue Forum ist soweit voll funktionsfähig, allerdings sind noch nicht alle der gewohnten Funktionen vorhanden. Nach Möglichkeit werden wir sie in den nächsten Wochen nachrüsten. Dafür sollte es nun einige der Probleme lösen, die wir in den letzten Tagen, Wochen und Monaten hatten. Auch der Server ist nun potenter als bei unserem alten Hoster, wodurch wir nun langfristig den Tank mit Bytes vollgetankt haben.

    Anfangs mag die neue Boardsoftware etwas ungewohnt sein, aber man findet sich recht schnell ein. Wir wissen, dass ihr alle Gewohnheitstiere seid, aber gebt dem neuen Board eine Chance.
    Sollte etwas der neuen oder auch gewohnten Funktionen unklar sein, könnt ihr den "Wo issn da der Button zu"-Thread im Feedback nutzen. Bugs meldet ihr bitte im Bugtracker, es wird sicher welche geben die uns noch nicht aufgefallen sind. Ich werde das dann versuchen, halbwegs im Startbeitrag übersichtlich zu halten, was an Arbeit noch aussteht.

    Neu ist, dass die Boardsoftware deutlich besser für Mobiltelefone und diverse Endgeräte geeignet ist und nun auch im mobilen Style alle Funktionen verfügbar sind. Am Desktop findet ihr oben rechts sowohl den Umschalter zwischen hellem und dunklem Style. Am Handy ist der Hell-/Dunkelschalter am Ende der Seite. Damit sollte zukünftig jeder sein Board so konfigurieren können, wie es ihm am liebsten ist.


    Die restlichen Funktionen sollten eigentlich soweit wie gewohnt funktionieren. Einfach mal ein wenig damit spielen oder bei Unklarheiten im Thread nachfragen. Viel Spaß im ngb 2.0.

Klausurvorbereitung Fragen

Kenobi van Gin

Brillenschlange

Registriert
14 Juli 2013
Beiträge
3.620
Ort
.\
Ich möchte auch an dieser Stelle nochmal anmerken, dass ich das nicht aus Gründen der Werbung oder Abwerbung (was mMn negativ auf uns zurückfallen würde) geraten habe, sondern weil ich bei einer Klausurvorbereitung eine gewisse Dringlichkeit sehe und nicht das Gefühl habe, dass der TS da im g:b aktuell gut aufgehoben ist.
[/OT]
 

Kugelfisch

Nerd

Registriert
12 Juli 2013
Beiträge
2.342
Ort
Im Ozean
Ich zitiere hier einfach einmal die Fragen aus deinem Thread im g:b ...
Erklären Sie den CBC-Modus für eine symmetrische Verschlüsselung. Wie viele Blöcke sind in welcher Weise falsch (d.h. wie viele Bits sind ca. falsch), wenn in einem Block des Geheimtextes bei der Übertragung ein Bit falsch übertragen wird?
Die Funktionsweise ist in https://de.wikipedia.org/wiki/Cipher_Block_Chaining meines Erachtens nachvollziehbar erklärt. Daraus ergibt sich direkt auch die Antwort auf deine Frage: im CBC-Modus wird jeder Block mit dem vorhergehenden Ciphertext-Block XOR-Verknüpft. Tritt nun in einem Ciphertext-Block ein Bitfehler auf, wird das im Allgemeinen - d.h. bei einem kryptografisch sicheren zu Grunde liegenden Cipher - den betroffenen Klartext-Block (vollständig) zerstören. Ausserdem tritt durch die XOR-Verknüpfung mit dem nächsten Klartext-Block dort ein einzelner Bitfehler auf. Daher werden i.A. B+1 Bits zerstört, wobei B die Blockgrösse ist - ein kompletter Block plus ein Bit im darauf folgenden Block.

Warum entspricht die Länge einer digitalen Signatur der Schlüssellänge des asymmetrischen Verfahrens und nicht der Bitlänge der Hashwerte, die mit der Hashfunktion erzeugt werden?
Im Allgemeinen sehe ich keinen Grund, weshalb dem nicht so sein sollte, die mutmasslich gesuchte Antwort ist jedoch, dass die Hashwert-Längen üblicher Hash-Algorithmen viel zu kurz wären, um brauchbare asymmetrische Schlüssel abzugeben. Hash-Werte sind oftmals maximal 512 Bit lang, asymmetrische Schlüssel für z.B. RSA mindestens 2048, besser 4096 Bit.
Frage missverstanden, siehe Beitrag von Skipjack: https://ngb.to/threads/770-Klausurvorbereitung-Fragen?p=21415#post21415

Beschreiben Sie das ARP-Spoofing als typischen, auf TCP/IP beruhenden, Angriff. Was ist der entscheidende Schwachpunkt des ARP-Protokolls. Warum braucht es diesen Angriff nicht im klassischen Ethernet?
Auch hier ist https://de.wikipedia.org/wiki/ARP-Spoofing ein guter Ansatzpunkt. Die Schwachstelle von ARP ist, dass keine Möglichkeit besteht, die Authentizität von Antworten zu sichern, d.h. festzustellen, ob eine ARP-Antwort auch tatsächlich von demjenigen System stammt, dessen IP-Adresse man angefragt hat. Zudem nutzen einige Betriebssysteme auch ARP-Antworten zur Aktualisierung des ARP-Caches, welche sie gar nicht angefragt haben. Das macht es für einen Angreifer natürlich sehr einfach, den ARP-Cache eines Hosts zu `vergiften`, d.h. durch gefälschte ARP-Antworten falsche MAC-Zuordnungen für beliebige IP-Adressen im ARP-Cache zu erzeugen.

Der zweite Teil der Frage ist meines Erachtens unklar formuliert. Mutmasslich ist mit `klassischem Ethernet` ein ungeswitchtes Ethernet-Netzwerk (bestehend aus genau einer Kollisionsdomäne) gemeint, wo ohnehin jeder Teilnehmer jedes Paket sieht und mitlesen kann. Alternativ könnte auch gemeint sein, dass man die SATs handelsüblicher Switches für Privatanwender verhältnismässig leicht überfluten und den Switch damit zum Hub-Fallback zwingen kann (vgl. https://de.wikipedia.org/wiki/MAC-Flooding).

Wie kann mit Hilfe eines Paketfilters die Richtung eines Verbindungsaufbaus bei TCP gefiltert werden (Verbindungsaufbau zulassen in eine Richtung, blockieren in die andere Richtung)?
Grundsätzlich: Indem man ein- bzw. ausgehende Pakete, welche (ausschliesslich) das SYN-Flag im Header gesetzt haben, filtert (verwirft oder aktiv abweist), denn diese initiieren in TCP den zum Verbindungsaufbau notwendigen 3-Wege-Handshake. In der Praxis ist es in der Regel sinnvoll, zusätzlich auch Pakete zu verwerfen, welche keiner zuvor aufgebauten, bekannten TCP-Verbindung zugehörig sind - Stichwort: Stateful Inspection.

Erklären Sie die prinzipielle Vorgehensweise bei der Quantenkryptografie (A kommuniziert mit B, wer macht wann was …). Was passiert, wenn E abhört? Was ist die wesentliche quantenmechanische Voraussetzung für die Funktionsweise? Welchem „klassischen“ Schlüsselaustauschverfahren ähnelt die Quantenkryptografie und warum?
Damit ist wohl der Quantenkryptografische Schlüsseltausch gemeint; https://de.wikipedia.org/wiki/Quantenschlüsselaustausch bietet eine gute Übersicht über das Verfahren. Ein Angreifer, der versucht, die Übertragung abzuhören, verändert durch seine Messungen den Quantenmechanischen Zustand des Systems - die Grundlage hier ist, dass ein Quantenmechanisches Sytem, welches in einer bestimmten beobachtbaren Grösse eine Überlagerung mehrerer Eigenzustände aufweist, durch eine Messung in genau einen dieser Eigenzustände gezwungen wird, dessen zugehöriger Eigenwert dann gemessen wird (welcher das ist, ist - nach einer bekannten Wahrscheinlichkeitsverteilung - zufällig).

Das hier wohl in Frage stehende BB84-Protokoll ähnelt gewissermassen einem Diffie-Hellman-Schlüsseltausch, und zwar insofern, dass beide Teilnehmer zur Schlüsselerzeugung einen geheimen Teil (die Polarisationen) sowie einen öffentlichen Teil (die Information darüber, welche Bits verwendbar sind) nutzen.
 
Zuletzt bearbeitet:

Orothred

Neu angemeldet

Registriert
18 Juli 2013
Beiträge
12
  • Thread Starter Thread Starter
  • #4
Sehr cool, vielen Dank für die Mühe....

Hätte noch ein drei, vielleicht könntest du mir da auch nochmal weiterhelfen :-)

Nennen und erklären Sie grob die jeweils grundlegende Angriffsart für symmetrische
(z.B. AES) und für asymmetrische Verschlüsselungsverfahren (z.B. RSA), welche die
sehr unterschiedlichen Schlüssellängen der beiden Verfahren begründet.


Nennen Sie die drei wichtigsten Anforderungen an die digitale Signatur. Erklären Sie,
wie die digitale Signatur mit Hilfe eines asymmetrischen Verschlüsselungsverfahrens und
einer kryptografischen Hashfunktion realisiert wird.


Erklären Sie, wie typischerweise Passwörter unlesbar abgelegt werden. Wozu diente ursprünglich
das Salt bei der UNIX Passwort“verschlüsselung“ (
 
Zuletzt bearbeitet:

Kugelfisch

Nerd

Registriert
12 Juli 2013
Beiträge
2.342
Ort
Im Ozean
Nennen und erklären Sie grob die jeweils grundlegende Angriffsart für symmetrische (z.B. AES) und für asymmetrische Verschlüsselungsverfahren (z.B. RSA), welche die sehr unterschiedlichen Schlüssellängen der beiden Verfahren begründet.
Wenn man in beidem Fällen von einem sicheren Cipher ausgeht, d.h. Cipher-spezifische kryptoanalytische Angriffe ausser Acht lässt, dann bleibt im Falle von symmetrischen Verfahren lediglich das erschöpfende Durchsuchen des Schlüsselraums nach Schlüssel-Kandidaten, welche `sinnvolle` Klartexte liefern. Das ist nach dem heutigen Stand der Technik selbst bei 128-Bit-Schlüsseln unrealistisch. Bei asymmetrischen Verfahren besteht eine inhärente Schwachstelle durch den mathematischen Zusammenhang zwischen öffentlichem und privatem Schlüssel. Der genaue Zusammenhang ist hängt vom konkreten Verfahren ab, in der Regel kommen Verfahren zum Einsatz, welche sich nur mit sehr hohem Aufwand umkehren lassen - etwa Multiplikation/Faktorisierung bei RSA oder elliptische Kurven (vgl. https://en.wikipedia.org/wiki/Elliptic_curve_cryptography). Im Beispiel von RSA könnte man versuchen, den Modulus zu faktorisieren, und würde dadurch die notwendigen Informationen zur Generierung des privaten Schlüssels (p, q) erhalten.


Nennen Sie die drei wichtigsten Anforderungen an die digitale Signatur. Erklären Sie, wie die digitale Signatur mit Hilfe eines asymmetrischen Verschlüsselungsverfahrens und einer kryptografischen Hashfunktion realisiert wird.
Die `drei wichtigsten` ist leider eine sehr unspezifische Frage. Sicherlich wichtig ist, dass Signaturen
  • Fälschungssicher und kollisionsresistent (weder sollten gezielt Klartexte erzeugt werden können, welche bei Signierung identische Signaturen ergeben, noch sollte das zufällig geschehen),
  • Anhand öffentlicher Informationen verifizierbar und
  • effizient zu berechnen und zu speichern sind.
Üblicherweise wird über den zu signierenden Text der Hash-Wert einer kryptografischen Hash-Funktion gebildet und dieser dann mit dem privaten Schlüssel eines asymmetrischen Schlüsselpaars verschlüsselt. Dadurch kann jeder die Signatur mit Hilfe des öffentlichen Schlüssels entschlüsseln und überprüfen, ob der Hash-Wert zum Klartext passt (indem er selbst den Hash-Wert über den Klartext bildet und ihn mit demjenigen aus der Signatur vergleicht). Es ist zu beachten, dass die verwendete Hash-Funktion sowohl gegen Preimage- als auch gegen Kollisionsangriffe sicher sein muss - ein praxisrelevantes Negativbeispiel war in der Vergangenheit z.B. MD5, was die Fälschung damit signierter X.509-Zertifikate (SSL/TLS) ermöglichte.
 

Orothred

Neu angemeldet

Registriert
18 Juli 2013
Beiträge
12
  • Thread Starter Thread Starter
  • #7
Frag ihn doch direkt, ob er die Klausur für dich schreibt.

Ich denke, es ist erlaubt, hier Fragen zu stellen. Ich denke auch, es ist jedem freigestellt, hier zu helfen. Du willst es anscheinend nicht. Aber dann halt dich doch bitte auch komplett raus ;-)


/edit: Nochmals danke, kugelfisch :-) Zur Frage mit den Angriffen: Ist bei einem von beiden nicht noch Man-In-The-Middle möglich?
 

gerechtigkeit0

Renommierter Pestarzt™

Registriert
15 Juli 2013
Beiträge
337
Das war keineswegs ein persönlicher Angriff, falls du das so gedeutet hast... und normalerweise bin ich nicht so kleinlich.
Aber Kugelfisch gibt sich hier verdammt viel Mühe um deine Fragen zu beantworten.

Im alten Board war es Gang und Gebe, vor der Erstellung eines "Hilfe bei Schul-/Uni-Aufgaben"-Threads vorher Eigeninitiative zu beweisen und die eigenen Fragen vorher selbst versuchen zu beantworten, indem man sie mal bei diversen Suchmaschinen eintippt.
Kugelfisch liefert dir viele Links, die du auch hättest alleine herausfinden können.

Nochmals: Es war nicht böse von mir gemeint - ich erkenne nur keinerlei Eigeninitiative ;)
 

Kugelfisch

Nerd

Registriert
12 Juli 2013
Beiträge
2.342
Ort
Im Ozean
Oh, Frage #3 hatte ich übersehen, bzw. überschnitt sich deine Bearbeitung wohl mit meiner Antwort. Daher:
Erklären Sie, wie typischerweise Passwörter unlesbar abgelegt werden. Wozu diente ursprünglich das Salt bei der UNIX Passwort“verschlüsselung“
Von Passwörtern wird typischerweise nur ein Hash-Wert gespeichert, da dieser einerseits zur Überprüfung des Passworts ausreicht, andererseits dadurch wirksam verhindert wird, dass ein Angreifer, der ein System erfolgreich kompromittiert, die Klartext-Passwörter auslesen kann. In sehr frühen Unix-Systemen waren die Passwort-Hashes sogar öffentlich lesbar (in /etc/passwd, bevor Shadowed-Passwörter und /etc/shadow eingeführt wurden).

Ein (Benutzer- bzw. Hash-spezifisches) Salt erfüllt zumindest zwei wichtige Aufgaben:
  • Es verhindert, dass Benutzer mit identischem Passwort identische Passwort-Hashes erhalten (was sehr effiziente Wörterbuch-Angriffe erlauben würde).
  • Rainbow-Table-Angriffe werden effektiv verhindert.

Nachtrag:
Zur Frage mit den Angriffen: Ist bei einem von beiden nicht noch Man-In-The-Middle möglich?
Auf welche Frage von dir bezieht sich das?

Im alten Board war es Gang und Gebe, vor der Erstellung eines "Hilfe bei Schul-/Uni-Aufgaben"-Threads vorher Eigeninitiative zu beweisen und die eigenen Fragen vorher selbst versuchen zu beantworten, indem man sie mal bei diversen Suchmaschinen eintippt.
Grundsätzlich wäre das sicherlich wünschenswert, ja. Allerdings war ich bereits im g:b bekannt dafür, bei der Auslegung dieser dort selbst in den Boardregeln verankerten Anforderung in den von mir moderierten Foren sehr grosszügig zu sein ;)
 
Zuletzt bearbeitet:

Orothred

Neu angemeldet

Registriert
18 Juli 2013
Beiträge
12
  • Thread Starter Thread Starter
  • #10
Nachtrag:

Auf welche Frage von dir bezieht sich das?

Auf diese:

Nennen und erklären Sie grob die jeweils grundlegende Angriffsart für symmetrische (z.B. AES) und für asymmetrische Verschlüsselungsverfahren (z.B. RSA), welche die sehr unterschiedlichen Schlüssellängen der beiden Verfahren begründet.
 

Kugelfisch

Nerd

Registriert
12 Juli 2013
Beiträge
2.342
Ort
Im Ozean
Dann kann ich deine Nachfrage nur teilweise nachvollziehen. Ob ein Man-in-the-Middle-Angriff möglich ist, hängt vom gewählten Verfahren zum Schlüsseltausch ab, prinzipiell ist er weder bei symmetrischen noch bei asymmetrischen Verfahren auszuschliessen, wenn die Schlüssel über einen unsicheren Kanal übertragen werden. Gegen passives Abhören ist asymmetrische Kryptografie inhärent sicher, da nur die öffentlichen Schlüssel übertragen werden müssen. Bei symmetrischer Kryptografie muss dazu ein spezielles Verfahren zum Schlüsseltausch verwendet werden, z.B. der Diffie-Hellman-Schlüsseltausch.
 

p3Eq

zu nichts zu gebrauchen

Registriert
15 Juli 2013
Beiträge
358
Ein Man in the Middle-Angriff ist grundsätzlich bei symmetrischen und asymmetrischen Verschlüsselungsverfahren möglich. Erst durch weitere Maßnahmen wird ein solcher Angriff zu verhindern versucht.

Bei symmetrischen Verfahren:
Beim Schlüsselaustausch könnte ein Angreifer sich physisch oder logisch in zwischen A und B schalten und so den Netzwerkverkehr manipulieren. Wird das von Kugelfisch angesprochene Diffie-Hellman-Verfahren eingesetzt, um einen Schlüssel zu generieren, so könnte der Angreifer einen gemeinsamen Schlüssel mit A erzeugen und einen weiteren gemeinsamen Schlüssel mit B. Die Botschaften werden dann verschlüsselt von A zum Angreifer übertragen, dort mit Key1 entschlüsselt, mitgelesen und mit Key2 wieder verschlüsselt und zu B gesendet.

Bei asymmetrischen Verfahren besteht ebenfalls die Gefahr, dass die Übertragung von Bs öffentlichen Schlüssels zu A manipuliert wird, sodass der öffentliche Schlüssel des Angreifers nun zu A gesendet wird. A verschlüsselt die Daten also mit dem öffentlichen Schlüssel vom Angreifer und dieser kann die Daten nun entschlüsseln, mitlesen und mit dem wahren öffentlichen Schlüssel von B an B weiterleiten. In der Praxis ist es aus diesem Grund wichtig, dass der öffentliche Schlüssel aller Parteien möglichst bekannt ist, sodass eine Manipulation erkannt werden würde, wenn ein falscher öffentlicher Schlüssel übertragen wird. Daraus resultierte die Idee des Web of Trust (siehe http://de.wikipedia.org/wiki/Web_of_Trust ).
 

Orothred

Neu angemeldet

Registriert
18 Juli 2013
Beiträge
12
  • Thread Starter Thread Starter
  • #13
Klausur war heute und lief denk ich ganz gut, vielen Dank für die großzügige Hilfe :-)
 

Tryndamere

Neu angemeldet

Registriert
23 Juli 2013
Beiträge
49
Hallo ich würde mich dem Thema gerne anschließen und hab da auch ein paar Fragen

Thema SSL Protokoll

Der Handshake ist ja wie folgt definiert (bitte korregieren wenn falsch) [] werden verwendet bei optionalen Dingen wenn es so eingestellt ist.

A --> B
(Hallo ich bin A, habe folgende Verfahren im Angebot, 32 bit Zuffalszahl R_a)

B --> A
(Wir verwenden folgende Verfahren, [Zertifikat], Public Key, [Zertifikatbitte], Zufallszahl R_b)

[A]
Zertifikat prüfen

[A --> B]
Zertifikat schiken B prüft, Public Key

A
genieriert Randomzahl PMS (Pre Master Secret)

A --> B
Encricption_PublicB (PMS)

A und B einzelnd
Berrechnen aus R_a, R_b, PMS = MS (Master Secret), Umstellen auf Synchrone Verschlüsselung mit MS als Schlüssel

Jetzt die Frage: Warum muss Alice PMS bestimmen und warum kann Bob das nicht tun.

Meine Idee:
A muss ja nicht zwingend einen Public, Private Key verwenden, damit kann nicht sichergestellt werden, das B PMS für A verschlüßeln kann. (Beispiel Browser, wenn ich https verwende habe ich ja auch keinen public key für den Server, denn dieser müsste ja bei der optionalen Zertifikatanfrage gesendet werden)

Lieg ich da mit meiner Idee richtig, oder ist das einfach nur falsch?



Zweite frage betrifft Hashfunktionen:

Wie finde ich herraus ob eine Hashfunktion stark Kollisionsresistent bzw. schwach Kollisionsressistent ist?

Def. der Bedingungen:
Für die Hashfunktion h gilt:

stark: Zu einem beliebigen x gibt es ein beliebiges y für das gilt: h(x) = h(y)
schwach: Zu einem bestimmten x gibt es ein beliebiges y für das gilt h(x) = h(y)

aus stark folgt schwach aber nicht umgekehrt

Für das brechen der starken Eigenschaft bin ich über das Schlagwort "Geburtstagsangriff" gestolpert.
In der Prüfung soll die Frage in etwa so aussehen:

Eingaben gegeben(x,y,h), bestimmen ob schwach oder stark Kollisionsresistent


Die dritte frage betrifft den DSA:

Mir ist aufgefallen, das beim DSA Gleitkommawerte rauskommen können(bzw sogar werden) auf die der Modulu Operator angewand wird. Wie soll man sowas im Taschenrechner berechnen?

Beispiel Verifizierung der Signatur

0 < s1,s2 < q (Bedingung DSA)
s2^-1 mod q

d.h.
1/s2 mod q
=> wenn s2 != 1 dann tritt genau dieser Fall auf.

konkretes Beispiel:
auch beim RSA

d = e^-1 mod phi(n)
konkrete Zahlen:
3=23
phi(n) = 60

http://www.wolframalpha.com/input/?i=23^-1+mod%2860%29

Warum kommt 47 raus?

Mit freundlichen Grüßen
 
Zuletzt bearbeitet:

Tryndamere

Neu angemeldet

Registriert
23 Juli 2013
Beiträge
49
d = e^-1 mod phi(n)
konkrete Zahlen:
3=23
phi(n) = 60

http://www.wolframalpha.com/input/?i=23^-1+mod%2860%29

Habe ich glaube nun gelöst:

Ich gehe nun wie folgt vor via Durchprobieren

((k* Phi(n))+1)/e;
k++
solange bsi eine ganze Zahl rauskommt.

Diese Zahl ist dann der private Schlüßel

LG
 

Mr_J

Neu angemeldet

Registriert
14 Juli 2013
Beiträge
991
[...]
Die dritte frage betrifft den DSA:

Mir ist aufgefallen, das beim DSA Gleitkommawerte rauskommen können(bzw sogar werden) auf die der Modulu Operator angewand wird. Wie soll man sowas im Taschenrechner berechnen?[...]

Beziehst du dich da auf irgendein Skript? Eigentlich sollten da keine Gleitkommawerte auftreten.

------

Ablauf DSA:

Schlüsselerzeugung
- Alice erzeugt q mit 2^159 < q < 2^160
- Alice erzeugt eine Primzahl p mit 2^(511+64t) < p < 2^(512+64t) für ein t aus {0, 1, ...,8}; q muss Teiler von p-1 sein
- Alice wählt eine Primitivwurzel x mod p und berechnet g = x^[(p-1)/q] mod p
- Alice wählt a zufällig aus {1, 2, ..., q-1} und berechnet A = g^a mod p
- Der öffentliche Schlüssel ist jetzt (p, q, g, A), der geheime Schlüssel ist a

Erzeugung der Signatur
- Alice möchte Text x signieren, sie verwendet eine kollisionsresistente Hashfunktion h
- Alice wählt Zufallszahl k aus {1, 2, ..., q-1} und berechnet r = (g^k mod p) mod q und s = k^-1 * (h(x) + a*r) mod q
- Die Zahl k^-1 ist das Inverse von k modulo q, die Signatur ist (r,s)

Verifikation
- Bob erhält (r,s) und kennt den öffentlichen Schlüssel (p,q,g,A) von Alice sowie die Hashfunktion h
- Bob verifiziert dass 1 <= r <= q-1 und 1 <= s <= q-1
- Bob verifiziert dass r = ((g^((s^-1 * h(x)) mod q) * A^((r * s^-1) mod q)) mod p) mod q gilt, dann ist die Signatur gültig

Quelle: Einführung in die Kryptographie, Buchmann

Es sollten übrigens weder bei DSA noch RSA Gleitkommawerte auftreten, da diese von der Modulorechnung nicht erlaubt werden.
Beispiel: wenn ich z.B. mit (mod 8) rechne, dann können nur Werte von 0 bis 8 auftreten, sonst nichts.

MfG
Mr. J
 
Zuletzt bearbeitet:

Skipjack

Neu angemeldet

Registriert
17 Juli 2013
Beiträge
213
Auch wenn es für den TS nicht mehr relevant ist. Vielleicht hilft es ja jemand anderem.

Warum entspricht die Länge einer digitalen Signatur der Schlüssellänge des asymmetrischen Verfahrens und nicht der Bitlänge der Hashwerte, die mit der Hashfunktion erzeugt
werden?

Im Allgemeinen sehe ich keinen Grund, weshalb dem nicht so sein sollte, die mutmasslich gesuchte Antwort ist jedoch, dass die Hashwert-Längen üblicher Hash-Algorithmen viel zu kurz wären, um brauchbare asymmetrische Schlüssel abzugeben. Hash-Werte sind oftmals maximal 512 Bit lang, asymmetrische Schlüssel für z.B. RSA mindestens 2048, besser 4096 Bit.

Der Grund ist ein anderer: bei einer digitalen Signatur wird der Hash-Wert des zu signierenden Dokumentes "asymmetrisch verschlüsselt". Das Ergebnis der asymmetrischen Operation ist dann so lang wie der Schlüssel, z.B. bei RSA so lang wie der Modulus. Die Länge des Hash-Wertes hat also keinen Einfluss auf die Länge der Signatur. Randbedingung ist aber i.A. dass die Hash-Länge mit dem gewählten asymmetrischen Verfahren überhaupt verarbeitet werden kann. Z.B. muss bei RSA, der zu verschlüsselnde oder signierende Wert kleiner als der Modulus sein. Da der pure Hash-Wert vor der asymmetrischen Operation noch "verpackt" (Padding) wird, ist der Input für die asymmetrische Operation (der also kleiner als der Schlüssel sein muss) grösser als der eigentliche Hash-Wert. SHA-256 und RSA-768 (was für eine schwachsinnige Kombination) wäre also je nach Padding-Verfahren einfach nicht möglich.

--- Automatisch zusammengeführter Beitrag ---

Thema SSL Protokoll
...
Jetzt die Frage: Warum muss Alice PMS bestimmen und warum kann Bob das nicht tun.
...
Meine Idee:
A muss ja nicht zwingend einen Public, Private Key verwenden, damit kann nicht sichergestellt werden, das B PMS für A verschlüßeln kann. (Beispiel Browser, wenn ich https verwende habe ich ja auch keinen public key für den Server, denn dieser müsste ja bei der optionalen Zertifikatanfrage gesendet werden)

Lieg ich da mit meiner Idee richtig, oder ist das einfach nur falsch?

Die ist richtig. Bei Mutual Authentication (beide haben ein Zertifikat) wäre es prinzipiell egal, aber da es eben auch den Fall der Server-Only Authentication gibt, ist das Protokol so spezifiziert, dass der Client das PMS erzeugt.


Die dritte frage betrifft den DSA:
...

Mir ist aufgefallen, das beim DSA Gleitkommawerte rauskommen können(bzw sogar werden) auf die der Modulu Operator angewand wird. Wie soll man sowas im Taschenrechner berechnen?

...

1/s2 mod q
=> wenn s2 != 1 dann tritt genau dieser Fall auf.

Dein Denkfehler ist, dass Du hier die "Gleitkomma"-Arithmetik verwendest, die auch Dein Taschenrechner kann.
Hier haben wir es aber mit modularer Arithmetik (scheiss Übersetzung) zu tun. 1/s ist nicht "1 dividiert durch s", sondern das modular Inverse zu s.
1/s ist also das Element x für das x*s=1 (mod q) gilt.
Beispiel: q=5, s=3 dann ist 1/s=2 weil 3*2 = 6 mod 5 = 1 ist.

Den Rest musst Du jetzt selber rechnen.
Viel Erfolg.
 

Kugelfisch

Nerd

Registriert
12 Juli 2013
Beiträge
2.342
Ort
Im Ozean
Jetzt die Frage: Warum muss Alice PMS bestimmen und warum kann Bob das nicht tun.

A muss ja nicht zwingend einen Public, Private Key verwenden, damit kann nicht sichergestellt werden, das B PMS für A verschlüßeln kann. (Beispiel Browser, wenn ich https verwende habe ich ja auch keinen public key für den Server, denn dieser müsste ja bei der optionalen Zertifikatanfrage gesendet werden)
Korrekt. Nur der öffentliche Schlüssel des Servers wurde über das ausgelieferte Server-Zertifikat (X.509-PKI) verifiziert. Client-Zertifikate sind unüblich und kommen in der Regel nur dann zum Einsatz, darüber auch eine Authentifizierung erfolgen soll. Alternativ zur rein clientseitigen Generierung des PMS besteht die Möglichkeit, dieses über einen Diffie-Hellman-Schlüsseltausch auszuhandeln, wobei das Zertifikat der Vermeidung von MitM-Angriffen dient.


Eingaben gegeben(x,y,h), bestimmen ob schwach oder stark Kollisionsresistent
Die Fragestellung kann ich so nicht nachvollziehen. Wenn h(), x und y gegeben sind, ist trivial festzustellen, ob eine Kollision der Form h(x)=h(y) vorliegt. Ansonsten stellt sich die Frage, in welcher Form die Hash-Funktion h() gegeben ist - im Allgemeinen Fall, wenn man h() als Black-Box betrachtet, bleibt bloss die Möglichkeit, Kollisionen durch einen Brute-Force-Angriff zu finden. Effizientere Kollisionsangriffe beziehen sich immer auf eine ganz spezifische Hash-Funktion.


Mir ist aufgefallen, das beim DSA Gleitkommawerte rauskommen können(bzw sogar werden) auf die der Modulu Operator angewand wird. Wie soll man sowas im Taschenrechner berechnen?
[...]
s2^-1 mod q
1/s2 mod q
Du hast wohl die Bedeutung von s2^-1 falsch interpretiert. In diesem Fall ist damit nicht 1/s2 (das multiplikativ Inverse von s2 im Körper der reellen Zahlen), sondern das multiplikativ Inverse zu s2 im Restklassenring Z/qZ, was (sofern es denn existiert) durchaus ein Element der zu Grund liegenden Menge und damit eine Ganzzahl zwischen 0 und q-1 ist. Siehe auch https://en.wikipedia.org/wiki/Modular_multiplicative_inverse (wo auch Algorithmen zur vergleichsweise effizienten Berechnung genannt sind).



Nachtrag: Tab nicht aktualisiert, daher Skipjacks Antwort übersehen.
Der Grund ist ein anderer: bei einer digitalen Signatur wird der Hash-Wert des zu signierenden Dokumentes "asymmetrisch verschlüsselt". Das Ergebnis der asymmetrischen Operation ist dann so lang wie der Schlüssel, z.B. bei RSA so lang wie der Modulus
Stimmt, bei nochmaligem Lesen der Frage ist wird klar, dass ich diese falsch interpretiert hatte - nämlich derart, weshalb als Schlüssel das Ergebnis einer Hash-Funktion hinsichtlich seiner Länge nicht in Frage kommen würde. Du hast selbstverständlich Recht, danke für die Korrektur.
 
Zuletzt bearbeitet:

Tryndamere

Neu angemeldet

Registriert
23 Juli 2013
Beiträge
49
danke für deinen Beitrag

Was modulare Artithmetik angeht bin ich inzwischen schon einen Tatsch weiter dank den Links und viel gebastel. Ich häng noch ein bisschen an der Inverse, aber das wird schon, muss nur noch rauskriegen, wie die Zahlen ich nenne es mal "zerlegt"

das z.B. aus 27/47 =(3 Striche) 27 * -21 wird. daraus lässt sich das alles dann einfach berechnen.

Das wird schon noch *g*.

Aber das gute, durch das viele Knobeln bin ich inzwischen sogar schon so weit das ich die Algorithmen auswendig kann :-).

Soweit ich das sehe hängt es bei mir nämlich im großen ganzen nur noch am Kerberos System (muss ich nochmal genau recherchieren), Kollisionsresistenz bestimmen und an dem modulo.

wobei ich bei der definition der Aufgabe mir die gleiche Frage gestellt habe wie Kugelfisch, ich hab gedacht ich kenne irgendein Verfahren(Bei der Hash VL war ich krank, das Skript relativ kurz gehalten) nicht mit dem sich das Allgemein bestimmen lässt etc.
LG
 
Zuletzt bearbeitet:
Oben