Diskussion:HMAC

Anmerkungen

"Die grundlegende Idee ist, das man die Nachricht mit einem geheimen Schlüssel verknüpft und davon einen Hash-Wert berechnet"

Heisst verknüpfen einfach nur konkatenieren ? Is das net bissi...."arm" ?(nicht signierter Beitrag von 84.178.44.140 (Diskussion) 15:10, 27. Jul. 2005 (CEST))

Kryptographische Algorithmen sind (bis auf eine Ausnahme) bisher nicht "beweisbar sicher"!(nicht signierter Beitrag von 141.24.146.4 (Diskussion) 12:47, 14. Okt. 2005 (CEST))

Beweisbare Sicherheit

Beweisbar sicher sind kryptographische Verfahren nur unter bestimmten Voraussetzungen, die entweder nicht vollständig zutreffen oder selbst nicht beweisbar sind. Für den HMAC kann die Sicherheit unter der Voraussetzung der Sicherheit der Hashfunktion H bewiesen werden, sofern diese eine kollisionsresistente Einweg-Funktion ist.

Beim HMAC wird das Argument der (äußeren) Hashfunktion als Funktion der Nachricht N und des Schlüssels berechnet.

MAC = H(f(N,K))

Sofern H als sicher betrachtet werden kann, genügen zwei Bedingungen erfüllen.

• Es ist praktisch unmöglich zwei unterschiedliche Wertepaare (K,N) und (K',N') zu finden, so dass

f(K,N) = f(K',N') gilt.

• Es ist praktisch unmöglich aus f(K,N) und N für eine andere Nachricht N' den Wert f(K,N') zu berechnen.

Die erste Bedingung ist auch durch einfaches Zusammensetzen

f(K,N) = K || N

erfüllt, die zweite jedoch nicht. Für

f(K,N) = K || N || K

ist auch die zweite Bedingung erfüllt. Die zweite Bedingung ist auch verzichtbar, falls f(N,K) eine feste Länge besitzt. Daher ist auch die Wahl

f(K,N) = H(K,N)

möglich. Die zweite Bedingung ist in der Regel erforderlich, da z.B. bei SHA-1 unter Beachtung der Paddingvorschrift die Nachricht so verlängert werden kann, dass der Hashwert der verlängerter Nachricht aus dem letzten Block der Nachricht und dem Hashwert berechenbar ist. Eine verlängerte Nachricht wäre jedoch erkennbar manipuliert.

Die Sicherheit des Verfahrens hängt also nicht wesentlich von der Art der Verknüpfung ab. Neben dem einfachen Hintereinanderschreiben benutzt der HMAC-Standard eine XOR-Verknüpfung mit zwei unterschiedlichen Konstanten, ein Auffüllen von K auf 512 Bit, sowie eine äußere und eine innere Hashfunktion.

Das Verfahren ist damit sicher, sofern die Hashfunktion als sicher gelten kann. Falls H Schwächen aufweist, ist jedoch die Sicherheit nicht zwingend gefährdet. Es ist sehr zweifelhaft, ob da noch etwas wesentliches verbessert werden könnte. Der Schlüssel kann übrigens beliebig lang gewählt werden.(nicht signierter Beitrag von Fsswsb (Diskussion | Beiträge) 10:06, 16. Mai 2006 (CEST))

(H)MAC als elektronische Signatur

Ein (H)MAC ist im kryptografischen Sinne keine Signatur: Eine wesentliche Anfordeung an eine Signatur ist, dass die Nachricht mittels der Signatur eindeutig einer Quelle zugeordnet werden kann.

Das ist bei einem (H)MAC nicht der Fall, da neben dem Sender ("Alice") auch der Empfänger ("Bob") über das Geheimnis K verfügen muss, um die Integrität der Nachricht prüfen zu können. Dadurch ist aber nicht mehr zweifelsfrei nachweisbar, von wem die Nachricht stammt: Alice oder Bob. D. h. MACs können nur verwendet werden, falls sich Sender und Empfänger gegenseitig vertrauen.

