Diskussion:Message Authentication Code

Ich glaub da ist ein kleiner Widerspruch im Artikel.

Im Text steht zum Einen: "Ein MAC wird erzeugt, indem eine kryptografische Hashfunktion, die ein Passwort (symmetrischen Schlüssel) enthält, auf die Nachricht angewandt wird."

Und unten dann: "MAC auf der Basis von Hash-Funktionen heißen HMAC."

Das heißt dann doch: Alle MAC sind gleichzeitig HMAC, weil sie ja alle mit Hashfunktionen arbeiten Stimmt das oder hab ich irgendwo nen Denkfehler

Du hast recht. Es ist extrem unsauber formuliert, hier nochmal kurz wie ich es sehe (Referenz: Claudia Eckert, IT-Sicherheit, 2005). MAC dient zur Absicherung von Hash Funktionen durch einen Schlüssel. Hintergrund ist, dass man bei normalen Hashes zwar prüfen kann, ob sie zu den Daten passen, man weiß aber nicht ob der Hash auch vom Urheber der Daten stammt. (Angreifer könnten Daten verändern und den Hash entsprechend neu generieren) Deshalb wird dem Hash noch ein Schlüssel beigefügt. Dieser Schlüssel wird zum Beispiel einfach an das Ende der Daten angehängt und mitgehasht, den Schlüssel kennt ein Angreifer nicht und kann deshalb keinen gültigen Hash für (verfälschte) Daten generieren.

HMAC ist ein Spezialfall. Hier wird der Schlüssel nicht irgendwie an die Nachricht gehängt, sondern der Schlüssel bildet den Initialisierungsvektor der Hashfunktion. Dieser Initialisierungsvektor ist bei normalen Hashfunktionen fest vorgegeben, ihn durch den Schlüssel zu ersetzen führt also dazu, dass jeder eine persönliche Variante der Hashfunktion "entwickeln" kann.

Problem von MAC ist, dass der Schlüssel beiden Kommunikationspartnern zur Verfügung stehen muss, gegenüber allen anderen aber geheim sein muss. Es kann nicht einfach wie bei asymmetrischen Signaturverfahren irgendwo ein Public Key veröffentlicht werden, weshalb MAC nicht sonderlich gut skaliert.

Ich habe im Moment leider keine Zeit das mal ordentlich (im Artikel) zu formulieren, es sollte aber unbedingt getan werden, so wie's da steht ist es unbrauchbar, vielleicht sogar falsch. --JonKowal 13:55, 18. Nov 2005 (CET)

unverständliche Einleitung

In der Kryptographie bezeichnet der Message Authentication Code (MAC) einen erzeugten Prüfteil eines Authentikationscodes... Unverständlich ist vor allem dass der MAC als Prüfteil eines Authentikationscodes bezeichnet wird. Meiner Verständnis nach ist der MAC der Prüfteil der Nachricht. Ausserdem verstehe ich den MAC als einen speziellen Authenticationscode und zwar zur Verschlüsselung von Nachrichten. --Avron 09:04, 19. Jul. 2007 (CEST)

Ok, ist in der tat etwas mißverständlich. der mac ist ein prüfteil, der für eine spezielle nachricht gebildet und dieser angehängt wird. soweit scheint das ja klar zu sein. ein authentikationscode ist das zugrundeliegende symmetrische system / verfahren zur authentikation. mit dem mac alleine kann noch gar nichts erreicht werden. er sagt ja z.b. nichts darüber aus, daß im vorfeld ein geheimer schlüssel zwischen sender und empfänger zu vereinbaren und auszutauschen ist. dein zweiter punkt ist dagegen falsch. der mac dient lediglich als prüfteil und wird zusätzlich zur nachricht übersendet. natürlich werden meist authentikation und verschlüsselung kombiniert, sogar die reihenfolge ist prinzipiell bis auf kleine unterschiede egal, also ob zuerst authentisiert und das verschlüsselt wird oder umgekehrt. das originäre verfahren aber verschlüsselt nicht. nebenbei, du kannst mich natürlich mit stichhaltigen quellen gern eines besseren belehren. gruß --Murkel ^(anmurkeln) 14:27, 19. Jul. 2007 (CEST)

