Verschluesselung fuer Poin2Point Kommunikation mit wenig CPU last
-
~fricky schrieb:
nachgefragt schrieb:
Geht diese Analyse nur, wenn man normalen Text verwendet oder auch bei unbekanntem binarys?
geht nur mit text. ausserdem ist es abhängig von der verwendeten sprache.
Nein, es geht nicht nur mit Text. Siehe die verlinkte Seite. Es geht auch mit Binaries, wenn du statistische Informationen darüber ermitteln kannst.
~fricky schrieb:
wenn du z.b. ein binary mit einem xor-schlüssel vercryptest, der genau so lang ist wie das file selbst, dann ist es absolut unknackbar.
Das ist Blödsinn, wie ich hier bereits geschrieben habe.
-
rüdiger schrieb:
~fricky schrieb:
wenn du z.b. ein binary mit einem xor-schlüssel vercryptest, der genau so lang ist wie das file selbst, dann ist es absolut unknackbar.
Das ist Blödsinn, wie ich hier bereits geschrieben habe.
mal ein kleines beispiel: der text "hello world" wird XOR mit sich selbst verschlüsselt. heraus kommen 11 nullen. nun verrat mir mal, wie ein hacker aus 11 nullen "hello world" macht, wenn er den schlüssel nicht hat?
übrigens solltest du die links auch selber lesen, die du gepostet hast. schlecht sind die nämlich nicht.
-
~fricky schrieb:
rüdiger schrieb:
~fricky schrieb:
wenn du z.b. ein binary mit einem xor-schlüssel vercryptest, der genau so lang ist wie das file selbst, dann ist es absolut unknackbar.
Das ist Blödsinn, wie ich hier bereits geschrieben habe.
mal ein kleines beispiel: der text "hello world" wird XOR mit sich selbst verschlüsselt. heraus kommen 11 nullen. nun verrat mir mal, wie ein hacker aus 11 nullen "hello world" macht, wenn er den schlüssel nicht hat?
übrigens solltest du die links auch selber lesen, die du gepostet hast. schlecht sind die nämlich nicht.
Es funktioniert natürlich nicht immer. Das habe ich nie behauptet. Aber dein Beispiel ist ja auch vollkommen irrelevant. Besonders für Shades Fall.
Bei Shade kann ein Angreifer ohne Probleme an eine ausreichende Datenmenge kommen. Je nachdem kann der Angreifer sogar an eine beschriebene Magnetkarte kommen und hat entsprechende Plaintextdaten. Damit fällt XOR sowieso in sich zusammen (a ^ b ^ a = b). Wenn es sich um einen Kunden handelt oder jemand ein Gerät klaut, ist es auch relativ einfach mögliche Schlüssel, Formate etc. auszulesen. Und in der Produktion ist es ja auch nicht unbedingt möglich für jeden Kunden einen eigenen Schlüssel zu hinterlegen, so dass man mit einem erfolgreichen Angriff _alle_ Kunden knackt.
Natürlich, wenn Shade nur das minimalste Minimum an Sicherheit gewährleisten will, kann er zu solchen Methoden greifen. Aber ich denke mal, dass es ihm schon darum geht eine vernünftige Sicherheit anzubieten. Wenn es um ein erfolgreiches/zentrales Produkt in der Firma geht, kann nämlich ein erfolgreicher Angriff dafür sorgen, dass die ganze Firma den Bach runtergeht.
Und eigentlich würde ich hier gerne diese Schwachsinns Diskussion beenden und lieber warten, bis Shade etwas zu dem Thema sagt oder fragt.
-
Hmmm von dem bestehende Verfahren:
DES -> zu unsicher
3DES -> vebraucht zuviel Rechenzeit
AES -> scheint das richtige zu sein ;o
-
rüdiger schrieb:
Bei Shade kann ein Angreifer ohne Probleme an eine ausreichende Datenmenge kommen. Je nachdem kann der Angreifer sogar an eine beschriebene Magnetkarte kommen und hat entsprechende Plaintextdaten.
Eine Magnetkarte zu bekommen ist sogar trivial, da sie ja eben an Kunden ausgegeben wird
Man muss also nur Kunde von unseren Kunden sein.Aber mit den Daten auf der Magnetkarte kann man zum Glück nichts anfangen (ist nicht bei allen Konkurrenten der Fall). Aber natürlich kann man wenn man die Kommunikation von Client zu MagnetkartenEncoder mitliest und dann die erstellte Magnetkarte sich ansieht einen Teil der Daten in Klartext lesen.
Damit fällt XOR sowieso in sich zusammen (a ^ b ^ a = b). Wenn es sich um einen Kunden handelt oder jemand ein Gerät klaut, ist es auch relativ einfach mögliche Schlüssel, Formate etc. auszulesen. Und in der Produktion ist es ja auch nicht unbedingt möglich für jeden Kunden einen eigenen Schlüssel zu hinterlegen, so dass man mit einem erfolgreichen Angriff _alle_ Kunden knackt.
Das ist zum Glück nicht möglich. Wenn man die Kommunikation mitliest und versteht kann man "nur" kopien der erstellten Magnetkarten machen, man kann dennoch nicht selber eine neue erstellen. Aber da es ja nach Lage trivial ist die Kommunikation mitzulesen, sind kopien schon schlimm genug.
Und eigentlich würde ich hier gerne diese Schwachsinns Diskussion beenden und lieber warten, bis Shade etwas zu dem Thema sagt oder fragt.
Ich lese mit und finde es interessant. Ihr habt viele punkte genannt denen wir nachgehen werden.
Symmetrische Verschlüsselung gefällt mir aus folgendem Grund nicht:
Ich logge die Kommunikation zwischen Client und Magnetkartenencoder mit und sende dann nachts wenn ich physischen zugang zu dem MagnetkartenEncoder habe die selben Daten und habe eine Kopie der erstellten Magnetkarte. Das könnte zB ein Mitarbeiter des Kunden machen - der hat ja problemlos physischen Zugang zu den Geräten.
-
Symmetrische Verschlüsselung gefällt mir aus folgendem Grund nicht:
Ich logge die Kommunikation zwischen Client und Magnetkartenencoder mit und sende dann nachts wenn ich physischen zugang zu dem MagnetkartenEncoder habe die selben Daten und habe eine Kopie der erstellten Magnetkarte. Das könnte zB ein Mitarbeiter des Kunden machen - der hat ja problemlos physischen Zugang zu den Geräten.vergiss nicht deinen 8 bitter. der käme bei AES schon ins schwitzen. asymmetrische ciphers rechnen etwa 1000 mal so lange und brauchen viel mehr taktzyklen. deine magnetkarten-user wollen bestimmt keine halbe stunde warten, bis der 8-bitter fertig ist, oder?
übrigens: gegen diese sogenannten 'replay attacks' gibts auch mittel und wege, wie z.b. austausch von autentifizierungs-keys mit (ebenfalls verschlüsseltem) zeitstempel darin usw.
btw: ist 'ne technische bibliothek in der nähe, dann leih' dir mal das buch 'applied cryptography' aus. ich würde ja gern 'nen download-link posten, aber dann wird der mod wieder sauer.
-
Shade Of Mine schrieb:
rüdiger schrieb:
Bei Shade kann ein Angreifer ohne Probleme an eine ausreichende Datenmenge kommen. Je nachdem kann der Angreifer sogar an eine beschriebene Magnetkarte kommen und hat entsprechende Plaintextdaten.
Eine Magnetkarte zu bekommen ist sogar trivial, da sie ja eben an Kunden ausgegeben wird
Man muss also nur Kunde von unseren Kunden sein.Aber mit den Daten auf der Magnetkarte kann man zum Glück nichts anfangen (ist nicht bei allen Konkurrenten der Fall). Aber natürlich kann man wenn man die Kommunikation von Client zu MagnetkartenEncoder mitliest und dann die erstellte Magnetkarte sich ansieht einen Teil der Daten in Klartext lesen.
Das würde ja vermutlich schon reichen um XOR zu knacken.
Shade Of Mine schrieb:
Damit fällt XOR sowieso in sich zusammen (a ^ b ^ a = b). Wenn es sich um einen Kunden handelt oder jemand ein Gerät klaut, ist es auch relativ einfach mögliche Schlüssel, Formate etc. auszulesen. Und in der Produktion ist es ja auch nicht unbedingt möglich für jeden Kunden einen eigenen Schlüssel zu hinterlegen, so dass man mit einem erfolgreichen Angriff _alle_ Kunden knackt.
Das ist zum Glück nicht möglich. Wenn man die Kommunikation mitliest und versteht kann man "nur" kopien der erstellten Magnetkarten machen, man kann dennoch nicht selber eine neue erstellen. Aber da es ja nach Lage trivial ist die Kommunikation mitzulesen, sind kopien schon schlimm genug.
Ich meinte auch eher, dass man dann den Schlüssel für alle Geräte hätte. Entsprechend könnte man überall einfach mitlesen oder den Schlüssel gleich auf Rapidshare hochladen und einen Link an alle Konkurrenten, Cracker und deinen Chef schicken.
Shade Of Mine schrieb:
Symmetrische Verschlüsselung gefällt mir aus folgendem Grund nicht:
Ich logge die Kommunikation zwischen Client und Magnetkartenencoder mit und sende dann nachts wenn ich physischen zugang zu dem MagnetkartenEncoder habe die selben Daten und habe eine Kopie der erstellten Magnetkarte. Das könnte zB ein Mitarbeiter des Kunden machen - der hat ja problemlos physischen Zugang zu den Geräten.Das meinte ich am Anfang mit der Gefahr der eigenen Protokolle :). So etwas kann man natürlich durch gewisse Methoden vermeiden. Aber man kann sich am Ende halt viele Probleme an Bord holen, die man auf den ersten Blick gar nicht sieht.
Aber ich würde vielleicht auch eher auf einer Mailingliste/Newsgroup/Forum fragen, wo sich die Leute besser mit dem Thema auskennen.
~fricky schrieb:
btw: ist 'ne technische bibliothek in der nähe, dann leih' dir mal das buch 'applied cryptography' aus. ich würde ja gern 'nen download-link posten, aber dann wird der mod wieder sauer.
Das Buch kann ich auch nur sehr empfehlen! :lieve:
Und ja, bitte keine Download-Links hier posten, da dies zu rechtlichen Problemen für uns führen kann!
-
Danke fuer den Tipp, das Buch hab ich naemlich sogar.
Aber wie gesagt: wir wollten nie etwas eigenes erfinden. Ich suche lediglich schnelle Algorithmen die eine ordentliche Sicherheit bieten (eben performance im tausch gegen Sicherheit). Aber jetzt gibt es ja schonmal massig Sachen zum weiter verfolgen.
-
Ich kann mich ja irren, aber ich glaub was rapso gemeint hat war ein Stromverschluesseler, kein OTP; dazu braucht er wirklich einen PRNG (und keinen RNG) und kann nachher Problemlos mittels XOR arbeiten. Ausserdem ist das wesentlich schneller als AES & Co.
EDIT: das waer dann auch mein Vorschlag. Mittels DH einen Schluessel erzeugen, damit den PRNG initialisieren und ab geht die Post.
Oder einen bestehenden Stream-Cyper verwenden: http://en.wikipedia.org/wiki/ESTREAM
-
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?