diff options
Diffstat (limited to 'archive/2021-08-10--rump-session-at-pets')
| -rw-r--r-- | archive/2021-08-10--rump-session-at-pets | 70 |
1 files changed, 70 insertions, 0 deletions
diff --git a/archive/2021-08-10--rump-session-at-pets b/archive/2021-08-10--rump-session-at-pets new file mode 100644 index 0000000..393189a --- /dev/null +++ b/archive/2021-08-10--rump-session-at-pets @@ -0,0 +1,70 @@ +Hello + * Rasmus Dahlberg (rgdd) + * Affiliations + * Karlstad University (PhD student) + * Mullvad VPN (software engineer) + +Purpose of this mini talk - make people aware of sigsum logging + * Work-in-progress, still early days + * Plenty of opportunity to: + * get involved + * design + * code + * apply pattern of transparent logging (pick a use-case) + * operate experimental logs and/or witnesses + * etc. + * shape the project as we move forward + * aim: free and open source + +The basics + * Sigsum, short for "signed checksum" + * Sigsum logging is about adding signed checksums into a transparent log + * Think of this as Certificate Transparency, but: + * s/Certificate/checksum + * checksum is the output of a cryptographic hash function + +Backdrop and motivation + * You can already achieve transparency for cryptographic checksums by piggy-backing on Certificate Transparency + * Encode hash into a certificate + * Mozilla proposed a form of Binary Transparency this way a while back + * https://wiki.mozilla.org/Security/Binary_Transparency + * But could really be <anything> transparency because <anything> is hashed + * With sigsum logging you can do this without the runaround of: + * first encoding that hash with ASN.1 (as a certificate) + * then doing a ping-poing with a certificate authority + * and learning about ecosystem specific constructs like + * promises of public logging, "SCTs" + * eventually you will realize that you are kind of on your own in terms of gossip-audit models + * so what you are left with is a weirdly encoded hash and a log that you trust blindly + * We try to bring transparency to signed checksums in a more sensible way + +It is fair to say that we place a large emphasis on minimalism + * Keep it simple + +But at the same time, important features shouldn't be left out + * E.g., we want features that make log operations less costly and less scary + * anti-spam + * anti-poison + * sharding (helps with log life cycles) + * We also want features - or maybe I should say considerations - that facilitate adoption of transparent logging patterns + * if your users already download data from a repository or a website, and you want to bring transparency to that data + * great, that is the only communication pattern we assume for end-users + * "preserved data flows" + * few and simple (de)serialization parsers + * no cryptographic agility (simplifies protocol, tooling, etc.) + * built-in mechanism to ensure a globally consistent log + * simpified version of witness cosigning + * log is not a party that you trust blindly + +Current status + * We have a proof of concept up and running (log + witness) + * Tooling is basically non-existing + * format data with printf, pipe into curl :) + * If you have a use-case for transparent logging, or if you want to learn more, or if this sounds like fun and you would like to get involved: + * irc: #sigsum @ oftc (the conversation happens here) + * talk to me here on gather + * our repos are currently on github, contains code and some documentation + * github.com/sigsum + * www.sigsum.org + +(I will also post link to a non-persistent pad with this mini-talk in the chat.) |