Discussion:
[Cancel-Lock] Secret zu kurz bzw. Key mit Länge Null (was: ignore test3 canlock)
(zu alt für eine Antwort)
Michael Bäuerle
2018-05-01 19:02:02 UTC
Permalink
Wunderbar, alles bestens. Vielen Dank für Deine Tests.
Interessant ist jetzt vielleicht noch der Sonderfall, wenn der Key Länge
Null hat. Die Hash-Funktion funktioniert auch ohne Input:
|
| $ printf "" | openssl dgst -sha256 -binary | base64
| 47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=

und es könnte daher folgendes auftreten:
|
| $ canlock -c 'sha256:','sha256:47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='
| Good

RFC 8315 verbietet das nicht, d.h. "sha256:" ist ein syntaktisch
korrektes <c-key> Element und canlock weist es deswegen auch nicht ab.

Sowas ist natürlich sinnfrei und ein Fehler des Absenders. Es könnte
aber ggf. durch ein Versehen ausgelöst werden und nicht sofort auffallen
(weil das Lock ja auf den ersten Blick "normal" aussieht).
IMHO macht es Sinn, wenn dein Prüf-Script diesen Sonderfall (Key mit
Länge Null, egal mit welchem <scheme>) abweist.


BTW:
Auch das "canlock" Frontend könnte wenigstens eine Warnung ausgeben,
wenn man versucht ein Secret mit Länge Null zu verwenden um ein Lock
zu erzeugen.



[Xpost und Fup2 nach de.comm.software.newsserver]
Emil Schuster
2018-05-01 19:46:20 UTC
Permalink
Post by Michael Bäuerle
Interessant ist jetzt vielleicht noch der Sonderfall, wenn der Key Länge
|
| $ printf "" | openssl dgst -sha256 -binary | base64
| 47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=
|
| $ canlock -c 'sha256:','sha256:47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='
| Good
RFC 8315 verbietet das nicht, d.h. "sha256:" ist ein syntaktisch
korrektes <c-key> Element und canlock weist es deswegen auch nicht ab.
Sowas ist natürlich sinnfrei und ein Fehler des Absenders. Es könnte
aber ggf. durch ein Versehen ausgelöst werden und nicht sofort auffallen
(weil das Lock ja auf den ersten Blick "normal" aussieht).
IMHO macht es Sinn, wenn dein Prüf-Script diesen Sonderfall (Key mit
Länge Null, egal mit welchem <scheme>) abweist.
Ja, das ist so. In $cancel_key steht die Ausgabe aus dem Parser:

| for my $k(split(/\s+/, $cancel_key))
| {
| unless($k =~ m/^(sha1|sha224|sha256|sha384|sha512):(\S+)/)
| {
| INN::syslog('notice', "Invalid Cancel-Key syntax '$k'. target=$msg");
| next;
| }
[...]

Es muss also mindestens ein Zeichen ungleich whitespace (wie nennt man das?)
folgen, welches dann ja, falls vorhanden, dank Parser auch korrekt ist.

Im weiteren Verlauf der for-Schleife wird der momentane Cancel-Key dann gegen
die Tabelle der Cancel-Locks geprüft. Auch diese Tabelle wird nach der gleichen
Logik aufgebaut.
--
Emil
Michael Bäuerle
2018-05-19 16:08:26 UTC
Permalink
Post by Emil Schuster
Post by Michael Bäuerle
[...]
IMHO macht es Sinn, wenn dein Prüf-Script diesen Sonderfall (Key mit
Länge Null, egal mit welchem <scheme>) abweist.
[...]
Es muss also mindestens ein Zeichen ungleich whitespace (wie nennt man das?)
folgen, welches dann ja, falls vorhanden, dank Parser auch korrekt ist.
Im weiteren Verlauf der for-Schleife wird der momentane Cancel-Key dann gegen
die Tabelle der Cancel-Locks geprüft. Auch diese Tabelle wird nach der gleichen
Logik aufgebaut.
Die Parser haben nun eine Homepage:
<http://micha.freeshell.org/canlock-hp/index.html>

Loading...