- Sigsum-general - Sigsum mailing lists

First release of the Sigsum log software and ansible roles
by Morten Linderud 31 Mar '23

31 Mar '23

We are happy to announce the first release of the sigsum log server software and Ansible role collection! This means that the project is ready for wider deployment, and that we are committed to provide well-documented upgrade paths when releasing future versions. For background, recall that Sigsum makes signed checksums transparent. This makes it possible to detect malicious and unintended key-usage. The ansible role collection aims to make it easy for organizations to host sigsum logs on their own infrastructure, including setup of mariadb and data replication between a log instance's primary and secondary nodes. The v1.0.0 Ansible release makes use of the following versions: - log-go v0.9.0 - sigsum-go v0.1.23 - Trillian v1.5.1 For more information relating to the log server architecture and how to get started with our ansible collection, see: https://git.glasklar.is/sigsum/admin/ansible https://git.glasklar.is/sigsum/core/log-go/-/blob/main/doc/readme.md We recommend to also take a look at the Sigsum roadmap: https://git.glasklar.is/sigsum/project/documentation/-/blob/main/archive/20… https://git.glasklar.is/groups/sigsum/-/milestones Of note is that the sigsum protocol is still at version 0. While we are not expecting any major changes at this point, an upcoming release will extend the log software with a witness cosigning protocol that is still in-progress. Change logs and the information necessary to perform upgrades will be provided from here on. However, it is not recommended for end-users to fail-close on sigsum logging before protocol version 1. Please report issues and request support on our GitLab issue tracker. We are also available on irc.oftc.net and Matrix in room #sigsum. More informasion can also be found on our webpage: https://www.sigsum.org/ Cheers, The Sigsum team

1 0

Meaning of a single cosignature?
by Niels Möller 17 Mar '23

17 Mar '23

Hi, this is a question that I hope is convered in the literature on transparency logs, but what meaning do we assign to a single, isolated, cosignature? If we have a *sequence* of cosigned tree heads (signed by a particular witness, ordered by increasing tree size), then each cosignature says that all tree leafs in previous cosigned trees are present in later trees. But a sigsum client only sees a single cosigned tree head, not the sequence. In particular, consider the case of the first cosignature of a particular witness, with no history. So what exactly does that signature mean? I suspect there are maybe some underlying assumptions or policys that should be spelled out somewhere. Is this an reasonably accurate description? When I see a leaf node accompanied by a cosigned treehead and an inclusion proof leading up to that head, then I expect that the witness will raise some alarm if, sometime in the future, the log attempts to publish a tree head where the leaf no longer is present? In this case, a single cosignature doesn't make any claim about the state of the log, it just states that the witness has observed this state, and hence that the witness has the information needed to detect future inconsistencies. More concisely: An isolated cosignature (without history) does not make a claim about the state of the log, it makes a claim about the state of the witness. Does that make sense? Regards, /Niels

2 4

Re: We include the checksum in tree_leaf. But what is it used for?
by Niels Möller 17 Nov '22

17 Nov '22

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

2 2

We include the checksum in tree_leaf. But what is it used for?
by Niels Möller 29 Sep '22

29 Sep '22

Let me start with a description of my current understanding of the checksum field, present in the tree_leaf struct in the spec. The submitter submits a message M to the log (M typically a hash of some data not disclosed to the log), together with a public key and signature. The log first verifies the signature, and then adds a leaf to the merkle tree. The signatures are done using ssh format, configured to use sha256. This implies that sign and verify operations on which includes computing SHA256(M), and we call this "checksum" and include it in the tree_leaf struct together with the signature. My first question: Does it matter in any way that the checksum happens to be a value used internally in the ssh signature formatting? If we instead publish a signature of M created using the SHA512 hash internally, as is the ssh-keygen -Y sign default, and publish this signature together with checksum = SHA256(M), wouldn't that work just as well? Next question: Do we really need to publish the checksum at all? It serves as a unique and random-looking identifier for the message M, but who's using this id? We have the following roles: 1. Submitter. Will collect signatures on the submitted leaf. Obviously knows everything needed to query for the leaf hash, and will crete the "sigsum proof package" package to distribute to sigsum verifiers. 2. Sigsum verifier (the party that gets the message M and wants to verify that it is properly logged). The verifier needs to get (by other means than querying the log by itself) all of M itself signature of M inclusion proof for the leaf including this signature witness signatures all related public keys As far as I see, signer will clearly recompute the checksum, in the internals of the signature verification. It could also explicitly compare the checksum it to the value stored in the leaf, but what benefit does that give, if the signature is already verified? On the other hand, it seems essential to verify that the signature and the public key hash in the leaf are as expected. I think this is the core of the question: Is there any reason for the verifier to validate the checksum stored in the leaf, in addition to verifying the signature? If not, what use is that field? 3. Witness. The witness doesn't have access to M, so to a witness the checksum is just random string, there's no way to validate it. It could possibly use it to verify the signature (not by using ssh-keygen though, but by digging into internals if ssh signatures), except that the witness is not expected to have access to the submitter's public key. 4. Monitors. The purpose of a monitor is to query the log and alert whenever an unexpected signature appears. My understanding of monitoring is somewhat fuzzy, but I think the monitor is expected to query for recent tree heads (relying on witness cosignatures to know that what it gets is recent), download all (new) leaves in the tree, and filter on one or more public key hashes of interest. For the leaves found, it will then alert key owner on "unexpected" checksums. However, couldn't one do without the checksums and just as well look at unexpected signatures? The checksum uniquely (except for hash collisions) identifies a single message M. But the signature itself also uniquely identifies a single message M (it seems highly unlikely to have collisions, even if we allow the public key to vary, and in case we insist on having the same public key, any collision represents a break of the security of the signature algorithm). The difference is that the checksum can be (re)computed from M only, while computing the signature also requires the private key. That's sonds like a big dfference, but the only roles above that are expected to know M, are the submitter and the verifier. The submitter by definition knows the private key. And the verifier should be provided with the signature by other means, and just verify it. Regards, /Niels

