Diskussion:HMAC

message: "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)
replies: text: 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)
thread_title:  Anmerkungen 

message: 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)
thread_title:  Beweisbare Sicherheit 

message: 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)
replies: text: 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)
thread_title:  Nutzen von ipad und opad? 

message: 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)
replies: text:  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)

text: 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)
thread_title: Zugrunde liegende Hash-Funktion muss nicht Kollisionsresistent sein

message: 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)
replies: text: habs gefixt. --Mario d 16:29, 5. Jul. 2011 (CEST)
thread_title:  QWHF 

message: * 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)
replies: text: 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)
replies: text: sehr gerne, das steht bei mir auch schon laenger auf der liste, mit dem neueren paper  --Mario d 13:08, 13. Nov. 2011 (CET)
thread_title:  Fehlende Belege 

message: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text:  OK, Danke :) 46.115.27.52 14:35, 30. Aug. 2014 (CEST)
thread_title:  Wie den Key auffüllen?