Verschluesselung fuer Poin2Point Kommunikation mit wenig CPU last
-
Blue-Tiger schrieb:
rapso schrieb:
LFSR fuer OTP ist sicher solange man keine wiederholung hat, dafuer reicht es auch eine kaskade von 8bit LFSR zu haben die man in verschiedenen frequenzen updated, diese generieren dann ebenfalls eine folge die sich kaum zu menschenzeiten wiederholen durfte.
BlueTooth nutzt es, NDS nutzt es, GSM nutzt es, ich denke bei kleiner rechenleistung und solange keine Atombombenplaene uber die leitung gehen, ist das ausreichend sicher.
Nur zur Korrektheit, bitte nenn es nicht OTP, du sprichst von einem Stromverschluesseler. OTPs funktionieren in der Tat nur mit echten Zufahlszahlen.
wenn sich der key nicht wiederholt, ist es OTP.
-
rapso schrieb:
Blue-Tiger schrieb:
rapso schrieb:
LFSR fuer OTP ist sicher solange man keine wiederholung hat, dafuer reicht es auch eine kaskade von 8bit LFSR zu haben die man in verschiedenen frequenzen updated, diese generieren dann ebenfalls eine folge die sich kaum zu menschenzeiten wiederholen durfte.
BlueTooth nutzt es, NDS nutzt es, GSM nutzt es, ich denke bei kleiner rechenleistung und solange keine Atombombenplaene uber die leitung gehen, ist das ausreichend sicher.
Nur zur Korrektheit, bitte nenn es nicht OTP, du sprichst von einem Stromverschluesseler. OTPs funktionieren in der Tat nur mit echten Zufahlszahlen.
wenn sich der key nicht wiederholt, ist es OTP.
Auch wenn sich aus einem key der nächste berechnen läßt ist es nicht OTP.
Und bei Zufallsgeneratoren die keine echten Zufallszahlen erzeugen kann man das (mehr oder weniger theoretisch)
-
SchlauMeyer schrieb:
rapso schrieb:
Blue-Tiger schrieb:
rapso schrieb:
LFSR fuer OTP ist sicher solange man keine wiederholung hat, dafuer reicht es auch eine kaskade von 8bit LFSR zu haben die man in verschiedenen frequenzen updated, diese generieren dann ebenfalls eine folge die sich kaum zu menschenzeiten wiederholen durfte.
BlueTooth nutzt es, NDS nutzt es, GSM nutzt es, ich denke bei kleiner rechenleistung und solange keine Atombombenplaene uber die leitung gehen, ist das ausreichend sicher.
Nur zur Korrektheit, bitte nenn es nicht OTP, du sprichst von einem Stromverschluesseler. OTPs funktionieren in der Tat nur mit echten Zufahlszahlen.
wenn sich der key nicht wiederholt, ist es OTP.
Auch wenn sich aus einem key der nächste berechnen läßt ist es nicht OTP.
Und bei Zufallsgeneratoren die keine echten Zufallszahlen erzeugen kann man das (mehr oder weniger theoretisch)ja, und eine verschluesselungen die jemals einen schluessel wiederholt verwenden ist laut definition unsicher, somit ist einzip OTP mit echtem zufallsschluessel sicher. soviel zur theorie pfenigfuchserei.
AES ist genau so unsicher wie OTP mittels xor auf eine AES sequenz.
-
rapso schrieb:
wenn sich der key nicht wiederholt, ist es OTP.
Ich will weder den Thread hijacken noch auf so einem Detail rumreiten, aber nein, was du beschreibst ist die Mutter aller Stream Cipher ( http://en.wikipedia.org/wiki/Stream_cipher ). Genauer gesagt beschreibst du, wie man AES im OFB Modus betreibt ( http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Output_feedback_.28OFB.29 ). Aber das ist kein OTP! Bitte lies die Wikipedia-Eintraege, wenn du mir nicht glaubst.
Du hast aber natuerlich Recht mit der Aussage, dass AES im OFB Modus genauso sicher ist wie AES im CBC-Modus (in dem er Normalerweise betrieben wird).
Allerdings ist SideWinder ja gerade an sehr schnellen Verschluesslern interessiert. Rijndael wurde zwar gerade deswegen zum AES gekuehrt, weil er schneller war als die (vermutlich sichereren) Mitbewerber. Allerdings gibts AFAIK andere (Strom)verschluesseler, die schneller sind. Und bei dem von dir vorgeschlagenem Modus kommt er nicht darum herum, den AES auf den Embedded Systems laufen zu lassen (ausser er gibt den IV fix vor und berechnet sich die XOR-Sequenzen im Voraus, aber das ist dann eher security through obscurity).
-
rapso schrieb:
ja, und eine verschluesselungen die jemals einen schluessel wiederholt verwenden ist laut definition unsicher..
eben nicht. bei AES kannst du millionen dateien mit dem gleichen schlüssel verschlüsseln und trotzdem kriegt ihn keiner raus. bei XOR musst du den schlüssel für jede datei wechseln *und* er muss riesig lang sein, damit XOR annähernd sicher ist. wenn man das allerdings konsequent durchzieht, also ständig neue schlüssel und die schlüssel mindestens so lang sind, wie die daten selber, dann ist XOR die sicherste verschlüsselung, die es gibt.
aber warum fragen wir nicht einfach den kryptochef?
-
^^soll heissen: aber warum fragen wir nicht einfach den kryptochef?
-
~fricky schrieb:
rapso schrieb:
ja, und eine verschluesselungen die jemals einen schluessel wiederholt verwenden ist laut definition unsicher..
eben nicht. bei AES kannst du millionen dateien mit dem gleichen schlüssel verschlüsseln und trotzdem kriegt ihn keiner raus.
Natürlich kann man den Schlüssel rausbekommen, nur OTP ist unknackbar.
Blue-Tiger schrieb:
Allerdings ist SideWinder ja gerade an sehr schnellen Verschluesslern interessiert.
Ich glaube dir ist nur entgangen, dass das ein Biespiel dafür war, dass OTP nicht per se unsicher ist.
LFSR dürfte weitaus schneller sein, und ist dennoch ausreichend sicher.
-
~nicky schrieb:
Blue-Tiger schrieb:
Allerdings ist SideWinder ja gerade an sehr schnellen Verschluesslern interessiert.
Ich glaube dir ist nur entgangen, dass das ein Biespiel dafür war, dass OTP nicht per se unsicher ist.
LFSR dürfte weitaus schneller sein, und ist dennoch ausreichend sicher.
Natuerlich ist OTP per se sicher. Aber OFB-AES ist kein OTP. Und ich sag ja auch dass SideWinder schnellere Verfahren nehmen soll als OFB-AES. Ob die Sicherheit ausreichend ist oder nicht koennen wir allerdings nicht wissen; das muss wenn, dann SideWinder selbst entscheiden. Wenn er mehr will als nur Hobby-Cracker aufhalten, z. B. sehr hohe Sicherheit garantieren, muss er wohl was Sichereres als RC4 oder Streamcipher auf LFSR-Basis nehmen. Ansonsten sind die beiden natuerlich gangbare Optionen (wobei ich dann RC4 einem LFSR-Cipher vorziehen wuerde).
EDIT: weils auf der RC4-Seite von Wikipedia verlinkt war; Das koennte was fuer SW sein: http://en.wikipedia.org/wiki/Tiny_Encryption_Algorithm
-
~nicky schrieb:
Natürlich kann man den Schlüssel rausbekommen, nur OTP ist unknackbar.
aber nur theoretisch. praktisch braucht man dafür sehr viel zeit und viel-viel teure hardware.
Blue-Tiger schrieb:
EDIT: weils auf der RC4-Seite von Wikipedia verlinkt war; Das koennte was fuer SW sein: http://en.wikipedia.org/wiki/Tiny_Encryption_Algorithm
was sich auch noch gut für microcontroller eignet ist RC5. das braucht keine fetten substitution-boxes und ist recht schnell ausgerechnet. die verschlüsselungsstärke sollte für den normalgebrauch ausreichend sein. ausserdem kann man die schlüssellänge variieren (wählt man grosse schlüssel, steht man in manchen ländern bestimmt mit einem bein im knast).
-
ich würde einen 8-bit-rc4 algorithmus verwenden und dh für den schlüsselaustausch (wie blue tiger schon geschrieben hat). die frage ist, ob authentifizierung nötig ist. wenn ja, muss man wohl auf rsa zurückgreifen. das könnte aber das dh ersetzen.
tls verwendet rsa (oder vergleichbares) für die authentifizierung, dh für den schlüsselaustausch und einen symmetrischen chiffre für die daten. rc4 wird von tls unterstützt. tls ist aber sehr komplex. die geräte können aber immerhin tcp. also werden sie nicht ganz so schwach sein.
rc4 mit 8 bit großen registern lässt sich auch perfekt auf einem 8 bit prozessor implementieren. es braucht gerade mal etwas über 256 byte für den zustand.
dh und rsa auf einem 8 bit prozessor zu implementieren ist sicher nicht leicht bzw performant. man sollte wohl darauf achten, nicht zu oft den schlüssel zu wechseln.ist aber nur mal meine meinung.
zum thema otp: otp bedeutet, dass man einen schlüssel in der länge des klartextest mit dem klartext xor verknüpft. der schlüssel muss dazu zufällig erzeugt werden und darf kein zweites mal verwendet werden. stromchiffren haben also nur das xor mit otp gemeinsam. otp ist übrigens immer und überall unmöglich zu knacken, da man jeden beliebigen klartext reproduzieren kann und deshalb nicht den richtige herausfiltern kann. es ist ein logisches problem und keines der komplexität.