aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorRasmus Dahlberg <rasmus@mullvad.net>2022-03-29 22:48:44 +0200
committerRasmus Dahlberg <rasmus@mullvad.net>2022-03-29 22:48:44 +0200
commitc6bd9b06dd40d98da265e35fb5542f57b5f9e76f (patch)
tree2d6b815c28dcd0f8882bd192e6b231bae6b7b8bf
parent18d13fa2ecf2f999b55411a9096d182ed325f4ec (diff)
persist pads from meeting minutes
-rw-r--r--archive/2022-03-29-no-arbitrary-bytes-notes39
1 files changed, 39 insertions, 0 deletions
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.