Rasmus Dahlberg <rasmus.dahlberg(a)glasklarteknik.se> writes:
>> I see one problem with this, though. The monitor can't simply use the
>> ssh-keygen command to verify the signature, since that command expects
>> to get the *message* as input, not the hash thereof. Which kind-of
>> defeats the idea of piggybacking on ssh tools.
>
> I disagree. The value of piggy-backing on SSH tooling is for the signer
> who can access their private key with good solutions that already exist.
I don't have a very strong opinion, maybe it's "only" a matter of
documentation. If we say "sigsum uses the ssh signature format", I would
expect that to mean that we use it as a black box with inputs and output
according to the spec, but that's not quite what we do.
We could say that we have
checksum = H(message)
and that the essence of the signature is to sign checksum, so that
signature can be verified given only the public key and checksum (i.e.,
without knowing message). And that we do signatures in a way that
produces an identical signature as if feeding message as the input of
ssh-keygen -Y sign --hashalg=sha256, or M = message in its spec.
>> message=SHA3(data) ; application layer
>
> Note that message must be exactly 32 bytes in Sigsum. So, you wouldn't
> be able to use SHA3 here
Side note: SHA3_256 is part of the SHA3 standard.
> I see your point if it is a desired property to verify leaf signatures
> in isolation with ssh-keygen. Would you say that the complexity is
> decreased, about the same, or increased if this change was proposed?
I think conceptual complexity would be decreased slightly, by which I
mean roughly that it will be slightly easier to document and explain.
For implementation complexity, not much difference (assuming that the
only value we see in actually using the ssh-keygen tool for handling
signatures is for the private key operations).
Regards,
/Niels