Sorry, im zweiten Teil habe ich natürlich Bullshit geschrieben. Sollte heissen: Ausserdem verstehe ich den MAC als einen speziellen Authenticationscode und zwar zur Sicherung von Nachrichten. --Avron 16:44, 19. Jul. 2007 (CEST)

Jetzt habe ich mir deine Antwort noch mal durchgelesen. authentikationscode ist das zugrundeliegende symmetrische system / verfahren zur authentikation Naja, die Wortwahl ist nicht gerade glücklich. Ein Code ist erst mal kein Verfahren. Das Athentikationscode-Verfahren ist ein Verfahren. --Avron 16:59, 20. Jul. 2007 (CEST)

über die wortwahl kann man sich ja immer streiten. zugegeben ich finde die bezeichnung auch nicht besonders toll - habs so gelehrt bekommen. aber nach namen sollte man nun nicht immer gehen: der diffie-hellman-schlüsselaustausch ist ja auch kein schlüsselaustausch ;)

wie bereits vorgeschlagen, wenn du aus der literatur eine treffendere begrifflichkeit kennst, dann füge sie bitte ein. mein anliegen in diesem fall besteht darin, daß prüfteil und verfahren nicht mit dem gleichen wort versehen werden. gruß --Murkel ^(anmurkeln) 18:28, 20. Jul. 2007 (CEST)

Dem Anliegen Murkels stimme ich vollkommen zu. Es vereinfacht den Lesefluss und das Verständnis des Lesers. Beispielsweise würde ich, ohne eine entsprechende Vorlesung belegt zu haben, 'Message Authentication Code (MAC)' als die Erweiterung der Nachricht und 'MAC-Verfahren' als den Prozess der Erstellung des MAC vor dem Senden der Nachricht und das Überprüfung der Authentizität/Integrität nach dem Empfangen derselbigen begreifen. Eine Aufstellung wie im Falle des Artikels über die Diffie-Hellman-Schlüsselvereinbarung ist zweckmäßig.

Ein weiterer Hinweis für die Einleitung: Überflüssige Adjektive, wie 'erzeugter' vor Prüfteil oder 'gesendete' vor Nachricht, können entfallen. Falls du damit gegebenenfalls ausdrücken möchtest, dass MACs ihre Verwendung bei Datenübertragungen finden, so versichere ich dir, dass dies 'Nachricht' impliziert. Weniger, dafür mehr sinntragende Adjektive erleichtern ebenso den Lesefluss. -- Kunsv 16:12, 10. Sep. 2010 (CEST)

>Ein Angreifer kann die Nachricht zwar ändern, da er aber den geheimen Schlüssel nicht kennt, kann er keinen gültigen MAC für die veränderte Nachricht erstellen. Hmm, aber bei einer Man-in-the-middle-attack kennt doch der Angreifer die geheimen Schlüssel, weil er ja vorgaukelt der jeweils andere zu sein? Er kann doch den MAC von Alice entfernen und einen neuen für Bob generieren, oder?

Widerspruch

In der Einleitung steht: "Authentifizierungscodes sind informationstheoretisch sichere symmetrische Authentifizierungsverfahren und gewährleisten die Integrität und Authentizität elektronischer Daten und Nachrichten" Weiter unten im Kapitel "Bezug zu Digitalen Signaturen" heisst es aber: "Da jeder, der einen MAC verifizieren kann, auch einen MAC erstellen kann, ist im Gegensatz zu digitalen Signaturen die Authentizität nicht gewährleistet."

