Verschlüsselung der Daten auf Android -, AES-GCM-oder nur-AES?
Mein team braucht, um eine Lösung entwickeln zu verschlüsseln binärer Daten (gespeichert als byte[]) im Rahmen einer Android-Anwendung in Java geschrieben. Die verschlüsselten Daten werden übertragen und auf verschiedene Weise gelagert, während die Beschädigung von Daten nicht ausgeschlossen werden kann. Schließlich ein weiteres Android-Anwendung (wieder) in Java geschrieben) haben, um die Daten zu entschlüsseln.
Es wurde bereits beschlossen, dass der Verschlüsselungs-Algorithmus hat zu AES, mit einem Schlüssel von 256 bit.
Allerdings würde ich mag, um eine informierte Entscheidung über die Verwendung der AES-Implementierung und/oder die "mode" - wir sollten Sie nutzen. Ich habe gelesen, über so etwas GCM-Modus, und wir haben einige tests gemacht mit ihm (mit BouncyCastle/SpongyCastle), aber es ist mir nicht ganz klar, was genau AES-GCM ist und was er "kauft" uns im Vergleich zu reinen AES - und ob es keine trade-offs berücksichtigt werden.
Hier ist eine Liste von Fragen/Anforderungen/Fragen, die wir haben:
-
Polsterung: die Daten, die wir brauchen, um zu verschlüsseln wird nicht immer ein Vielfaches von 128 bits, so dass die AES-Implementierung/mode sollte hinzufügen, Polsterung, aber nur wenn es nötig ist.
Ich hatte den Eindruck, dass eine nur AES-Implementierung, so wie es von derjavax.crypto.Cipherwürde das nicht tun, aber erste tests zeigten, dass es funktioniert. Also ich vermute, dass die Polsterung Anforderung an sich kein Grund sich zu greifen, um so etwas wie GCM statt "plain" AES". Ist das richtig? -
Authentifizierung: Wir brauchen eine narrensichere Weise, die erkennen, wenn eine Beschädigung der Daten aufgetreten ist. Aber im Idealfall wollen wir auch erkennen, wenn die Entschlüsselung wird versucht, mit einem falschen Schlüssel. Daher wollen wir in der Lage sein, zu unterscheiden zwischen den beiden Fällen. Der Grund, warum ich landete in Anbetracht GCM in Erster Linie wurde durch dieses Stackoverflow-Frage, wo einer der Responder scheint zu implizieren, dass diese Unterscheidung möglich ist, unter Verwendung von AES-GCM, obwohl er nicht eine ausführliche Erklärung (geschweige code).
-
Minimieren overhead: Wir müssen zu begrenzen overhead für die Speicherung und übertragung der verschlüsselten Daten. Daher möchten wir wissen, ob und in welchem Ausmaß die Wahl für eine bestimmte AES-Implementierung/mode beeinflusst die Menge an overhead.
-
Verschlüsselung/Entschlüsselung Leistung: Obwohl es nicht ein primäres Anliegen, wir werden Fragen, inwieweit die Wahl eines bestimmten AES-Implementierung/mode beeinflusst die Verschlüsselung und Entschlüsselung der Leistung, sowohl in Bezug auf CPU-Zeit und Speicherbedarf.
Vielen Dank im Voraus für jede Beratung, Klärung und/oder code-Beispiele.
EDIT: delnan hilfsbereit wies darauf hin, es gibt keine solche Sache als "plain AES". Um zu klären, was ich meinte, ist in der Java-built-in AES-Unterstützung.
Etwa so: Cipher localCipher = Cipher.getInstance("AES");
- Was ist "plain" AES? Es sei denn, Sie sind Umgang mit nur 256 bit der Daten. Wenn Sie mehr Daten haben als das, Sie sind unbedingt einige-Modus. Vielleicht ist Ihre Bibliothek wählt ein Modus standardmäßig (von dem, was ich gehört habe, haben viele Bibliotheken stellen eine ziemlich unsichere Wahl hier). So sollten Sie prüfen, welcher Modus tatsächlich verwendet, wenn Sie "reines" AES".
- Vielen Dank für Ihr Kommentar, @delnan, ich machte eine Bearbeiten, um zu verdeutlichen, was ich meinte.
Du musst angemeldet sein, um einen Kommentar abzugeben.
2012 die Antwort ist, GCM, es sei denn, Sie haben schwerwiegende Kompatibilitätsprobleme.
GCM ist ein Authentifizierte Verschlüsselung - Modus. Es bietet Sie Vertraulichkeit (Verschlüsselung), Integrität und Authentifizierung (MAC) in einem Rutsch.
So weit, die normalen Betriebsarten worden EZB (das ist der Standard für Java), CBC, CTR, OFB, und ein paar andere. Sie alle, sofern Sie die Verschlüsselung nur. Geheimhaltung an sich ist selten nützlich, ohne die Integrität allerdings; hatte man kombinieren wie klassische Modi, mit Integritätsprüfung in einer ad-hoc-Weise. Seit Kryptographie ist schwer zu bekommen Recht, oft sind solche Kombinationen waren unsicher, langsamer als nötig, oder sogar beide.
Authentifizierte Verschlüsselung Modi wurden (vor kurzem) erstellt von Kryptographen, um dieses problem zu lösen. GCM ist eine der am meisten erfolgreich: es wurde ausgewählt von NIST, es effizient, es ist zum patent frei, und es tragen kann Additional Authenticated Data (das heißt, Daten, die den Aufenthalt in der klaren, aber für die Sie überprüfen können, Authentizität). Für eine Beschreibung der weiteren Betriebsarten finden Sie dieser hervorragende Artikel von Matthew Green.
Kommen, um Ihre Anliegen:
Polsterung: standardmäßig benutzt Java PKCS#7-Auffüllung. Das funktioniert, aber es ist oft anfällig für padding-oracle-Angriffe, die am besten besiegt mit einem MAC. GCM bettet bereits einen MAC (genannt GMAC).
Authentifizierung: AES-GCM-dauert nur ein AES-Schlüssel als Eingabe, keine Passwörter. Es wird Ihnen sagen, wenn der AES-Schlüssel falsch ist oder die Nutzlast manipuliert wurde, aber solche Bedingungen werden wie eines behandelt. Stattdessen sollten Sie erwägen, einen entsprechenden Schlüssel-Ableitung Algorithmus wie PBKDF2 oder bcrypt, um daraus die AES-Schlüssel aus dem Passwort. Ich glaube nicht, dass es immer möglich zu sagen, ob das Kennwort falsch ist oder wenn der payload geändert wurde, da die Daten, die notwendig sind, um zu überprüfen, die ehemaligen können immer beschädigt werden. Sie können verschlüsseln Sie eine kleine bekannte Zeichenfolge (mit ECB AES), schicken Sie es zusammen, und es verwenden, um zu überprüfen, ob das Passwort korrekt ist.
Minimieren overhead: Am Ende des Tages, alle Modi führt zu den gleichen Aufwand (etwa 10 bis 20 bytes), wenn Sie wollen-Authentifizierung. Es sei denn, Sie arbeiten mit sehr kleinen Nutzlasten dieser Punkt ignoriert werden kann.
Leistung: GCM ist ziemlich gut, es ist ein online - Modus (ohne Puffer die ganze payload, also weniger Speicher), ist es, parallelisierbare, und es erfordert eine AES-Betrieb und eine Galois-Multiplikation pro Klartext-block. Klassische Modi wie EZB schneller sind (ein AES-Betrieb pro block nur), sondern - wieder - müssen Sie auch eine Rolle in der Integrität der Logik, die bis Ende Mai wird langsamer sein als GMAC.
Nachdem das gesagt ist, muss man sich bewusst sein, dass die GCM-Sicherheit stützt sich auf eine gute Zufallszahl-generation für die Erstellung des IV.