Deterministische RSA-Verschlüsselung in Java

Dies ist meine erste Frage auf dieser Seite, und ich habe nur ein grundlegendes mathematisches Verständnis von RSA, also bitte ertragen Sie mit mir! :)

Ich schreibe eine Java-Webanwendung für mein Abschlussjahrprojekt an der Universität. Es ist eine webbasierte Implementierung von "Pret-a-Voter", einem sicheren Wahlsystem für diejenigen, die davon gehört haben.

Im Wesentlichen ist mein Problem, dass ich jemandem, der die Rolle eines Auditors spielen möchte, erlauben kann:

• eine Quelle Byte-Array (der zu verschlüsselnde Klartext)
• eine RSA Public Key-Datei
• ein " Ziel " Byte-Array, das das Ergebnis meiner eigenen Berechnung der Chiffredaten ist, die den Klartext und den öffentlichen Schlüssel
erhalten

Ich möchte dann, dass der Auditor in der Lage ist, die Verschlüsselung unter Verwendung der ersten beiden Elemente durchzuführen, und sich davon überzeugt haben, dass das dritte das Ergebnis ist. Daher muss die Verschlüsselung deterministisch sein, d. H. Jedes Mal, wenn die Verschlüsselung mit dem gleichen Klartext und dem öffentlichen Schlüssel wiederholt wird, die gleichen Chiffredaten erzeugt werden.

(Hinweis - Ich arbeite mit sehr kleinen Datenblöcken in diesem Projekt - es gibt überhaupt keine symmetrische Verschlüsselung ... Ich bin mir bewusst, dass dies eine "interessante" Verwendung von RSA ist!)

Jedenfalls habe ich das in Java mit

verwendet das standardmäßige zufällige Auffüllschema mit Kosten von 11 Byte (bei einem 2048-Bit-Schlüsselpaar ist es also möglich, 2048 / 8-11 = 245 Byte zu verschlüsseln). Wiederholte Verschlüsselungen desselben Klartextes erzeugen unterschiedliche Chiffriertexte, was offensichtlich nicht der ECB-Modus ist, den ich möchte.

Meine Frage ist - sollte ich Folgendes verwenden?

Ich habe an vielen Stellen gelesen, dass RSA ohne Padding unsicher ist. Liegt das daran, dass ein Angreifer ein Wörterbuch mit Klartexten / Geheimtexten erstellen kann? Dies ist ein Nebeneffekt der deterministischen Verschlüsselung, die ich benötige, um Auditoren zu ermöglichen, meine Verschlüsselung zu verifizieren, und in meinem Schema werden Auditoren vertraut , so dass dies in Ordnung wäre.

Teil zwei meiner Frage ist mehr Java-bezogen. Wenn ich RSA / ECB / NoPadding wie oben verwende, glaube ich, dass ich in der Lage bin, ein Quellbytearray von (sagen wir) der Länge 128 (für ein 1024-Bit-RSA-Schlüsselpaar) bereitzustellen und dieses zu verschlüsseln um ein weiteres Byte-Array der Länge 128 zu erhalten. Wenn ich dann versuche, das erneut zu verschlüsseln, mit einem anderen öffentlichen Schlüssel mit 1024 Länge, bekomme ich

  

javax.crypto.BadPaddingException: Die Nachricht ist größer als der Modul

Weiß jemand warum?

EDIT - Verschlüsselung mit NoPadding erzeugt nicht immer diese Ausnahme - es ist temperamentvoll. Auch wenn die Verschlüsselung diese Ausnahme nicht generiert, generiert die Entschlüsselung Folgendes:

  

javax.crypto.BadPaddingException: Daten müssen mit Null beginnen

Vielen Dank für das Lesen! Jede Hilfe würde sehr geschätzt werden.

BEARBEITEN - Entschuldigung, meine ursprüngliche Frage war nicht sehr klar, was ich machen möchte, also hier ist ein [Versuch einer] Erklärung:

