Verschluesselung fuer Poin2Point Kommunikation mit wenig CPU last
-
rüdiger schrieb:
rapso schrieb:
rüdiger schrieb:
rapso schrieb:
RSA fuer die initializierung, ein paar randomizer die dir nen xor wert liefern fuer ne art one-time-pad. das ist sehr sehr flink und auch recht sicher.
ne ne ne, OTP ist doch totaler Blödsinn. Das funktioniert nur, wenn du wirklich gute Zufallszahlengeneratoren hast und wie willst du die in einem Magnetkartenleser einbauen? Ne ne ne, warum müssen bei jeder Diskussion zu Verschlüsselung Leute kommen und OTP erwähnen. OTP ist Schwachsinn. Vergesst es einfach!
glaubst du nur weil du bloedsinn, schwachsinn usw. rufst hinterlaesst du irgendeinen eindruck ausser laecherlichkeit? auf dem niveau nicht mit mir!
Ich habe dazwischen ja auch ein Argument geliefert. Du hast einfach keine zuverlässige Quelle für Zufallszahlen auf dem Generator. Somit fällt OTP flach, weil dass eine der absolut kritischen Voraussetzungen für OTP ist. Ansonsten ist OTP _nicht_ sicher.
so sicher wie die folge mit der man verknuepft.
rapso schrieb:
Wenn die Magnetkartenleser RSA aushalten, dann kann man auch einen vernünftigen Verschlüsselungsalgorithmus nehmen.
sehr oft ist es egal wie langsam RSA implementiert ist weil es nur zur initialisierung dient, 128byte zu entschluesseln schaft auch eine ec karten.
Wenn du 128 byte entschlüsselst und für OTP nehmen willst, dann kannst du auch nur 128 byte Daten übertragen. Warum also nicht gleich die 128 byte Daten in das RSA-Paket packen?
weil man mit einem assymetrischen verfahren (egal wie langsam) das symmetrische verfahren initialisiert. 128byte/1024bit sollten weit mehr sein als irgend ein symmetrische verfahren "benoetigt".
rapso schrieb:
Es gibt ja auch Algorithmen, die kleiner und schneller sind, als zB AES.
AES (was symmetrisch ist) als substitution zu RSA (was assymetrisch ist)? das macht deinen ausbruch oben nicht serioeser.
Nicht für RSA. Ich habe nie behauptet, dass es für RSA sein soll. TLS verwendet asymetrische Verschlüsselungsverfahren nur um den Schlüssel zu übertragen (ähnlich wie dein Vorschlag). Skaliert aber wesentlich besser, weil der Schlüssel für die Session bestehen bleibt. Das macht deinen Vorschlag OTP zu verwenden auch nicht seriöser
ja, ich kann mich nur wiederholen, RSA zur initialisierung, danach OTP zur eigentlichen verschluesselung.
Und damit funktioniert OTP eben nicht. OTP verlangt echte Zufallszahlen als Schlüssel!
deine veralgemeinerungen klingen sehr nach lehrbuch. wenn deine zahlenfolge mit der du XORst aus einem AES generiert werden wuerde (AES des vorherigen outputs von AES), waere das OTP so sicher wie AES selbst, erst wenn du die initialisierungs zahlenfolge von AES errechnen koenntest, koenntest auch das OTP knacken.
Entsprechend ist das nur eine frage des "randomizers" und es ist ein kinderspiel einen zu schreiben der so sicher wie AES ist, solange niemand an die hardware kommt.
ein beispiel waere "LFSR", wird z.B. beim nintendo DS benutzt und wurde bis heute nicht gehackt, dabei hat man den Biosdump, also algorithmus-implementierung usw. nur die keys sind in einem gesichertem bereich.falls du ein wenig darueber lesen willst @Shade http://electronicdesign.com/Articles/ArticleID/18115/18115.html
In a conventional LFSR-based encryptor, the clock used to run the shift registers and the keying algorithm generator is the same as that used by or recovered from the incoming data (Fig. 1). The incoming data is XORed (Exclusive ORed) with the output from the last shift register in the main algorithm generator
/rapso
-
-
rüdiger schrieb:
für den OP mags aber trotzdem das richtige sein, wenn man an seinen 8-bitter denkt. noch ein bisschen 'security thru obscurity' dazu und dann passt das. ich glaub nicht, dass sich irgendwelche geheimdienste dran machen werden, sein system zu knacken.
-
naja, beim nds haben sich echt massig leute versucht und man hat lediglich einen weg gefunden _nach_ der signaturpruefung das rom auszutauschen.
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.
-
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.
-
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.