Rasmus Dahlberg rasmus.dahlberg@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
Top-posting! As a summary for others, I spoke to Niels earlier today at Sigsum's weekly meet. We will either make a proposal that captures the below change, or at minimum update our documentation to be more clear.
We will put a pin in this until a few other proposals have been decided.
-Rasmus
On Fri, Sep 30, 2022 at 09:08:35AM +0200, Niels Möller wrote:
Rasmus Dahlberg rasmus.dahlberg@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
Rasmus Dahlberg rgdd@glasklarteknik.se writes:
Top-posting! As a summary for others, I spoke to Niels earlier today at Sigsum's weekly meet. We will either make a proposal that captures the below change, or at minimum update our documentation to be more clear.
To wrap this up, I think current api documentation is now clearer (https://git.glasklar.is/sigsum/project/documentation/-/blob/main/api.md#233-...), and there's no change to the number of levels of hashing.
Regards, /Niels
sigsum-general@lists.sigsum.org
-
Niels Möller -
Rasmus Dahlberg