- Thread Starter Thread Starter
- #41
Ich hatte auch nichts davon gelesen, dass es ein Vielfaches sein muss, allerdings hat es damit dann auch geklappt - bei verschiedenen Textlängen und so weiter.Dein Problem liegt nicht am Padding. GCM ist ein "Streaming Mode", d.h. die Länge von Input und Output muss kein Vielfaches der Blocklänge sein.
Stimmt, daran hätte ich denken können, als ich angefangen habe, diverse Dinge mit try-with-resource zu lösen.Dein Problem liegt offenbar in der Länge des Ausgabe-Arrays. Das könnte man dadurch lösen, dass man auch beim Decoden wieder in einen ByteArrayOutputStream schreibt - dann musst du dich vorher nicht auf eine Länge festlegen.
Problem 2 (das mit dem fehlenden letzten Block) liegt daran, dass der CipherStream die Daten immer blockweise verarbeitet - der letzte, halbe Block wird also erst entschlüsselt, wenn der Stream zu Ende ist (geschlossen wird).
Ich habe nun deinen Code mehr oder minder verwendet. Scheint soweit zu klappen.
Stimmt, das wäre möglich, wenn man das letzte Byte verändert. Allerdings würde das maximal 8 Zeichen vom entschlüsselten String abschneiden und die Sicherheit in diesem Fall nicht beeinträchtigen. Allerdings habe ich nicht dran gedacht, dass Padden explizit zu Crypto-Konstukten gehört. Ich habe das nämlich bereits in diversen anderen Contexten nutzen müssen, ohne dass es um Sicherheit in Form von Cryptographie oder ähnlichem ging. In der Universität musste man das beispielsweise für einige mathematische Verfahren verwenden, um eine Lösung zu bekommen.Für Padding gilt wie für alle anderen Crypto-Konstruktionen: Möglichst wenig selber machen! Deine Konstruktion oben hört sich an, als könnte man Text-Bytes "abschneiden", indem man das letzte Byte verändert.