3 3

Administrivia: Changes to this mailing list
by Linus Nordberg 17 Feb '22

17 Feb '22

Hi, tl;dr If you are sorting email messages from this server based on email headers, you might need to update your filters. This list has been moved from one server to another server. Previous List-Id header was sigsum-general.lists.sigsum.org Current List-Id header carries more cruft but the regular expression sigsum-general.lists.sigsum.org should still match. Previous Subject header was pre-pended with [sigsum-general]. Current Subject header might have changes in casing. Previous server did not DKIM-sign outgoing messages which was problematic since the list manager rewrites parts of the message (like Subject), rendering potential present signatures invalid. Current server does DKIM-sign outgoing messages. Previous list manager did not ever rewrite the From: header, making SPF checks at the recipient's server fail. Current server rewrites From: when needed. Previous list manager had no web interface for managing subscriptions. Current list manager does. Previous list manager accepted email messages to sigsum-general+subscribe@, sigsum-general+unsubscribe@ and sigsum-general+help@. Current list manager accepts messages to other addresses, see the List-* headers of any email received on the list. Enjoy, Linus

1 0

Sigsum project launch
by Rasmus Dahlberg 13 Oct '21

13 Oct '21

Hi everyone, Today we are launching Sigsum, a free and open source software project that revolves around transparency logs and their applications. While most other logging efforts focus on concrete data structures like TLS certificates, sigsum logs are meant to be general building blocks that support signed checksums and minimally required metadata. It is up to the signer to determine what a checksum should represent. For example, Mozilla's take on Binary Transparency [1] fits into the intended use of sigsum logging. By avoiding the Certificate Transparency design, complexity can be reduced. Sigsum logging has no SCTs, complicated ASN.1 parsers, or reactive gossip-audit protocols. Minimalism, distributed trust, and centralized log operations make up our key pillars. These characteristics keep the attack surface small. They also simplify usage, operations, and verification of sigsum logs. To learn more about sigsum logging, please refer to our design and API documentation [2, 3]. There is also a public prototype available [4]. Would you like to be part of the conversation? We have open Jitsi meetings on Tuesdays at 11:00 UTC. Meeting minutes and linked pads are persisted in our archive for transparency and future reference [5]. Asynchronous interactions take place on IRC, Matrix, and email. Website: https://www.sigsum.org/ Source: https://git.sigsum.org/ Pads: https://pad.sigsum.org/ Email: https://lists.sigsum.org/ IRC: #sigsum @ OFTC.net Matrix: #sigsum:matrix.org Jitsi: https://meet.sigsum.org/ About Sigsum --- Sigsum started out as one part of the System Transparency project [6]. Early drafts of the public log element can be traced back to 2019 [7]. More focused design iterations started in October, 2020 [8]. Mature drafts of what is now sigsum logging was presented in Q2 of 2021 [9-11]. Links --- 1: https://wiki.mozilla.org/Security/Binary_Transparency 2: https://git.sigsum.org/sigsum/tree/doc/design.md 3: https://git.sigsum.org/sigsum/tree/doc/api.md 4: https://git.sigsum.org/sigsum-log-go/tree/README.md 5: https://git.sigsum.org/sigsum/tree/archive 6: https://git.sigsum.org/sigsum/tree/doc/history.md 7: https://mullvad.net/blog/2019/6/3/system-transparency-future/ 8: https://github.com/system-transparency/stfe/commit/40250377da81864e9e502b80… 9: https://web.archive.org/web/20210427203606/https://hopin.com/events/padsec 10: https://web.archive.org/web/20210603112144/https://swits.hotell.kau.se/Annu… 11: https://web.archive.org/web/20210923134324/https://swits.hotell.kau.se/Annu…

1 0

First posting to -general
by Linus Nordberg 24 Aug '21

24 Aug '21

Hi, This list has now been set up. Its use is to discuss all aspects of Sigsum. Please note that email messages sent to this list are being archived for anyone on the internet to read.

1 0

2024

2023

2022

2021

Sigsum-general