sichere 128-Bit-Einweg-Hashfunktion

Hi Leute.

Ich suche ein Hashfunktion, welches ein Hash-Wert von max. 128 Bit Länge ausgibt. Wenn's geht, kann es auch ruhig kleiner sein.
Außerdem sollte es eine sichere Einwegfunktion sein. Kollisionsresistent braucht es aber nicht zu sein.
Ich kenne nur die MDA- und SHA-Reihe, aber davon kommt keine in Frage. Und viele andere Algorithmen, die ich gefunden habe, geben zu lange Hash-Werte aus.
Ich möchte die Funktion als Bestandteil eines Seriennummern-Algorithmus' benutzen. Damit der Key aber nicht oschimäßig lang wird, darf der Hash-Wert nicht zu lang sein. Z.B. wären 160 Bits zu lang.

Freu mich auf eure Antworten.

cu
Mr.Yeah
 
Möglichkeiten:

Du nimmst z.B. "Whirlpool" und schneidest einfach die Bytes, die zuviel sind ab. Das nimmt dem Algo zwar einen großen Teil der Sicherheit, aber ich denke, dass es für deine Zwecke reichen sollte. Aber lieber abwarten, bis sich dazu einer der hiesigen Kryptoexperten äußert ;)

Alternativ kannst du den größeren Wertebereich auf einen kleineren Bereich abbilden (XOR sei hier genannt).

Ansonsten würde es ja vielleicht auch reichen, wenn du mehrere kleine Hashfunktionen (z.B. zwei Funktionen, die 64bit liefern) zu kombinieren. Da gibt's z.B. FNV-64 oder Size-64. Die sind aber afaik nicht sicher, da musst du dich mal informieren.

EDIT: Vielleicht hilft dir auch diese Seite weiter: http://www.jonelo.de/java/jacksum/index_de.html
 
Original von valenterry
Du nimmst z.B. "Whirlpool" und schneidest einfach die Bytes, die zuviel sind ab. Das nimmt dem Algo zwar einen großen Teil der Sicherheit, aber ich denke, dass es für deine Zwecke reichen sollte.
Hui. Da nehme ich lieber SHA-224 und schneide etwas ab. Außerdem ist solche bestimmt eine solche Methode ein Sicherheits-Super-Gau. Die SHA-2-Familie lehne ich ja wegen der Länge ab.


Original von valenterry
Alternativ kannst du den größeren Wertebereich auf einen kleineren Bereich abbilden (XOR sei hier genannt).
Hm. XOR kenne ich, aber es so zu benutzen kenne ich nicht. Werde mich informieren.
Außerdem möchte ich nicht einen größeren Wertebereich auf einen kleineren abbilden, sondern einen beliebigen auf einen festen. Wenn's dafür eine andere Methode gibt, dann her damit. Mit beliebig ist aber auch gemeint, dass er größer als der feste Wertebereich sein kann.


Original von valenterry
Ansonsten würde es ja vielleicht auch reichen, wenn du mehrere kleine Hashfunktionen (z.B. zwei Funktionen, die 64bit liefern) zu kombinieren. Da gibt's z.B. FNV-64 oder Size-64. Die sind aber afaik nicht sicher, da musst du dich mal informieren.
Dann nehme ich gleich nur ein Algorithmus. Es sollten max. 128 Bit sein. Ich denke aber nicht, dass es einen sicheren 64-Bit-Algorithmus gibt.


Original von valenterry
EDIT: Vielleicht hilft dir auch diese Seite weiter: http://www.jonelo.de/java/jacksum/index_de.html
Danke, schaue ich mir mal an.
 
Einen Hashalgorithmus nehmen, der einen langen (512 bit) Hash liefert, und mittels eines anderen Hashalgorithmus 128 indices im Raum [0,511] bestimmen, und diese Bits nehmen? Ich bin Kryptologisch (noch) nicht wirklich bewandert, gleicht das eventuelle Schwächen in einem der beiden Algorithmen aus?

EDIT: was sind deine Sicherheitsbedenken gegenüber diesen Algorithmen?
 
Original von valenterryAlternativ kannst du den größeren Wertebereich auf einen kleineren Bereich abbilden (XOR sei hier genannt).

Mir gefält diese Idee eigentlich ganz gut. Man könnte einen 256 bit hash-Algo nehmen, in der Mitte teilen und die beiden Werte XORen.
Das solte sicher sein.
 
