Hallo,

ich habe mal irgendwann den GCM Blockverkettungsalgorithmus zur DEC hinzugefügt.
Dieser Authentifiziert ja zusätzlich und so wie er eingebaut ist darf er auch
benutzt werden, ohne das ein Schlüssel spezifiziert wird.

Nun kommt voraussichtlich bald ein weiterer Algorithmus dieses Typs hinzu und
ich frage mich, ob das automatisch auch für den so gehandhabt werden sollte?

Beide Algorithmen haben jeweils eine Init Methode und keinen Constructor
und diese Init bekommt nur den Initialisierungsvektor übergeben, aber nicht
den Key.

Macht sowas Sinn für Fälle wo nur authentifiziert, nicht aber auch
verschlüsselt/entschlüsselt werden soll?

Well, this is uncharted region, and i am not fan of this creating stuff and algorithm that provide nothing special, these will not bring anything useful to the table, only confuse the users and let them use it wrongly.

To put my thoughts in useful phrases:
1) Yes, OK, GCM can be used as standalone hash, a hash, general one, as it will lose its main feature the authentication that built on top of using the key, still if you use the IV as key then GCM (or Poly1305) can be used as stand alone keyed-hash, yet keyed hash require a key that named key, while the suggested use will use (and depend on the optional) IV initialization vector as key, IV as it is known and always used is a non secret value, i think you see the dilemma here !?, this is source for confusion opens the door for wrong doing form non expert users.

2) No, Shouldn't be used like that, as no other library or standard suggest it like that, using it as suggested or proposed does violate NIST and every other RFC contains it, (you can't find one test vector where key do not exist, there is none), let me be clear here, test vector with zeroed key is still a key, and there is no test vector with zero key (or no key).

from the above i say do not let it be used as standalone.

extra reading about this subject:
https://crypto.stackexchange.com/que...-keyed-hashing here salt is by definition a value that can be used once and dropped, unlike IV than be and must be reserved in public form (not secret)
https://stackoverflow.com/questions/...non-keyed-hash
https://crypto.stackexchange.com/que...tographic-hash here the answer showing that stand alone GCM is not considered as secure hash, and the reason for this insecurity is the reuse of the key which will be zeroed and ... well again the security will/might come form the IV alone, bring us again to should be used with IV?!, the name itself should be deterrent to such use

But if there was a salt in the mix, well, i will same the same, still not brining anything good or useful.

Thanks for this valuable input!

I'll keep it as is (not yet published but soon):

1. Allow GCM to be used without key but I'll add a warning notice into the documentation
that this is not recommended.

2. Do not allow CCM to be used without key.

Will work, but if you are going to warn about wrong doing/using then make sure to put the warning about using the same key.

Same key only can be reused in different operations if and only if IV is different, that goes for GCM and CCM, (well it goes for anything to do with AES or any block cipher for that matter).
In other words: if no IV is used, then key must be different and not used more than once, if the key is same then IV must be different each time.