Frage:
Was sind die Anforderungen für den geheimen HMAC-Schlüssel?
ivstas
2015-08-05 15:49:47 UTC
view on stackexchange narkive permalink

Ich erstelle einen HTTP-REST-Dienst, der nur über TLS verfügbar ist.

Zur Authentifizierung plane ich, für jeden Benutzer mit HMAC HS256 ein JWT -Token zu generieren . Ich benötige einen geheimen Schlüssel für HMAC.

Was sind die Anforderungen für geheimen Schlüssel ?

Benötige ich eine lange Zeichenfolge? von zufälligen Zeichen? Oder String mit fester Länge? Oder was?

Vier antworten:
#1
+42
SilverlightFox
2015-08-07 15:05:47 UTC
view on stackexchange narkive permalink

Ich habe meine Antwort hier hinzugefügt, da ich der Meinung bin, dass die vorhandenen Ihre Frage nicht direkt genug für meinen Geschmack beantworten.

Schauen wir uns RFC 4868 (in Bezug auf IPSec) an Es behandelt jedoch die HMAC-SHA256-Funktion, die Sie verwenden möchten - em mine ):

Blockgröße: Die Größe des Datenblocks, mit dem der zugrunde liegende Hash-Algorithmus arbeitet . Für SHA-256 sind dies 512 Bit , für SHA-384 und SHA-512 1024 Bit.

Ausgabelänge: Die Größe des von der zugrunde liegender Hash-Algorithmus. Für SHA-256 sind dies 256 Bit , für SHA-384 384 Bit und für SHA-512 512 Bit.

As WhiteWinterWolf-Hinweise, die länger als B sind, werden nicht empfohlen, da der Wert zuerst mit SHA-256 gehasht werden muss (dh in diesem Fall 512 Bit) und weniger als L nicht empfohlen wird (in diesem Fall 256 Bit). Ein 256-Bit-Schlüssel ist jedoch übertrieben, da alles, was 128 Bit oder mehr beträgt, in der aktuellen Lebensdauer eines Menschen nicht brutal erzwungen werden kann, selbst wenn jeder Computer auf der Welt daran gearbeitet hat, ihn zu knacken.

Daher würde ich a empfehlen 128-Bit-Schlüssel, generiert mit einem kryptografisch sicheren Pseudozufallszahlengenerator (CSPRNG). Wenn Sie dies als Text speichern möchten, kann ein 128-Bit-Schlüssel durch Generieren einer zufälligen Hex-Zeichenfolge mit einer Länge von 32 Zeichen dargestellt werden. Alternativ können Sie 16 zufällige Bytes generieren und diese dann über eine base64-Funktion ausführen.

