Umfrage/Architekturfrage zur DEC

[rabatscher]

Zitat von TurboMagic:

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)...

Würde dann dasselbe für EncodeBytes/DecodeBytes gelten? Done müsste eventuell noch die
letzten noch zwischegespeicherten Daten zurück liefern....

Ich bin nicht unbedingt ein Fan von super algemeinen Methoden, die niemand benutzt und oft
die Sache nur verkompliziert und fehleranfällig macht...
Gibt es ein RFC dass GCM nicht in Verbindung mit AES enthält?
Selbes gilt für Poly1305 - Es wird praktisch nicht mit AES verwendet!
https://crypto.stackexchange.com/que...is-it-obsolete