Ich weiß allerdings nicht, was das deutsche Signaturgesetz diesbezüglich regelt. Man könnte ein MAC-Verfahren einsetzen, wenn die Parteien über eine vertrauenswürdige dritte Instanz (z. B. einem Notar) miteinander kommunizieren. Diese nimmt eine Prüfung und "Umsignierung" aller Nachrichten vor. Sie benötigt dazu die jeweiligen Geheimnisse Ki aller Parteien.(nicht signierter Beitrag von 194.39.218.10 (Diskussion) 13:03, 23. Mai 2006 (CEST))

Es ist ein Irrglaube, dass ein kryptographisches Verfahren alleine die Identität des Senders belegen könne. Ein vertrauenswürdiger Dritter ist dazu immer unverzichtbar. Bei einer RSA-Signatur ist dieser erforderlich, um die Zuordnung des Public Key in einem Zertifikat zu einer Person zu ermöglichen.

Das ist schon richtig. Bei einem MAC-Verfahren kommt aber hinzu, dass mehrere Personen Kenntnis von dem Geheimnis haben müssen.

Auf der anderen Seite kann eine verbindliche Signatur auch mit einem MAC realisiert werden. Dazu ist lediglich der MAC-Wert an die vertrauenswürdige dritte Instanz sicher zu übertragen. Der "Notar" benötigt keine weiteren Informationen. Es genügt vollkommen, falls durch diese Instanz belegt wird, dass der Sender einen bestimmten MAC-Wert zu einem bestimmten Zeitpunkt eingereicht hat. Der Datenaustausch kann sonst völlig unabhängig von dem elektronischen "Notar" erfolgen. Die Datenmengen, die dabei mit dem "Notar" ausgetauscht werden und archiviert werden müssen, ist minimal (typisch 20 Byte). Technisch ist die Hinterlegung mit bewährten Verfahren wie z.B. dem PIN/TAN-Verfahren möglich.

Wenn aber das Geheimnis mehreren Personen - außer dem "Notar" - bekannt ist, wie kann dann entschieden werden, wer den MAC erzeugt hat?

Durch ein geeigenetes Verfahren, wie z.B. das im Zahlungsverkehr weit verbreitete PIN/TAN Verfahren, wird der MAC-Wert nachweislich durch eine Person beim "Notar" eingereicht. Diese kann dann nicht ableugnen das zugehörende Dokument elektronisch signiert zu haben. Er ist also verpflichtet einen auf diese Weise unterzeichneten Vertrag zu erfüllen. Das der Empfänger diesen MAC auch erstellt haben könnte, ist dabei im Prinzip unerheblich. Letztlich könnte sogar ein Hashwert statt dem MAC verwendet werden. Die Sicherheit ist aber erhöht, wenn nur der Unterzeichner und im Prinzip auch der Empfänger, jedoch kein Dritter, den MAC erzeugen kann. Falls sich die Vertragspartner vertrauen kann auf den Notar auch verzichtet werden. Ein Nachweis der Hinterlegung beim Notar wird nur in Außnahmefällen erforderlich sein, wie es auch bei der handschriftlichen Unterschrift nur selten zu einer Überprüfung durch einen Schriftsachverständigen kommt. Die handschriftliche Unterschrift kann im übrigen noch viel einfacher gefälscht werden als eine elektronische Signatur und ist in der Praxis kaum zuverlässig zu überprüfen. Der Schlüssel zur Signatur könnte nur zwischen den Vertragsparteien vereinbart werden. Es kann jedoch auch ein vom "Notar" der Person zugeordneter Signaturschlüssel verwendet werden. Dies kann gegebenfalls beim "Notar" wieder gelöscht werden.

Wie eine elektronische Signatur definiert ist, kann man hier nachlesen.(nicht signierter Beitrag von Fsswsb (Diskussion | Beiträge) 23:06, 23. Mai 2006 (CEST))

Dort ist hauptsächlich festgelegt, was eine Signatur nach dem deutschen Signaturgesetz ist. Dies ist aber nicht die einzig mögliche/relevante Definition. In der Literatur finden sich weitere und präzisere (als im Wikipedia Artikel) Definitionen; z. B. in C. Eckert, "IT-Sicherheit", 2. Auflage, Oldenbourg Verlag, 2003; Abschnitt 8.2.1, Anforderungen [an elektron. Signaturen], u. a.: "Identifikation: Die Unterschrift gibt Auskunft über die Person des Unterzeichners."(nicht signierter Beitrag von 194.39.218.10 (Diskussion) 10:49, 24. Mai 2006 (CEST))