• Der Klartext ist die Stimme eines Wählers bei einer Wahl.
• Pret-a-voter zielt darauf ab, end-to-end überprüfbar zu sein, ohne die Wählergeheimnisse (usw.) zu opfern. Nach der Abstimmung erhält der Wähler eine Quittung, mit der er überprüfen kann, ob seine Stimme korrekt aufgezeichnet wurde und welche später zeigt, dass seine Stimme nicht manipuliert wurde. Der Wähler vergleicht die Informationen auf seinem Empfang mit einer identischen Kopie im Internet.
Allerdings sollte es keinem Wähler möglich sein zu beweisen, wie er / sie gewählt hat (da dies zu Zwang führen könnte), also ist die Information nicht der Klartext, sondern eine verschlüsselte Kopie der Abstimmung.
• Tatsächlich ist der Klartext viermal verschlüsselt, mit vier verschiedenen asymmetrischen Schlüsseln - gehalten von zwei verschiedenen Kassierern, von denen jeder zwei Schlüssel hält. So wird einem Erzähler eine Stimme (Klartext) zur Verfügung gestellt, die ihn unter Verwendung des öffentlichen Schlüssels # 1 verschlüsselt und dann diesen Geheimtext mit seinem zweiten öffentlichen Schlüssel verschlüsselt und den Chiffretext dem zweiten Erzähler gibt, der ihn mit seinen zwei Schlüsseln in demselben verschlüsselt Weg. Der resultierende Chiffretext (Ergebnis von vier sequenziellen Verschlüsselungen) wird im Web veröffentlicht (publiziert). Die Kassierer sind vertrauenswürdig.
• Jede verschlüsselte Stimme kann als "Zwiebel" dargestellt werden, wobei das Zentrum die Stimme ist und mehrere Ebenen der Verschlüsselung vorhanden sind. Um zur Abstimmung zu gelangen, muss jede Schicht der Reihe nach entfernt werden, dh die entsprechenden privaten Schlüssel (die von den Wählern gehalten werden) müssen in umgekehrter Reihenfolge angewendet werden. Dies ist der Schlüssel zur Sicherheit - alle Kassierer müssen zusammenarbeiten, um die Stimmen zu entschlüsseln.
• Das Web Bulletin Board kann als eine Tabelle mit 5 Spalten visualisiert werden - die erste (auf der linken Seite) enthält die vollständig verschlüsselten Abstimmungen (wird auch auf dem Empfang jedes Wählers angezeigt) und ist die einzige sichtbare Spalte während der Stimmabgabe Bühne.Die zweite Spalte enthält den gleichen Satz von Stimmen, aber mit der äußeren Schicht entfernt - Teller 2 füllt diese Spalte und Spalte 3 durch Entschlüsseln der Stimmen mit seinen privaten Schlüsseln während der Tally-Phase. Am Ende der Zählphase enthält Spalte 5 die vollständig entschlüsselten Stimmen, die dann gezählt werden können.
• Jeder Wähler erhält eine Quittung, die ihn mit einer verschlüsselten Stimme in Spalte 1 verbindet. Dies zeigt nicht, wie er abgestimmt hat, sondern erlaubt ihm zu überprüfen, dass seine Stimme nicht manipuliert wurde, da sie dies während des Wahlprozesses überprüfen können Ihre verschlüsselte Stimme ist immer noch in Spalte 1, unberührt. Dies ist natürlich nur die Hälfte der "Ende-zu-Ende-Verifizierung", da die Wähler nicht verifizieren können, dass die Entschlüsselungen korrekt durchgeführt wurden, dh dass es in Spalte 2 einen Eintrag gibt, der ihre Stimme abzüglich der äußeren Verschlüsselungsschicht darstellt . Jeder Wähler ist nur für die Überprüfung bis zu dem Punkt der Spalte 1 verantwortlich.
• Danach ist es Aufgabe des Auditors, zu überprüfen, ob die Einträge in Spalte 1 in Spalte 2 entschlüsselt werden und so weiter. Die Art und Weise, wie sie dies tun, beruht auf der deterministischen Verschlüsselung und den öffentlichen Schlüsseln, die für die Verschlüsselung verwendet werden, öffentlich.
• Da öffentliche Schlüssel öffentlich sind, möchten Sie nicht, dass Personen einfach Zeilen aus Spalte 5 in Spalte 1 zeichnen und die Stimme von jemandem zusammenführen, wenn sie wiederholt verschlüsselt wird. Auf diese Weise knüpft eine Quittung, die Sie mit einer verschlüsselten Stimme verbindet Sie zu einer unverschlüsselten, lesbaren Stimme - & gt; Zwang! Daher sind nur die Spalten 1, 3 und 5 öffentlich (deshalb führt jeder Kassierer ZWEI Verschlüsselungen durch), und für jeden Eintrag in Spalte 3 wird nur einer der entsprechenden Einträge in {2,4} für die Prüfer offengelegt. Dies verhindert, dass jemand (auch Auditoren) eine verschlüsselte Abstimmung mit einer unverschlüsselten Abstimmung verknüpfen kann.
• Die Revisoren müssen daher einen Eintrag in Spalte 3 vornehmen, den entsprechenden Eintrag in Spalte 2 und den öffentlichen Schlüssel erhalten und die gleiche Verschlüsselung durchführen, um sicherzustellen, dass sie tatsächlich den Eintrag in Spalte 2 erhalten.
• Zusammengefasst bietet das eine End-to-End-Überprüfbarkeit.

Entschuldigung, das war so lang - ich hoffe, es beschreibt mein Bedürfnis nach deterministischen Verschlüsselungen. Ich habe viele grundlegende Details verpasst (ich habe dieses Schema stark modifiziert), aber hoffentlich sind die Kernprinzipien alle da. Vielen Dank für das Lesen - ich schätze es wirklich.