Meine Insights bezüglich des Bugreports hast du ja schon
I really lost in the conversation on Github and went right away to put a test based on doubted code behavior, right after downloading your test project the one attached as text file.
Ich wollte hier nur noch kurz ein paar Anmerkungen machen:
* GCM ist soweit ich weiss ja nur für 128 bit Ciphers möglich
-> es wäre eventuell eine Idee GCM nur in spezialisierten Klassen zu verwenden
-> wäre rauslösen aus den TDECCipherModes eine Option, die GMC Variable ist dort eigentlich nur
für die AES Implemtierung (oder liege ich da falsch?) ?
I don't think it worth it, it will work though, AES is de facto standard, not
a standard but
THE standard, and GCM defined for it, so no point to recommend to use AEAD other than the most proven and compatible schemes, which are AES with GCM and ChaCha20 with Poly1305.
Though GCM is in need for 128bit block and has nothing to do with key size.
* Ich bastle gerad am ChaCha20 Poly1305 Encoding scheme - auch dieses Schema ist nur für
256 bit ciphers gedacht (es würde also auch eine Option für AES 256 geben) aber sonst
für keine anderen Cipher. Da die Poly1305 und ChaCha teilweise miteinander verwoben sind
wäre es evt. auch hier sinnvoll eine extra Klasse zu coden...
Nice, i also have those, yet again mixing between these standards is not a recommended thing, see ChaCha20 is stream cipher by design and it don't define any padding scheme on its own the operation happen on the last row in the state and it is faster than AES when there is no hardware acceleration, yet adding Poly1305 to AES make little sense as if AES is fast with CPU acceleration then most likely the GHASH (GCM) is also accelerated by the CPU with carry-less multiplication, but the real reason why it should not be done is, it will make compatibility with any other library almost non existed, so the data encrypted using different pair will need custom library to
handle data from/to other languages or platforms.
* 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.