Diese Definition von C. Eckert ist aber rechtlich kaum relevant.(nicht signierter Beitrag von Fsswsb (Diskussion | Beiträge) 22:37, 24. Mai 2006 (CEST))

Nutzen von ipad und opad?

Welchen Nutzen haben denn ipad und opad? Mit einem sicheren Hash als Grundlage sollte diese Transformation doch unnötig sein, oder? Kann das jemand erklären und in den Artikel schreiben? --Tbleher 12:35, 26. Apr. 2008 (CEST)

Sehe ich auch so. Verschiedene Werte von ipad und opad könnten allerdings benutzt werden, um verschiedene (geheime) HMAC-Varianten zu erstellen. --WikiDiskussion 14:54, 19. Jul. 2010 (CEST)

Zugrunde liegende Hash-Funktion muss nicht Kollisionsresistent sein

Aus dem Quellen-Baustein:

Dafür das die Hash-Funktion nicht Kollisionsresistent sein muss hät ich gerne eine Quelle.--Schönen Gruß "Wohingenau" 20:46, 6. Apr. 2010 (CEST) -- Lieber Wohingenau, jede Hashfunktion, deren Ursprungsmenge (viel) größer ist als die Zielmenge ist nicht kollisionsresistent. Es findet sich nämlich keine eineindeutige Abbildung statt. Schöne Grüße.

Etliche Hashfunktion wie SHA-1 sind nach heutigem Stand kollisionsresistent, das heißt, Kollisionen, die es natürlich gegen muss, weil mehr Nachrichten als Hashwerte denkbar sind, können nicht gefunden werden. Für die Sicherheit sollte aber ausreichen, wenn zu einem gegebenen HMAC keine Nachricht gefunden werden kann, mit genau diesem HMAC. Es erscheint aber zweckmäßig Funktionen zu verwenden, die nach heutigem Stand kollionsresistent sind. --WikiDiskussion 14:50, 19. Jul. 2010 (CEST)

Man kann auch (theoretische?) Hash-Funktionen konstruieren die auch für viel größere Ursprungsmengen kollisionsresistent sind (siehe Merkles_Meta-Verfahren). So oder so ergibt es für mich keine Sin wenn man im Artikel (als auch in dem RFC) Anforderunge an die Hash-Funktion stellt und dann sagt, ach dass ist eigentlich egal... Da wäre eine verständliche Erklärung und noch besser eine ordentliche Quelle für angebracht. Deshalb hab ich den Baustein wieder eingefügt. Ansonsten kann man wegen mir den Absatz auch gerne löschen wegen fehlender Quellen, denk aber dass es so besser für den Artikel ist.--Schönen Gruß "Wohingenau" 23:38, 21. Apr. 2010 (CEST)

Verstehe ich nicht. Der HMAC kann für (praktisch) beliegige Nachrichten berechnet werden? Was soll unter größeren Untermengen zu verstehen sein? (nicht signierter Beitrag von WikiDiskussion (Diskussion | Beiträge) 14:54, 19. Jul 2010 (CEST))

QWHF

Was ist QWHF? Sollte das vielleicht OWHF heißen und ist ein Tippfehler? Sowohl Google als auch der verlinkte Artikel sagen mir nichts über QWHF. -- 84.112.151.6 16:53, 3. Jul. 2011 (CEST)

habs gefixt. --Mario d 16:29, 5. Jul. 2011 (CEST)

Fehlende Belege

• unter "eigenschaften" wird vorausgesetzt, H sei kollisionsresistent. daraufhin habe ich den einzelnen, zusammenhangslosen satz aus der einleitung geloescht, der etwas anderes behauptet hat. ohne belege und eine praezise analyse wuerde ich MD5 hier auch nicht empfehlen wollen.
• wird HMAC wirklich zur eletronischen signatur eingesetzt? das erscheint mir merkwuerdig, deshalb haette ich dafuer gerne eine quelle.

--Mario d 16:44, 5. Jul. 2011 (CEST)