Es ist richtig, dass der Empfänger einer Nachricht einen gültigen MAC erzeugen kann, da er im Besitz des symmetrischen Schlüssels ist. Ich denke aber, die Authentizität ist sichergestellt, aber nicht die Verbindlichkeit (non-repudiation). Der Sender kann immer abstreiten, die Nachricht gesendet zu haben und behaupten, sie sei vom Empfänger erstellt werden. --213.3.105.222 20:40, 28. Jul. 2009 (CEST)

der satz ist wirklich etwas unglücklich; ich habe ihn daher entfernt. jedes verfahren muss natürlich bestimmungsgemäß verwendet werden, damit die gewünschten konsequenzen, also hier die authentizität, auch eintreten. gruß Murkel ^(anmurkeln) 08:05, 29. Jul. 2009 (CEST)

Belege fehlen

Es gibt keinen einzigen Beleg. Woher stammt der Begriff "Prüfteil"? Ist der hier erfunden worden? Wer sagt, dass MACs "zur Authentifizierung einer gesendeten Nachricht" dienen? Was soll das bedeuten? (Bei Eckert: IT-Sicherheit kann man lesen, dass die "Authentizität von Daten" im Zusammenhang mit MACs häufig irreführend behauptet wird.) Woher kommt das Beispiel? Woher die "Sicherheitsanalyse"? Woher die "Eigenschaften"; was ist dort der "allgemeine Fall"? -- JensLechtenboerger 20:50, 26. Okt. 2011 (CEST)

der abschnitt ueber das inf.th. sichere verfahren ist nicht besonders gut geschrieben und es die belege fehlen, ich wuerde den text aber gerne noch behalten; er laesst sich sicherlich verbessern. --Mario d 23:08, 2. Nov. 2011 (CET)

ich habe hier was gefunden. folie 24 ist recht genau das beispiel, folie 25 und 26 die sicherheitsanalyse. leider gibt es dort keine literaturangaben. --Mario d 22:18, 3. Nov. 2011 (CET)

Ich ahne, worum es geht. Sehe ich richtig, dass ich mindestens ein MAC-Bit pro Nachrichten-Bit einsetzen sollte? Dann wäre das kein MAC (beide von mir angegebenen Bücher fordern eine feste Länge für MACs, das gehört vermutlich in die Einleitung).-- JensLechtenboerger 17:37, 5. Nov. 2011 (CET)

da hast du natuerlich recht, daran hatte ich nicht gedacht. die frage ist, ob wir es trotzdem hier behandeln, oder dafuer einen neuen artikel aufmachen. ich muesste mich nochmal in Carter-Wegman reinlesen, evtl. koennte man die authentifikationscodes als vorspiel dazu nehmen.

des weiteren gefaellt mir die praesentation nicht so ganz. in abschnitt 1 tauchen jetzt unvermittelt hashfunktionen auf, vermutlich basierend auf der def. von MAC als familie von hashfunktionen (oder keyed hash function); in naechsten abschnitt heisst es jedoch "MACs basieren entweder auf Blockchiffren oder auf Hash-Funktionen". das ist zwar beides richtig, muesste aber noch besser integriert werden. --Mario d 20:40, 5. Nov. 2011 (CET)

Du hast recht, ich schiebe das in einen erweiterten Abgrenzungsabschnitt.-- JensLechtenboerger 11:33, 6. Nov. 2011 (CET)

das ist auch eine gute loesung. --Mario d 13:04, 6. Nov. 2011 (CET)

Fehler in der Einleitung

"Das Wort „Authentication“ ist irreführend, da MACs dem Integritätsschutz dienen und nicht der Authentifizierung. Das Wort „Code“ ist irreführend, da es die Verwendung von Codierungs- oder Verschlüsselungsverfahren nahelegt." Da MAC-Verfahren meist auf Basis eines PSK eingesetzt werden (vgl. IPsec, andere Protokolle), wird der Urheber der Nachricht, da dessen Key einfließt, sehr wohl authentifiziert: MAC(Nachricht) = Hash(Nachricht, Key). Da diesen Key nur die Kommunikationspartner kennen, kann die Nachricht nur vom anderen Kommunikationspartner stammen. Außerdem ist "Code" ebenfalls nicht irreführend, da es ja in der Datenübertragung auch die Prüfcodes gibt. Es ist eine Fehlannahme, zu behaupten, dass Codes Verschlüsselungsverfahren nahelegen. Dies gilt maximal für fachfremde Personen. Habe daher diesen Satz mal entfernt.

