Best practices für die Verschlüsselung kontinuierliche/kleine UDP-Daten

Ich habe eine Anwendung wo ich senden mehrere kleine Daten pro Sekunde über das Netzwerk Via UDP. Die Applikation zum senden der Daten in Echtzeit (ohne Wartezeiten). Ich wollen, verschlüsseln Sie diese Daten und versichern, dass das, was ich Tue, ist so sicher wie möglich.

Da bin ich, die UDP verwenden, gibt es keine Möglichkeit SSL/TLS zu verwenden, so habe ich zum verschlüsseln jedes Paket alleine, da das Protokoll verbindungslos/unzuverlässig/ungeregelt.

Gerade jetzt, ich bin mit einer 128-bit-Schlüssel aus einer passphrase abgeleitet von der Benutzer-und AES-Standard im CBC-Modus (PBE mit AES-CBC). Ich habe mich für einen zufälligen salt mit der passphrase, um daraus die 128-bit-Schlüssel (verhindern Wörterbuch-Angriff auf die passphrase), und natürlich IVs (um zu verhindern, dass die statistische Analyse für die Pakete).

Aber ich bin besorgt über die paar Dinge:
Jedes Paket enthält eine kleine Menge von Daten (wie ein paar von integer-Werten pro Paket), die die verschlüsselte Pakete anfällig für known-plaintext-Angriffe (welche wird Ergebnis in macht es leichter, den key zu knacken). Auch, da der Schlüssel aus einer passphrase abgeleitet, dadurch wird die Tastatur so weniger (ich weiß, das Salz wird helfen, aber ich habe zu senden, die das Salz durch das Netzwerk einmal und jeder kann es bekommen). Angesichts dieser zwei Dinge kann jeder schnüffeln und speichern der gesendeten Daten, und versuchen den key zu knacken. Obwohl dieser Vorgang kann einige Zeit in Anspruch nehmen, wenn der Schlüssel einmal geknackt werden alle gespeicherten Daten entschlüsselt werden, die werden ein echtes problem für meine Anwendung.

Meine Frage ist also, was ist die best practices für das senden/verschlüsseln kontinuierliche kleine Daten über ein verbindungsloses Protokoll (UDP)?
Ist mein Weg der beste Weg, es zu tun? ...floss? ...Overkill?

Bitte beachten Sie, dass ich mich nicht Fragen, für eine 100% sichere Lösung, da es keine solche Sache.

InformationsquelleAutor der Frage temp | 2010-06-14

  1. 12

    Haben Sie mehrere Möglichkeiten. Sie können DTLS, welche version von TLS adapated für Datagramme. Es ist angegeben in einer RFC und umgesetzt in der openssl-Bibliothek. Sie können auch verwenden Sie die IKE/IPsec-Protokoll und UDP-Kapselung von IPsec-Teil. In der Regel IPsec ist verfügbar auf OS-Ebene. Sie können auch OpenVPNwas aussieht, um ein hybrid von TLS-Schlüsselaustausch und eine proprietäre UDP-basierte packet-Verschlüsselung.

    InformationsquelleAutor der Antwort James K Polk

  2. 3

    Wenn Ihr problem ist, dass die Daten zu klein ist, wie es um die Erweiterung die Daten mit Zufalls-bytes? Das macht den Text viel schwerer zu erraten.

    InformationsquelleAutor der Antwort Amnon

  3. 0

    Diese Frage ist ein wenig alt, aber was ist mit dem One-Time-Pad Art Ansatz? Sie konnte eine sichere zuverlässige transport-Mechanismus (wie HTTPS) zur übertragung des one time keys vom server auf Ihren client. Es könnte sein, zwei Sätze von Tasten-eine für client-Server und eine für server-zu-client. Jedes Datagramm würde dann eine laufende Nummer (wird verwendet, um zu identifizieren, die eine Zeit-Taste) und dann die verschlüsselte Nachricht. Da jeder Schlüssel wird verwendet, nur für ein Datagramm, sollten Sie nicht ausgesetzt werden, um die small-data-problem. Das heißt, ich bin kein Experte in diesen Sachen, also auf jeden Fall prüfen, diese Idee aus, bevor Sie es...

    InformationsquelleAutor der Antwort alarik

  4. 0

    Verwenden Ecdh-key-exchange (verwenden Sie ein Kennwort zum verschlüsseln des privaten Schlüssels; Links auf dem client) anstelle eines Kennworts. Dies ist eine sehr starke Schlüssel.

    Aes-cbc hilft nicht; die Nachrichten sind zu kurz, und Sie wollen replay-Angriffe zu verhindern. Polstern Sie Ihren 64-bit-message (zwei Ganzzahlen) mit einem Zähler (beginnend mit 0) 64 bit bedeutet 2^64 Nachrichten gesendet werden können. Verschlüsseln Sie den block zweimal (aes-ecb) und senden von e(k;m|Anzahl)|e(k, e(k;m|zählen)). Empfänger akzeptiert nur monoton steigende Zählungen, wo der zweite block ist die Verschlüsselung der ersten. Dies sind die 32 byte Nachrichten, die passen Prima in ein udp-Paket.

    wenn 2^64 Nachrichten ist zu klein; sehen, wenn Ihre Nachricht könnte kleiner sein (3 byte-Ganzzahlen bedeutet, der Zähler kann mit 80 bits); oder gehen Sie zurück zu Schritt 1 (neue private Schlüssel, die für mindestens eine Seite), sobald Sie in der Nähe (sagen wir 2^64-2^32) bis an die Grenze.

    InformationsquelleAutor der Antwort Warren MacEvoy

Schreibe einen Kommentar