Ich finden diesen Abschnitt ebenfalls seltsam. In [Bellare et al.] gibt es eine Sicherheitsanalyse mit Annahmen. Diesen Artikel würde ich für eine Überarbeitung verwenden.-- JensLechtenboerger 19:45, 11. Nov. 2011 (CET)

sehr gerne, das steht bei mir auch schon laenger auf der liste, mit dem neueren paper Mihir Bellare: New Proofs for NMAC and HMAC: Security without Collision-Resistance. In: Advances in Cryptology – Crypto 2006 Proceedings. Springer, 2006, S. 602–619, doi:10.1007/11818175_36 (Link).  --Mario d 13:08, 13. Nov. 2011 (CET)

Warum doppelt Hashen?

Was ist an einem einfachen H( Key || Message ) oder H( Message || Key ) nicht ausreichend? Ich sehe nicht, wie man bei diesem einmaligen Hashen die Nachricht verfälschen könnte, ohne dass der Hashwert sich ändert (außer durch BruteForce). --RokerHRO (Diskussion) 09:13, 29. Apr. 2012 (CEST)

wenn die hashfunktion eine Merkle-Damgård-Konstruktion ist, haengt die sicherheit deiner ersten konstruktion einzig an der finalisierungsfunktion. dass du oder ich keinen angriff erkennen koennen, bedeutet einfach gar nichts. kannst du beweisen, dass es keinen gibt? bei der HMAC-konstruktion geht das - und zwar nur aufgrund von annahmen an die kompressionsfunktion, nicht an die ganze hashfunktion [1]. --Mario d 10:45, 29. Apr. 2012 (CEST)

Dass eine Aussage "ich sehe keinen Angriff" in der Kryptographie nichts wert ist, ist mir klar. :-)

Mein Satz war auch eher dazu gedacht. eine Antwort zu provozieren, die grob skizziert, wie ein möglicher Angriff auf meinen einfachen Algorithmus aussehen würde. Der engl. WP-Artikel erwähnt zumindest, dass diese beiden von mir genannten Methoden nicht sicher sind, allerdings verstehe ich die dort angegebene Begründung auch nicht. Daher wäre ich froh, wenn der dt. WP-Artikel das auf eine Weise erklären würde, die man zumindest in Ansätzen verstehen (und dann auch Dritten weiter erklären) kann, ohne sich von einem Fachartikel zum nächsten durchhangeln zu müssen. --RokerHRO (Diskussion) 11:35, 29. Apr. 2012 (CEST)

das haettest du auch direkt sagen koennen :) ich habe in dem moment nicht daran gedacht, in die englische version zu schauen, mein erster satz skizziert allerdings den gleichen angriff ("length-extension attack"). danke auf jeden fall fuer den tipp, ich werde die erklaerung gleich in den artikel einbauen. --Mario d 12:01, 29. Apr. 2012 (CEST)

Ich bin gespannt und werde dann den OMA-Test machen. :-) --RokerHRO (Diskussion) 12:34, 29. Apr. 2012 (CEST)

hat ein bischen gedauert, weil ich noch auf einer anderen baustelle war. ich wuerde mich freuen, wenn du mal drueberschaust. --Mario d 15:41, 29. Apr. 2012 (CEST)

Sieht erstmal gut aus, auch wenn ich es inhaltlich nicht verifizieren kann. Eine Frage hab ich noch: Haben MD5 und SHA "keine Finalisierungsfunktion, die nicht trivial umkehrbar ist"? --RokerHRO (Diskussion) 16:18, 29. Apr. 2012 (CEST)

danke, das freut mich. MD5 und SHA-1 sind beide plain Merkle-Damgård, ohne finalisierung. fuer beide gibt es kollisionsangriffe, also sind sowohl fuer MD5 als auch fuer SHA-1 die H(m,k) und H(k,m)-konstruktionen unsicher, fuer HMAC sind sie aber noch gut genug (gerade so, d.h. es gibt keine praktischen angriffe). mindestens MD5-HMAC ist aber keine PRF, es gibt einen algorithmus, der die ausgabe von zufall unterscheidet (s. RFC 6151). --Mario d 17:31, 29. Apr. 2012 (CEST)

Wie den Key auffüllen?

