blob: 9bca070b2f54cf7cf7cc3eba747ed94203a22df9 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
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.
|