Edit: Sogar in der Originalquelle heißt es, dass MACs "rather" dem Integritätsschutz dienen und "weniger" der Authentifikation. Im Gegensatz zur Einleitung, welche behauptet, dass sie _nicht_ der Authentifizierung dienen. V.a. die HMAC-Unterklasse der MAC-Verfahren dient sehr wohl der Authentifizierung. (nicht signierter Beitrag von 138.246.2.74 (Diskussion) 16:33, 28. Feb. 2012 (CET))

Supereinfache Erklärung für MACs:

Was digitale Signaturen für die asymmetrische Verschlüsselung sind,
sind MACs für die 'symmetrische Verschlüsselung.

(Deswegen kann auch jeder Beteiligte der die MAC prüfen kann diese auch generieren. Weil jeder Beteiligte ja auch den gemeinsamen Schlüssel hat. Im Gegensatz zu digitalen Signaturen, wo jeder seinen eigenen Schlüssel hat.)

Ich finde das sollte unbedingt in den Artikel, da die aktuelle Beschreibung und der aktuelle Vergleich mit digitalen Signaturen langatmig und dadurch unnötig verwirrend ist. Obiges macht mit einem Satz alles klar. :)

(Digitale Signaturen lassen sich entsprechend auch mit einem Satz erklären, allerdings sollte man irgendwo [am besten auf beiden Seiten] zusätzlich das Konzept der Signatur[generierung/prüfung] erklären auf der beide Verfahren basieren. Auch in einem Satz, denn komplexer ist es nicht.)

– 87.79.139.86 11:16, 26. Jul. 2013 (CEST)

das ist nicht ganz korrekt, bspw. ist bei einer digitalen signatur auch dritten klar, wer signiert hat, weil nur ein benutzer den geheimen schluessel hat. das steht auch bereits im artikel. --Mario d 12:55, 3. Aug. 2013 (CEST)

absolut unverständliches Beispiel

Das Beispiel unter 4.1 und die anschließende Sicherheitsanalyse sind beim besten Willen nicht zu verstehen. Kann das bitte jemand besser bzw. überhaupt erklären? (nicht signierter Beitrag von 91.141.0.4 (Diskussion) 16:58, 3. Jul 2016 (CEST))

geht mir genau so. "Ihm ist aus der Übersicht bekannt, dass der entsprechende Schlüsselabschnitt 10 oder 11 lautet." - Also ich sehe da aber vier Fälle. warum denn nur 10 oder 11?--Bomberzocker (Diskussion) 16:01, 24. Sep. 2016 (CEST)

Der Angreifer hat die Nachricht und die jeweiligen MACs der einzelnen Bits abgefangen, also (A,1)(A,0)(B,1)(B,0). Außerdem hat er Kenntnis über die Tabelle, die mithilfe des Schlüssels die Zeichen A und B mit ihrem jeweiligen MAC verknüpft. Er schlägt in der Tabelle (A,1) nach, um den Schlüssel herauszufinden, der benutzt worden ist, um für das Nachrichtenzeichen A den MAC 1 zu generieren. Allerdings führen sowohl 10 und 11 für A zum MAC "1", also kann der Angreifer nicht entscheiden, welcher der beiden Schlüssel benutzt wurde. Will er nun die Nachricht fälschen und das A durch ein B ersetzten kann er nur raten, welcher Schlüssel benutzt wurde. --Muxamilian (Diskussion) 16:59, 16. Mai 2017 (CEST)