Ich sehe wenig Sinn darin, die Flexibilität zu beschränken, wenn es auch anders geht.
Ja, GCM wird hautsächlich auf AES angewendet. Das kann man ja so dokumentieren. Aber
wenn ein neuer Standard mal kommt der auch 128 Bit Blöcke nuntzt und GCM für den auch
einigermaßen üblich ist müsste man ja wieder ran.
Lieber die Zeit dafür nutzen und die problematische Umsetzung für Streams ändern.
Das muss man so wie es aussieht für die vor kurzem eingeführten Paddings wie Pkcs#7
sowieso auch tun. Und dann vermutlich zuerst für diese und danach für GCM, oder arbeitet
das auf den ungepaddeten Daten?
Mir schwebt eine überladene Done Variante mit Parametern vor (vermutlich der Input und
der Output Stream). Wenn man will kann man kann man nih ein Flag einbauen, welches beim
Aufruf von Encode/DecodeStream auf True gesetzt werden und würde, wenn das gesetzt ist,
im normalen Done eine
Exception werfen. Damit würde man die Entwickler sicher erziehen
(bis auf die, die ihren Code nicht testen)...
* Ich denke multiple Calls zu EncodeBytes / EncodeStream sollten evt. doch zugelassen werden -
alle anderen Cipher, die ja nicht voneinander abhängig sind funktionieren ja so auch...
Es bräuchte hier nur etwas mehr "housekeeping" (status, counter, schon initialiert usw.) gemacht.
Ein Call von "Done" würde dann natürlich das Ganze abschließen und das Finale Tag berechnen....
I am not sure about that,
See stream functionality does need signal to end as it can and most likely used as chunk or repeated calls, "Done" will signal the sealing of the GCM tag calculation by multiply the last chained result with the first block (the one with counter=0), but enforcing requirement will break the one hit EncodeBytes/DecodeBytes, i saw these being used in many places in one line of code, enforcing "Done" with them is wrong, yet i support the functionality itself, but it must be different, may be different pair of functions, like EncodeChunk that accept TBytes or ...
But in general moving GCM into own class is not bad idea, just costly in implementation, and will make the code cleaner as one line operation like EncodeBytes can use that GCM and call done internally, yet it might be not small refactor.[/QUOTE]
GCM ist bereits eine separate Klasse und
Unit, weil das komplizierter/aufwändiger als die anderen
Blockmodi ist. Das wird dann halt in DECCipherModes aufgerufen.
Wie oben geschrieben: meine aktuelle Idee ist es, das Ende der Streamoperation per überladener Done Methode zu signalisieren.