Hallo,
man muss bedenken was bei MD-5 sicher bzw. unsicher ist. Zu einem gegeben Hash die Eingabe zu finden ist nach wie vor nicht möglich.

Ansonsten gibt es diverse Möglichkeite, nur 128 Bit zu bekommen, zwei wären.
1) md5(sha256(m))
2) sha256 in zwei 128 Bit Teile zerlegen und per XOR verknüpfen

Oder man wartet auf den SHA Nachfolger ;)
 
Original von Heinzelotto
Einen Hashalgorithmus nehmen, der einen langen (512 bit) Hash liefert, und mittels eines anderen Hashalgorithmus 128 indices im Raum [0,511] bestimmen, und diese Bits nehmen? Ich bin Kryptologisch (noch) nicht wirklich bewandert, gleicht das eventuelle Schwächen in einem der beiden Algorithmen aus?
Ich denke eher, dass es die Schwächen addiert, denn so würde man doch z.B. einen Man-in-the-middle-Angriff vereinfachen, oder? Ich habe aber auch kein großes Know-how in Sachen Kryptologie.


Original von Heinzelotto
EDIT: was sind deine Sicherheitsbedenken gegenüber diesen Algorithmen?
Siehe meine Signatur. Es gibt viele Leute, die es bei solchen Sachen nicht genau nehmen und sich denken: "Das passt schon". Dann kommen solche Geschichten wie die 20-Nullen-Seriennummer dabei heraus. Es ist wahr!
Ich möchte deswegen aus den Fehlern lernen und nicht solch eine Dummheit machen.


Original von Elderan
Hallo,
man muss bedenken was bei MD-5 sicher bzw. unsicher ist. Zu einem gegeben Hash die Eingabe zu finden ist nach wie vor nicht möglich.
Was mein Algorithmus leisten muss, ist eher, zu einem gegebenem Eingabewert keinen zweiten zu finden, der den gleichen Hash ausgibt. Und soweit ich weiß gibt es schon Schwächen in diese Richtung.


Original von Redfox
Original von valenterry
Alternativ kannst du den größeren Wertebereich auf einen kleineren Bereich abbilden (XOR sei hier genannt).

Mir gefält diese Idee eigentlich ganz gut. Man könnte einen 256 bit hash-Algo nehmen, in der Mitte teilen und die beiden Werte XORen.
Das solte sicher sein.
Original von Elderan
2) sha256 in zwei 128 Bit Teile zerlegen und per XOR verknüpfen
Erst jetzt habe ich die Idee verstanden. Ich finde es sehr gut, und aus Seiten der Sicherheit scheint es genügend sicher zu sein.

Danke für eure Hilfe.

cu
Mr.Yeah
 
[...]
Original von Elderan
Hallo,
man muss bedenken was bei MD-5 sicher bzw. unsicher ist. Zu einem gegeben Hash die Eingabe zu finden ist nach wie vor nicht möglich.
Was mein Algorithmus leisten muss, ist eher, zu einem gegebenem Eingabewert keinen zweiten zu finden, der den gleichen Hash ausgibt. Und soweit ich weiß gibt es schon Schwächen in diese Richtung.
[...]

Korrigier' mich bitte, wenn ich mich irre, aber führst du damit nicht das Prinzip eines Hash-Algorithmus' ad absurdum? Wenn du einen beliebig großen Wertebereich auf einen bestimmten Wertebereich abbilden willst, kannst du es wegen der naturgemäßg beschränkten Anzahl der Werte nicht ausschließen, dass es irgendwann Kollisionen (die du oben beschreibst) geben wird - und solltest es auch nicht. Ansonsten hättest du keinen Gewinn durch den Hash-Algorithmus.
 
Original von lBr1anl
[...]
Original von Elderan
(...)

Korrigier' mich bitte, wenn ich mich irre, aber führst du damit nicht das Prinzip eines Hash-Algorithmus' ad absurdum? Wenn du einen beliebig großen Wertebereich auf einen bestimmten Wertebereich abbilden willst, kannst du es wegen der naturgemäßg beschränkten Anzahl der Werte nicht ausschließen, dass es irgendwann Kollisionen (die du oben beschreibst) geben wird - und solltest es auch nicht. Ansonsten hättest du keinen Gewinn durch den Hash-Algorithmus.

Theoretisch ist es natürlich nicht möglich, solche Kollisionen zu verhindern. Ein guter Algorithmus versucht es allerdings, das Finden einer solchen Kollision in der Praxis so weit zu erschweren, dass es sich nicht lohnt.
 
Zurück
Oben