Verschluesselung fuer Poin2Point Kommunikation mit wenig CPU last
-
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.
hätte ich auch gesagt.
-
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!
Wenn die Magnetkartenleser RSA aushalten, dann kann man auch einen vernünftigen Verschlüsselungsalgorithmus nehmen. Es gibt ja auch Algorithmen, die kleiner und schneller sind, als zB AES. Ich denke mal, dass es auch nicht so viel Aufwand wäre im Zweifelsfall TLS mit einem alternativen Verschlüsselungsverfahren zu benutzen.
Ganz zu schweigen davon, dass Shade dann ja noch ein ganzes Protokoll dazu entwerfen müsste. Nichts gegen Shade. Aber ohne große Erfahrung kann man bei so etwas leicht Fehler machen.
-
Shade Of Mine schrieb:
Die CPU power der embedded geraete ist ziemlich niedrig, genaue MHz zahlen stehen noch nicht fest, deshalb muessen wir mit sowenig last wie moeglich auf den geraeten auskommen.
vielleicht die verschlüsselung in einen externen chip auslagern?
schau mal hier: http://point-at-infinity.org/avraes/
-
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!
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.
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.
-
Also ich würde gern wissen, welche Sicherheitsanforderung vorliegen. Wirklich Sicherheit, Pseudosicherheit wegen juritsche Rahmenbedinung.
-
rüdiger schrieb:
...und wie willst du die in einem Magnetkartenleser einbauen? Ne ne ne
mit ner z-diode, oder einem rauschgenerator: http://www.techlib.com/electronics/pinknoise.htm
oder gleich was fertiges nehmen: http://home.comcast.net/~orb/
geht alles, also nicht immer nur 'nein' sagen. wir sind ja nicht im c++ forum.
-
-fricky- schrieb:
rüdiger schrieb:
...und wie willst du die in einem Magnetkartenleser einbauen? Ne ne ne
mit ner z-diode, oder einem rauschgenerator: http://www.techlib.com/electronics/pinknoise.htm
oder gleich was fertiges nehmen: http://home.comcast.net/~orb/
geht alles, also nicht immer nur 'nein' sagen. wir sind ja nicht im c++ forum.
es darf kein echter zufallsgenerator sein, es muss ein pseudogenerator sein, sodass beide seiten die gleichen werte erhalten ;).
-
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.
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?
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
-fricky- schrieb:
rüdiger schrieb:
...und wie willst du die in einem Magnetkartenleser einbauen? Ne ne ne
mit ner z-diode, oder einem rauschgenerator: http://www.techlib.com/electronics/pinknoise.htm
oder gleich was fertiges nehmen: http://home.comcast.net/~orb/
geht alles, also nicht immer nur 'nein' sagen. wir sind ja nicht im c++ forum.
Das Rauschen könnte man ja beeinflussen oder selbst auslesen, wenn man Zugang zum Gerät hat.
rapso schrieb:
-fricky- schrieb:
rüdiger schrieb:
...und wie willst du die in einem Magnetkartenleser einbauen? Ne ne ne
mit ner z-diode, oder einem rauschgenerator: http://www.techlib.com/electronics/pinknoise.htm
oder gleich was fertiges nehmen: http://home.comcast.net/~orb/
geht alles, also nicht immer nur 'nein' sagen. wir sind ja nicht im c++ forum.
es darf kein echter zufallsgenerator sein, es muss ein pseudogenerator sein, sodass beide seiten die gleichen werte erhalten ;).
Und damit funktioniert OTP eben nicht. OTP verlangt echte Zufallszahlen als Schlüssel!
-
Zeus schrieb:
Also ich würde gern wissen, welche Sicherheitsanforderung vorliegen. Wirklich Sicherheit, Pseudosicherheit wegen juritsche Rahmenbedinung.
Juristisch - nichts. Es werden keine Personenbezogenen Daten übermittelt - aber es werden eben Magnetstreifen erstellt und wir wolle nicht dass Jemand anhand des Datenverkehrs den wir haben selber solche Magnetkarten erstellt und unsere Kartenleser damit austricksen kann.
Der Datenverkehr findet auch nicht über das Internet statt, sondern in mehr oder weniger geschlossenen Netzen - wobei hier natürlich durchaus auch sowas wie WLAN vorkommen kann - die Netze sind also nicht abgesichert und tw sogar absichtlich offen für unbekannte Clients.
Wir garantieren halt eine gewisse Sicherheit wenn man unser System verwendet und sie damit (aktuell eben wegen besserer Sicherheit der Magnetstreifen) durchaus nicht schlecht positioniert.
-
rapso schrieb:
es darf kein echter zufallsgenerator sein, es muss ein pseudogenerator sein, sodass beide seiten die gleichen werte erhalten
verschlüsselung ist so ziemlich unwirksam, wenn man pseudo-zufallswerte nimmt, die auch ein angreifer vorausberechnen kann. wenn der verschlüsselungs-algo initialisierungsvektoren usw. austauschen muss, dann sollte er sich besser sowas hier bedienen: http://en.wikipedia.org/wiki/HMAC
rüdiger schrieb:
-fricky- schrieb:
rüdiger schrieb:
...und wie willst du die in einem Magnetkartenleser einbauen? Ne ne ne
mit ner z-diode, oder einem rauschgenerator: http://www.techlib.com/electronics/pinknoise.htm
oder gleich was fertiges nehmen: http://home.comcast.net/~orb/
geht alles, also nicht immer nur 'nein' sagen. wir sind ja nicht im c++ forum.
Das Rauschen könnte man ja beeinflussen oder selbst auslesen, wenn man Zugang zum Gerät hat.
was iss'n das für'n argument? wenn man zugang zum gerät hat, zumindenst auf dem level, dass man hardwareeingriffe machen kann, dann ist sowieso jede art von verschlüsselung für die katz.
-
-fricky- schrieb:
was iss'n das für'n argument? wenn man zugang zum gerät hat, zumindenst auf dem level, dass man hardwareeingriffe machen kann, dann ist sowieso jede art von verschlüsselung für die katz.
Ne, das stimmt nicht. Zumindest Verschlüsselungschips, Smartcards etc. sind ja so gebaut, dass man das Gerät zerstören müsste um einen Zugriff auf die Interna zu bekommen.
Aber ja, dass Argument ist ein bisschen weit hergeholt. Nur steht es wohl außer Frage, dass Shade an jedes Gerät noch zusätzliche Hardware basteln kann. Zumal sich dann ja eher ein Verschlüsselungschip anbieten würde.
Und das Rauschen kann man ja immer noch in gewisser Hinsicht beeinflussen bzw. Beeinflussungen des Rauschens ausnutzen.Mein Punkt ist einfach nur: OTP ist was für die Theorie. In der Praxis ist der Einsatz einfach nicht realistisch durchführbar (Gibt natürlich ein paar Spezialfälle. Aber die sind vernachlässigbar) oder führt dazu, dass das System unsicher wird. Die Amis konnten zB während des 2. Weltkriegs die Kommunikation des Auswärtigenamtes lesen, obwohl die OTP benutzten, einfach weil der Zufallsgenerator mit dem die Schlüssel generiert wurden nicht zufällig genug war.
-
Warum muss der client das passwort generieren? Das kann doch auch der Server machen.
-
nachgefragt schrieb:
Warum muss der client das passwort generieren? Das kann doch auch der Server machen.
Aber dann hat man immer noch das Problem den Schlüssel zu verteilen. Und bedenke, dass du für jedes verschlüsselte Byte ein Byte Schlüssel benötigt.
Sprich es bringt dir auch nichts den Schlüssel via asymmetrischer Kryptographie zu verteilen, da du dann genauso gut die Nachricht direkt via asymmetrischer Kryptographie schicken könntest.
=> OTP ist nicht praktikabel.
-
rüdiger schrieb:
Aber dann hat man immer noch das Problem den Schlüssel zu verteilen. Und bedenke, dass du für jedes verschlüsselte Byte ein Byte Schlüssel benötigt.
Sprich es bringt dir auch nichts den Schlüssel via asymmetrischer Kryptographie zu verteilen, da du dann genauso gut die Nachricht direkt via asymmetrischer Kryptographie schicken könntest.
=> OTP ist nicht praktikabel.
rapso schrieb:
...fuer ne art one-time-pad...
Nen richtigen OTP wollte er glaub ich nicht, sondern nur ein relativ langes Passwort, so habs ich zumindest verstanden.
XOR dürfte halt die beste Wahl sein, wenn man wirklich extrem CPU Power sparen muss, sonst kann man auch was aufwendigeres nehmen.
-
nachgefragt schrieb:
XOR dürfte halt die beste Wahl sein, wenn man wirklich extrem CPU Power sparen muss, sonst kann man auch was aufwendigeres nehmen.
XOR ist ziemlich anfällig für ein paar triviale Attacken.
-
nachgefragt schrieb:
Nen richtigen OTP wollte er glaub ich nicht, sondern nur ein relativ langes Passwort, so habs ich zumindest verstanden.
XOR dürfte halt die beste Wahl sein, wenn man wirklich extrem CPU Power sparen muss, sonst kann man auch was aufwendigeres nehmen.
Dann kann man sich das XOR auch gleich sparen, weil ein derartiges Vorgehen absolut gar keinen Schutz bietet. Man kann mittels Koinzidenzerfassung die Schlüssellänge ermitteln und muss dann nur noch den Text um die Schlüssellänge verschieben und mit dem Original XORen.
-
rüdiger schrieb:
nachgefragt schrieb:
Nen richtigen OTP wollte er glaub ich nicht, sondern nur ein relativ langes Passwort, so habs ich zumindest verstanden.
XOR dürfte halt die beste Wahl sein, wenn man wirklich extrem CPU Power sparen muss, sonst kann man auch was aufwendigeres nehmen.
Dann kann man sich das XOR auch gleich sparen, weil ein derartiges Vorgehen absolut gar keinen Schutz bietet. Man kann mittels Koinzidenzerfassung die Schlüssellänge ermitteln und muss dann nur noch den Text um die Schlüssellänge verschieben und mit dem Original XORen.
Du willst doch nicht sagen, dass man nur die Schlüssellänge wissen muss und schon die XOR Verschlüsselung geknackt hat? Was meinst du mit "den Text um die Schlüssellänge verschieben"? Welchen Text? Den Original hast du doch nicht. Und was soll Text verschieben für ne Operation sein?
-
nachgefragt schrieb:
rüdiger schrieb:
nachgefragt schrieb:
Nen richtigen OTP wollte er glaub ich nicht, sondern nur ein relativ langes Passwort, so habs ich zumindest verstanden.
XOR dürfte halt die beste Wahl sein, wenn man wirklich extrem CPU Power sparen muss, sonst kann man auch was aufwendigeres nehmen.
Dann kann man sich das XOR auch gleich sparen, weil ein derartiges Vorgehen absolut gar keinen Schutz bietet. Man kann mittels Koinzidenzerfassung die Schlüssellänge ermitteln und muss dann nur noch den Text um die Schlüssellänge verschieben und mit dem Original XORen.
Du willst doch nicht sagen, dass man nur die Schlüssellänge wissen muss und schon die XOR Verschlüsselung geknackt hat? Was meinst du mit "den Text um die Schlüssellänge verschieben"? Welchen Text? Den Original hast du doch nicht. Und was soll Text verschieben für ne Operation sein?Man muss ja noch nicht einmal die Schlüssellänge wissen, da man diese auch gut über statistische Methoden rausfinden kann. Natürlich nicht den Originaltext, sondern den verschlüsselten Text. Text verschieben um j bedeutet, dass du aus a[i] a[(i+j)%length] machst.
Okay, das Ergebnis muss man dann noch einmal auswerten. Eine Anleitung findest du hier http://www.richardclegg.org/networks2/2003/codes.pptAber hier ist auch ein Dienst, der das alles für dich übernehmen kann: http://cryptology.dod.net/xor/xor.php
-
http://cryptology.dod.net/xor/xor.php antwortet gerade nicht.
Shift the ciphertext by the key length and XOR with itself. Since a | b | b = a, this removes the key and leaves us with the plaintext XOR'd with a copy of itself shifted by the key length.
Now have k mono-alphabetic substitution ciphers so do frequency analysis on each one in turn.Geht diese Analyse nur, wenn man normalen Text verwendet oder auch bei unbekanntem binarys?
-
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. 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.