From c6bd9b06dd40d98da265e35fb5542f57b5f9e76f Mon Sep 17 00:00:00 2001 From: Rasmus Dahlberg Date: Tue, 29 Mar 2022 22:48:44 +0200 Subject: persist pads from meeting minutes --- archive/2022-03-29-no-arbitrary-bytes-notes | 39 +++++++++++++++++++++++++++++ 1 file changed, 39 insertions(+) create mode 100644 archive/2022-03-29-no-arbitrary-bytes-notes (limited to 'archive') diff --git a/archive/2022-03-29-no-arbitrary-bytes-notes b/archive/2022-03-29-no-arbitrary-bytes-notes new file mode 100644 index 0000000..9bca070 --- /dev/null +++ b/archive/2022-03-29-no-arbitrary-bytes-notes @@ -0,0 +1,39 @@ +# Background + +Our implementation of SSHSIG and the remove arbitrary bytes proposal recommends +a "double hash" of the data. + + message = H(data) + blob = SSHSIG{ + ... + H(message) + } + +Logs are strict to enforce that len(message) = sha256.HashSize. This means that +the message could be 32 arbitrary bytes, but the resulting checksum is a hash. + +# Misc notes from discussion + +From sigsum-tools-go, test/ssh.sh: + + openssl dgst -binary $msg-$i | ssh-keygen \ + -Y sign \ + -O hashalg=sha256 \ + -f $priv \ + -n $(./sigsum namespace) > $msg-$i.sig + +Could potentially s/openssl/sigsum + +The pipe into ssh-keygen is potentially a UX burden. + - How proportional is this trade-off compared to the log eating 32 arbitrary bytes? + - I.e., an option would be to let the submitter send H(message) as before, in which case the log does not know if it is a hash or something else of the same byte-size. + +Manual verification is not in-scope for UX. Manual verification is not done. In the few cases that it is done without sigsum tooling, a pipe will not be the hard part. + +UX here is mainly important for "deploy" and "debugging". + +The sigsum tool should be as convenient as possible, and we should also list what relevant helpers does (in case you are in an environment without the sigsum tool). + +# Conclusion + +No planned changes right now. Continue to improve tooling and documentation. -- cgit v1.2.3