Guten Tag, ich bin auf der Suche nach einer einfachen Art und Weiße eine Datenkommunikation zu verschlüsseln. Angenommen ein Schlüsselaustauschverfahren ist bereits gegeben. Beispielsweise über Diffie-Helmann. Dann fehlt nur noch ein geeigneter Verschlüsselungsalgorithmus. Könnt ihr mir einen Algorithmus oder ein Verfahren empfehlen, welches dazu verwendet werden kann auch kleinere Datenblöcke so zu verschlüsseln, dass sich die Nachrichtengröße nicht ändert? Ich meine: Wenn 32 Bit Klartext verschlüsselt werden, soll die verschlüsselte Nachricht ebenfalls nur 32 Bit groß sein. Mir wäre da beispielsweise ein Stromverschlüsselungsverfahren wie beispielsweise RC4 in den Sinn gekommen. Beim standard AES handelt es sich ja um ein Blockverschlüsselungsverfahren und zu kleine Nachrichten müssen mit padding Bytes aufgefüllt werden. Blockverfahren können nicht angewendet werden. Auch Verfahren wie ChaCha20-Poly wo noch eine MAC beigefügt wird kann ich nicht verwenden. Habt ihr eine Empfehlung?
Tbd_01 schrieb: > ich bin auf der Suche nach einer einfachen Art und Weiße eine > Datenkommunikation zu verschlüsseln. XOr Dazu reicht 1 Byte.
Bosk schrieb: > XOr > > Dazu reicht 1 Byte. 1. Das nennt sich OTP 2. Das geht sogar mit nur 1 Bit Bedingung fuer OTP: Der Schluessel muss mindestens so lang sein wie die Nachricht und der Schluessel darf nur ein einziges mal verwendet werden.
Wie sicher soll die Verschlüsselung sein? Reicht ein einfaches Verschleiern oder soll es gegen Brute Force Angriffe der NSA sicher sein?
AES (und auch jeder andere Blockchiffre) kann auch als Stromverschlüsselung eingesetzt werden.
Georg G. schrieb: > Wie sicher soll die Verschlüsselung sein? Reicht ein einfaches > Verschleiern oder soll es gegen Brute Force Angriffe der NSA sicher > sein? Die Verschlüsselung sollte als Verschlüsselungsalgorithmus zumindest als solcher anerkannt sein. Damit meine ich, dass es schon etwas mehr sein soll als nur ein einfaches XOR aber es braucht auch keinen Cyber Attacken von erfahrenen Hackern standhalten.
Tbd_01 schrieb: > …ein einfaches XOR… Den Hacker will ich sehen, der diese Operation (mit einem OTP als zweitem Operand) dechiffriert und nicht Bruce Schneier oder Chuck Norris heißt. Vielleicht nimmst du mal Zettel und Stift und probierst mit 4 Datenbytes und 4 Byte Schlüssellänge die XOR-Operation aus. Was da rauskommt ist – ohne Kenntnis des Schlüssels – Rauschen. (Gute Schlüssel setze ich einfach so voraus.)
Tbd_01 schrieb: > Damit meine ich, dass es schon etwas mehr sein soll als nur ein > einfaches XOR aber es braucht auch keinen Cyber Attacken von erfahrenen > Hackern standhalten. Wie wäre es mit einer Tabelle in Flash? Sie könnte z.B. 256 bytes sein. Die Zusammensetzung byte zu byte könnte willkürlich gewählt werden.
Hi Guck dir mal trivium an. Damit kann man ein einzelnes byte verschlüsseln.
Boris O. schrieb: > Den Hacker will ich sehen, ... Nachricht XOR Schluessel = verschluesselte Nachricht Aber auch: Bekannte Nachricht XOR zugehoerige verschluesselte Nachricht = Schluessel Und falls der Schluessel mehrmals verwendet wird, kennt man dann auch die weiteren Nachrichten. Dafuer reicht tatsaechlich ein Zettel.
Chuck Schneier schrieb: > Und falls der Schluessel mehrmals verwendet wird Was ist dir an dem Ausdruck OTP nicht bekannt? Notfalls kann man im Flash 16kBytes oder mehr Pseudo Random ablegen und als OTP nutzen. Das reicht für einige Messages.
Georg G. schrieb: > Was ist dir an dem Ausdruck OTP nicht bekannt? Das (einzige) Problem an OTP ist doch, dass es bei Sender und Empfänger bekannt sein muss. Ich muss also im Zweifel über eine anderweitige Verbindung (Asymetrisch verschlüsselt, Panzerwagen, Vereinbarung, z.B. Bildzeitung dritte Seite 11-99.Buchstabe) den OTP übertragen ohne das ihn jemand mitlesen kann.
oder der Schlüssel wird bereits in der Fimware beider Geräte integriert.
Dirk F schrieb: > oder der Schlüssel wird bereits in der Fimware beider Geräte > integriert. Das halte ich für eine schlechte Idee, weil jeder mit Zugang zur Firmware auch Zugang zum Schlüssel hat. Bisher hat es noch für die meisten Systeme mit eingesperrten (privaten) Schlüsseln erfolgreiche Angriffe gegeben. Dafür reichten bisher Seitenkanalattacken (Schwankungen der Versorgungsspannung). Später ging man zu Störabstrahlung über. Mittlerweile ist man bei gezielter EMV-Störung angekommen. Das dauert zwar ein paar Stunden und erfordert Laborausrüstung, aber wenn der Preis hoch genug ist, lohnt sich das irgendwann. Im einfachsten Fall sendet die Quelle und verwirft einen Teil des OTP und der Empfänger erhält die Botschaft nicht. Die nächste Botschaft trifft nun ein und die Startposition des OTP passt nicht. Etwas Dialog einzufügen und den OTP transaktional zu steuern (erst löschen, wenn der Empfänger bestätigt) bedeutet weitere Angriffsfläche. Die ersten One-Time-Pads wurden auf Schallplatten gepresst. Aktuelle Verschlüsselungsverfahren arbeiten nach dem Prinzip der Pseudozufallsfunktion mit Startwert. Das teure asymmetrische Verfahren transportiert den Startwert, der ist ziemlich klein, bspw. 2048bit. Im Nachhinein wird dieser Startwert für eine Pseudo-Zufallsfunktion genutzt, den nun folgenden OTP bereitzustellen. Die ganze Magie mit Rückkopplung (verschlüsseltes Wort wird nächster Startwert der Pseudozufallsfunktion oder dritter Wert für ein weiteres XOR), Entropie-Erhöhung (Einspeisung von Zufallswerten, Kompression) und begrenzte Sitzungszeit machen dann den Algorithmus aus. Du solltest dir folglich genau überlegen, welche Angriffsszenarien dein Algorithmus überstehen soll. Aber du bleibst ja ungenau, es herrscht Salamitaktik und Verschlüsselung selbst zu entwickeln ist keine gute Idee.
Tbd_01 schrieb: > Auch Verfahren wie ChaCha20-Poly wo noch eine MAC beigefügt wird kann > ich nicht verwenden. Dann nutze halt nur ChaCha20, keiner zwingt doch ChaCha20-Poly1305 zu verwenden. Oder nutze AES im CTR- oder OFB-Modus.
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.