Im Artikel steht, dass K (der Key), wenn er kürzer ist als die Blocklänge B der Hashfunktion, auf deren Länge aufgefüllt werden soll. Wie das bewerkstelligt werden soll wird nicht genannt. Laut der englischen Wikipedia-Seite ("K is a secret key padded to the right with extra zeros to the input block size of the hash function, or the hash of the original key if it's longer than that block size") soll der Key einfach mit Null-Bytes aufgefüllt werden, bis die Blockgröße der verwendeten Hashfunktion erreicht ist (meistens 512Bit bzw. 64Byte). In RFC2014 hingegen wird zwischen der Blockgröße ("B") und der Länge der Ausgabe der Hashfunktion ("L") unterschieden. Bsp.: Bei MD5 wäre B 64Byte aber L nur 16Byte. Die Spezifikation sagt jetzt, dass der Key mindestens L-Byte lang und pseudozufällig sein soll. An diesen >=L-Byte großen Key werden nun so viele Null-Bytes angefügt, wie man braucht, um auf die Länge B zu kommen.

tl;dr Der Key muss mindestens so lang wie die Ausgabe der Hashfunktion und pseudozufällig sein. An ihn werden dann so viele Null-Bytes angehängt, bis so groß wie die Blockgröße der Hashfunktion ist. Das würde ich auf jeden Fall noch in den Artikel schreiben.

Die Pseudozufälligkeit schließt außerdem aus, dass vom Benutzer gewählte Passwörter einfach übernommen werden können. Jetzt stellt sich die Frage, wie man ein vom Benutzer gewähltes Passwort so stärkt, dass man es für den HMAC benutzen kann. scrypt? Oder ist das überhaupt nicht vorgesehen?

KizzyCode (Diskussion) 19:40, 26. Aug. 2014 (CEST)

danke fuer den hinweis, das wollte wirklich in den artikel. zu deiner frage: wenn ein passwort wenig entropie hat, wird kein deterministisches verfahren diese entropie erhoehen. auch wenn du scrypt anwendest, kann man die passwoerter noch aufzaehlen, es ist nur in der praxis aufwaendiger. was willst du denn erreichen? --Mario d 19:19, 28. Aug. 2014 (CEST)

Naja, bevor es Betriebsmodi für Authentifizierung und Verschlüsselung in einem gab, wurden die Daten mit einem Passwort verschlüsselt und dann ein HMAC der Daten angehängt, um ihre Integrität überprüfbar zu machen (das macht man wohl manchmal auch noch heute). Welcher Schlüssel wurde für den HMAC gewählt? Das Passwort, das ja potenziell deutlich kürzer ist als L und selten pseudozufällig ist? Soweit ich weiß werden Verfahren wie scrypt oder Vorgänger verwendet, um die geringere Entropie durch erhöhten Rechenaufwand auszugleichen. Die Frage ist, ob das auch bei einem HMAC sinnvoll wäre. Und wenn nicht, wie hat man das bewerkstelligt? KizzyCode (Diskussion) 19:27, 28. Aug. 2014 (CEST)

das klingt etwas konfus. daten werden nicht mit einem passwort verschluesselt, sondern mit einem schluessel. das gleiche gilt fuer HMAC. welcher schluessel gewaehlt wird, haengt von der anwendung und den verfahren ab. das passwort direkt als schluessel zu verwenden klingt ziemlich unsinnig. spontan fallen mir mehrere unterschiedliche ansaetze ein. man kann zwei zufaellige schluessel waehlen, einen zum verschluesseln, den anderen zum MACen, und diese dann mit dem passwort schuetzen. die beiden schluessel muessen dann mit uebertragen werden, aber nur einmal. man kann auch einfach mit einem PAKE (password-authenticated key exchange) einen schluessel austauschen und den verwenden. oder man leitet mit einer key derivation function (KDF) wie scrypt einen schluessel direkt aus dem passwort ab. es gibt auch KDFs, die auf HMAC basieren. es gibt jedenfalls nicht den einen richtige weg, die rahmenbedingungen und das key management spielen immer eine rolle. --Mario d 14:29, 30. Aug. 2014 (CEST)

OK, Danke :) 46.115.27.52 14:35, 30. Aug. 2014 (CEST)