Abend, hat jemand von euch schon mal ein Programm für nen AVR programmiert, welches das Diffie-Hellman Prinzip anwendet? Muss mit einem Gerät kommunizieren, welches einen 128Bit Geheimschlüssel austauscht. Dumme Frage: Wie kann ich überhaupt eine 128Bit Primzahl generieren (für das Element p im DH-Prinzip)? Ein 16 Byte langes Array mit Zufallsprimzahlen von 0-255 erzeugen? PS: geht das ganze mit nem 8-Bit µC? Geschwindigkeit ist egal! Gruß, Mani
Hi, ok, hab den Coe mal ins AVR Studio reingeladen. Der Compiler schreit, dass er bcopy und bzero nicht findet. Hab gelesen, dass es diese Funktionen nicht mehr gibt, sondern ersetzt wurden durch welche in string.h. bcopy z.B. durch memmove, aber der 10 Zeilen DH-Code verwendet des öfteren bcopy mit nur zwei statt der 3 benötigenten Argumente für memmove, was den Compiler zum meckern veranlasst. Durch was kann ich die Funtionen bcopy und bzero ersetzten? Mani
ungetestet:
1 | #include <string.h> |
2 | |
3 | |
4 | void bcopy( const void *src, void *dest, size_t n ) |
5 | {
|
6 | memmove( dest, src, n ); |
7 | }
|
8 | |
9 | void bzero( void *s, size_t n ) |
10 | {
|
11 | memset( s, 0, n ); |
12 | }
|
Mani schrieb: > Ein 16 Byte langes Array mit Zufallsprimzahlen > > von 0-255 erzeugen? da muss der Zufall aber gut sein, damit es am ende auch eine Primzahl wird. Ich kann mir nicht vorstellen das es in sinnvoller Zeit auf einem AVR (8-Bit Atmel) möglich ist.
naja, von 0 bis 255 kann es ja nicht mehr als 254 Primzahlen geben. Die moderne Wissenschaft geht davon aus, daß es sogar eher weniger sind. Insofern würde ich schon auf akzeptable Rechenzeit tippen.
Ja das mit dem Array dachte ich mir schon, dass das nicht so gehen wird. Den 10 Zeilen DH Code check ich gar nicht :-( Wie programmiert man nun den 128 Bit Primzahlengenerator? Hat keiner nen Code-Auszug wo mit nem Gerät Schlüssel mittels DH ausgetauscht werden? Kann ich zum Austesten, also ob ich eine Kommunikation mit meinem Gerät hinbekomme, die Zufallszahl und die restlichen DH Variablen fix fertig deklarieren also die "Alice" Werte und mit den empfangengen Daten von "BOB" also meinem anzusteuernden Gerät weiterrechnen um einen gemeinsamen Schlüssel zu generieren? Im Handbuch des Gerätes, steht, dass es bei jeder Kommunikation einen Key Wechsel geben soll um die Sicherheit zu erhöhen. Wenn ich jetzt aber immer die gleichen "ALICE" Daten sende, da mir momentan die Abhörsicherheit egal ist, hab ich halt immer den gleichen Schlüssel, kann das so funktionieren? Der Schlüssel soll dann noch mittels AES mit den Nutzdaten verschlüsselt werden. Den 128 Bit AES Code hab ich mir schon mal aus diversen Foren zusammengestrickt, der funzt supa. Sorry für die vielleicht "dummen" Fragen.
Mani schrieb: > Kann ich zum Austesten, also ob ich eine Kommunikation mit meinem Gerät > hinbekomme, die Zufallszahl und die restlichen DH Variablen fix fertig > deklarieren also die "Alice" Werte und mit den empfangengen Daten von > "BOB" also meinem anzusteuernden Gerät weiterrechnen um einen > gemeinsamen Schlüssel zu generieren? Klar. Der Mathematik ist es egal, ob du jedesmal mit verschiedenen oder immer mit der gleichen Zufallszahl rechnest. Bietet nur dann eben ggf. keinen Schutz mehr. > Im Handbuch des Gerätes, steht, dass es bei jeder Kommunikation einen > Key Wechsel geben soll um die Sicherheit zu erhöhen. Wenn ich jetzt aber > immer die gleichen "ALICE" Daten sende, da mir momentan die > Abhörsicherheit egal ist, hab ich halt immer den gleichen Schlüssel, > kann das so funktionieren? Der Schlüssel wird nicht immer gleich sein, da ja die Zufallszahl von Bob auch mit einfliesst. Solange du die Zufallszahl von Alice geheimhalten kannst, und Bob einen ordentlichen Zufallszahlengenerator benutzt, ist das noch nichtmal unsicherer als ein "normaler" DH-Austausch. Allerdings kann ein Angreifer, wenn er irgendwann mal die Alice-Zahl herausbekommt. rückwirkend alle damit durchgeführten Schlüsselaustausche knacken. Ohne weitere Massnahmen gegen Man-In-The-Middle (keine Ahnung ob dein Protokoll da etwas wirksames vorsieht) ist DH aber sowieso erstmal witzlos, also nur zu. Andreas
Mani schrieb: > Abend, > > hat jemand von euch schon mal ein Programm für nen AVR programmiert, > welches das Diffie-Hellman Prinzip anwendet? Muss mit einem Gerät > kommunizieren, welches einen 128Bit Geheimschlüssel austauscht. Dumme > Frage: Wie kann ich überhaupt eine 128Bit Primzahl generieren (für das > Element p im DH-Prinzip)? Ein 16 Byte langes Array mit Zufallsprimzahlen > von 0-255 erzeugen? http://tools.ietf.org/html/rfc2631 (2.2.1.1. Generation of p, q) Test auf Primalität: http://www.itl.nist.gov/fipspubs/fip186.htm (2.1. A PROBABILISTIC PRIMALITY TEST) > > PS: geht das ganze mit nem 8-Bit µC? Geschwindigkeit ist egal! Die Laufzeit für den Test ist O(k log³ n) , n ist die zu testende Zahl, k die Anzahl der durchzuführenden Tests (sollte >= 50 sein)... > Gruß, Mani
Grüß euch, danke für die raschen Antworten. @Andreas: Stimmt, der Schlüssel wird natürlich nicht immer gleich sein, da ja Bob's Werte immer anders sein werden, nur meine, also Alice Werte (p,g,a) und daraus folgend das Alpha (ist quasi öffentliche Schlüssel von Alice)bleibt gleich. Wie gesagt, das Thema Abhörsicherheit interessiert mich momentan noch nicht, bin schon happy wenn ich mal eine gültige Kommunikation Herstellen kann. @Arc Net: Vielen Dank für die Links, man findet ja immer wieder neue Seiten wo das DH beschrieben ist :-) Werd ich mir dann gleich mal durchlesen. Wie es mit der Geschindigkeit aussieht, dass muss ich mir noch angucken, dafür muss ich erst mal den von dir empf. Link durchlesen. Wenn jemand noch weitere Vorschläge hat, nur her damit! Dank euch vorerst mal! Gruß Manfred
Muß man denn beim Diffie-Hellman jedesmal eine neue Primzahl suchen? Ich hätte jetzt gedacht, jemand legt den Generator und den Modulus einmal vorher allgemein fest (wobei jede Menge Rechenleistung zum Einsatz kommen kann, um sicherzustellen, daß der Modulus prim ist), so daß nachher zum Schlüsselaustausch auf jeder Seite nur noch eine Zufallszahl und zweimal modulo-Exponentiation nötig ist. Für einen 8-Bitter ist das ja schon genug Arbeit.
> Muß man denn beim Diffie-Hellman jedesmal eine neue Primzahl suchen?
Nein, Generator g und das prime p des Restklassenkoerpers sind
vor der Kommunikation konstant festgelegt. Beide Kommunikationsendpunkte
generieren eine (kryptographisch gute) Zufallszahl, es entsteht ein
shared master secret (vulgo "Schluessel"), --- aus dem nach einer
(normalerweise folgenden) Authentisierungsphase --- mit (i.d.R.)
kryptographischen Pseudozufallsfuntionen ("PRFs")
Schluessel fuer symmetrische und MAC-Verfahren generiert
werden... (i.d.R) fuer jeweils eine Richtung.
-> kryptographisch gute Zufallsfunktionen sind eine Schlangengrube!
-> im embedded Bereich hat man oft keine Minute(n) fuer einen
regulaeren DH, ECDH waere --- auch vom notwendigen
RAM her --- die Alternative.
Zur Inspiration:
RFC4346 klaert und beschreibt die Schritte im
TLS(/SSL ~ "https") Protokoll.
VG, Hans
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.