128 Bit oder 256 Bit schlüssel errechnen mittels Hash funktion
-
hi,
guckst du: http://www.cs.umd.edu/~mhshin/doc/802.11/802.11i-D3.0.pdf
absatz 5.1 PRF reference code.
das ist so'ne kryptografische hashfunktion, die unterschiedliche schlüssellängen ausspucken kann...
-
merci...
aber bezieht sich das nicht auf char input? Kann es sein dass nur inputs bis maximal 64 erlaubt sind?...bin mir unsicher ob ich das für meine double bzw. ganzzahligen werte verwenden kann?
Danke
-
Mati schrieb:
aber bezieht sich das nicht auf char input? Kann es sein dass nur inputs bis maximal 64 erlaubt sind?
das gilt für den key, den man da reinmixen soll, damit der output noch 'zufälliger' wird. ist es ein 64-byte langer key, dann haste eine 'PRF-512'. die länge der daten, die gehashed werden sollen, ist aber variabel...
Mati schrieb:
...bin mir unsicher ob ich das für meine double bzw. ganzzahligen werte verwenden kann?
ist ja nicht so schlimm. musste halt dein double-array in char* casten.
(ich glaub' vor kurzem hatte hier einer exakt das gleiche thema
)
-
hui. danke....
hmm....ich brauche aber ganzzahlen weil ich rumshifte später auf den keys....und bitoperationen mache....müsste halt 2mal casten...einmal in char und dann wieder zurück - ginge das? Ich muss zusätzlich Zeitperformant bleiben - 2maliges casten - ist das nicht zu teuer? Ich arbeite mit riesigen dimensionen: vektoren können 2000, 50000 und im extremfall 500 000 000 einträge haben ....deswegen die frage nach dem casten...
-
Mati schrieb:
Ich muss zusätzlich Zeitperformant bleiben
äääh, ach so, naja, an typecasts solls nicht scheitern aber wenn's um speed geht, würde ich eine PRF nicht nehmen. die verwendet zum verscramblen intern den SHA-1 algo und sowas hat zwar 'ne gewisse kryptografische qualität, ist aber leider alles andere als schnell

-
Hallo
oder um es anders zu sagen : Die Casts an sich werden nichts verlangsamen. Alle Casts bis auf den dynamic_cast werden ausschließlich zur Compile Time ausgewertet, und haben zur Laufzeit keinen Einfluß mehr.
bis bald
akari
-
Alle Casts bis auf den dynamic_cast werden ausschließlich zur Compile Time ausgewertet, und haben zur Laufzeit keinen Einfluß mehr.
Falsch.
-
Hallo
@ nöö : und kannst du deine "Kritik" auch begründen?
bis bald
akari
-
begründung?
edit: Akari war schneller..scheiße....prf ist also langsam und SHA auch? *grmpf....vielleicht sollte ich doch mit bitsets irgendwie arbeiten.....ach die welt wär doch so schön

-
akari: denk doch mal nur an 'nen einfachen cast von 'int' nach 'double' oder umgekehrt. das sind ganz andere formate, das muss zur laufzeit umgerechnet werden...
btw: eigentlich kommen nur casts von pointer nach pointer ohne berechnungen aus. naja, mit ausnahe dieses c++-geraffels 'dynamic_blah<p*>', das die ganze vererbungsliste durchrattern muss.
-
Hallo
Nein, es wird nichts gerechnet. Sondern der Compiler wird gezwungen, den Speicherbereich des Arguments wie vom Typ des Cast-Ziels zu behandeln. Das kann auch zu Speicherfehlzugriffen führen. Zum Beispiel so
unsigned short test = 10; unsigned int test2 = std::numeric_limits<unsigned int>().max(); reinterpret_cast<unsigned int>(test) = test2;Hier wird der Compiler gezwungen, die 2 Bytes des shorts mit den 4 Bytes des ints zu überschreiben, was demzufolge auch unzulässig ist.
Casts selber (bis auf den dynamic_cast) verändern gar nichts./Edit :
Ein guter Compiler läßt mein Beispiel gar nicht durch. Aber so kompilierts, und verursacht trotzdem Speicherfehlerunsigned short test = 10; unsigned int test2 = std::numeric_limits<unsigned int>().max(); *(reinterpret_cast<unsigned int*>(&test)) = test2;bis bald
akari
-
probier doch mal sowas:
int main (int a, char **b) { double d = (double)a; // c++ casts auch mal probieren std::cout << d << std::endl; }und schau dir das disassembly an.
ich könnte wetten, dass zum konvertieren eine versteckte funktion aufgerufen wird...
-
Hallo
ja, die "versteckte Funktion" ist der Konstruktor von double.
Egal was aus dem Cast von a kommt, durch die Dekalration von double wird auf jedenfall ein gültiges double initialisiert.bis bald
akari
-
akari schrieb:
Egal was aus dem Cast von a kommt,
eben nicht. der inhalt von 'd' ist davon abhängig.
-
Hallo
okay, dann zieh ich meine erste Aussage zurück. Und grenze sie auf Pointer ein.
bis bald
akari
-
hmm.jetzt bin ich verwirrt - könnte jemand nochmal kurz zusammenfassen was unser ergebnis nun ist? Danke :p