Fügen Sie lediglich einen Verweis auf die [OWASP-Empfehlungen zur Länge der Sitzungs-ID und Kommentare zur Entropie der Sitzungs-ID] (https://www.owasp.org/index.php/Session_Management_Cheat_Sheet#Session_ID_Length) hinzu, der weitere Erläuterungen zur Auswahl von 128 Bit enthält.
* 12 * Bytes, Base64-codiert, ergeben 128 Bit. Alle 6 Bits (2 ^ 6 = 64) werden als 8-Bit-Zeichen codiert, sodass wir 12/6 * 8 * 8 = 128 haben.
@AryehLeibTaurog: 12 Bytes ergeben bei Base64-Codierung eine Größe von 128 Bit, die zugrunde liegende Entropie würde jedoch nur 96 Bit betragen. Dies liegt daran, dass nicht jede Bitkombination in der resultierenden Codierung gültig ist.
Es ist von Natur aus veraltet, um die Zeit zu schätzen, die benötigt wird, um etwas brutal zu erzwingen, obwohl sich Moores Gesetz verlangsamt hat.
@eke Ich bin mir nicht sicher, worauf Sie sich beziehen, da in meiner Antwort oder den folgenden Kommentaren überhaupt keine Zeit geschätzt wurde.
@eke, es sei denn, Sie beziehen sich auf "Lebensdauer" als Schätzung: D? Siehe hier https://securityintelligence.com/moores-law-and-cryptography-for-business-do-we-need-a-larger-key-Raum/
@SilverlightFox Dieser Artikel hat mich nicht sehr überzeugt (dieselben alten und veralteten Annahmen), aber dieses Video hat mich überzeugt: https://www.youtube.com/watch?v=S9JGmA5_unY
Es sollte 256 sein, wie JWA angibt.
#2
+19
jordanbtucker
2017-01-01 01:17:27 UTC
view on stackexchange narkive permalink

Gemäß RFC 7518 - JSON-Webalgorithmen (JWA):

Ein Schlüssel mit der gleichen Größe wie die Hash-Ausgabe (z. B. 256 Bit für " HS256 ") oder größer MUSS mit diesem Algorithmus verwendet werden. (Diese Anforderung basiert auf Abschnitt 5.3.4 (Sicherheitseffekt des HMAC-Schlüssels) von NIST SP 800-117 (sic) [ NIST.800-107], in dem angegeben ist, dass die effektive Sicherheitsstärke beträgt Das Minimum der Sicherheitsstärke des Schlüssels und das Zweifache der Größe des internen Hashwerts.)

Im Fall von JWT MÜSSEN Sie also einen Schlüssel mit mindestens 256 Bit verwenden HS256.

#3
+10
WhiteWinterWolf
2015-08-05 16:49:47 UTC
view on stackexchange narkive permalink

Der RFC 2104, der HMAC-Funktionen definiert, beantwortet diese Frage:

Der Schlüssel für HMAC kann beliebig lang sein (Schlüssel, die länger als B Bytes sind, werden zuerst mit H gehasht ). Von weniger als L Bytes wird jedoch dringend abgeraten, da dies die Sicherheitsstärke der Funktion verringern würde. Schlüssel, die länger als L Bytes sind, sind akzeptabel, aber die zusätzliche Länge würde die Funktionsstärke nicht wesentlich erhöhen. (Ein längerer Schlüssel kann ratsam sein, wenn die Zufälligkeit des Schlüssels als schwach angesehen wird.)

Schlüssel müssen zufällig ausgewählt werden (oder unter Verwendung eines kryptografisch starken Pseudozufallsgenerators, der mit einem zufälligen Startwert geimpft ist), und regelmäßig aktualisiert. (Aktuelle Angriffe geben keine bestimmte empfohlene Häufigkeit für Schlüsseländerungen an, da diese Angriffe praktisch nicht durchführbar sind. Eine regelmäßige Schlüsselaktualisierung ist jedoch eine grundlegende Sicherheitspraxis, die potenziellen Schwachstellen der Funktion und der Tasten entgegenwirkt und den Schaden eines exponierten Schlüssels begrenzt. )

Zur Information wird in diesem Auszug die folgende Notation verwendet:

Wir nehmen an, dass H eine kryptografische Hash-Funktion ist, bei der Daten durch Iteration von a gehasht werden Grundlegende Komprimierungsfunktion für Datenblöcke. Wir bezeichnen mit B die Bytelänge solcher Blöcke (B = 64 für alle oben genannten Beispiele für Hash-Funktionen) und mit L die Bytelänge der Hash-Ausgänge (L = 16 für MD5, L = 20 für SHA-1) ).

#4
+1
StackzOfZtuff
2015-08-05 16:07:37 UTC
view on stackexchange narkive permalink

EDIT: Falsche Antwort. Wird nicht gelöscht, um den Kommentarthread beizubehalten.


HMAC-Benutzereingabeschlüssel, die länger als die Blockgröße der spezifischen Hash-Algorithmen sind, werden zuerst gekürzt. (Indem Sie die langen Schlüssel durch den Hash laufen lassen und diesen Hash dann als eigentlichen Schlüssel verwenden.)

SHA256 gibt 256-Bit-Hashes aus. Das sind 32 Bytes. Daher schlage ich vor, dass Sie geheime 256-Bit-HMAC-Schlüssel generieren. (Verwenden eines kryptografisch sicheren Zufallsgenerators.) Schlüssel bieten keine zusätzliche Sicherheit mehr.

Habe ich es richtig verstanden: Ich muss eine zufällige 256-Bit-Sequenz (bei Verwendung von HMAC mit HS256) mit einem kryptografisch sicheren Zufallsgenerator generieren und dann als Schlüssel verwenden?
Wenn Sie die maximale Stärke des HMAC-SHA256 wünschen, dann ja.
Lassen Sie uns genau sein: Bei SHA-256 beträgt die Ausgabegröße 256 Bit, die Blockgröße jedoch 512 Bit, sodass die "Verkürzung" nur für Schlüssel mit mehr als 512 Bit auftritt. Kryptografische Schlüssel (für symmetrische Algorithmen wie HMAC), die länger als 128 Bit sind, erhöhen jedoch nicht die Sicherheit, sodass nicht unbedingt ein Schlüssel mit voller Blocklänge verwendet werden muss.
Genauer gesagt: Sie würden einen Zufallszahlengenerator für einen völlig neuen Schlüssel verwenden. Es ist beispielsweise möglich, einen Schlüssel von einer Schlüsselableitungsfunktion zu erhalten, möglicherweise unter Verwendung eines Schlüsselvereinbarungsprotokolls. Solange alle zulässigen Schlüssel für Ihre spezifische Größe für einen Angreifer gleichermaßen möglich sind, sind Sie gut.
Danke, Tom, Maarten. Ich habe eine Warnung über meine frühere Antwort gesetzt. Ich lasse es wegen dieses Kommentarthreads am Leben.


Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...