Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tamper-Evident Logs

transparency.dev

Post reply on HN
Print view View original

21–30 of 51 posts

Re: Tamper-Evident Logs

#21

Post by geofft »

skybrian wrote: post #12

This isn't obviously anything new. From the github repo, it looks like Google open-sourced the underlying implementation for certificate transparency a while back. [1] Any DNS registry will need something similar to this to participate. While in theory, anyone publishing public information might find something like this useful, it's not clear there's much demand for it outside DNS. Something like Dolt [2] seems like…

I'm seeing this as an alternative to blockchain hype for cases where there isn't a double-spend problem (which is most of the non-public-access-currency use cases people are excited about) or where you can't assume that the network controls more computational power than any attacker (which is basically all of them). Just about any "permissioned blockchain" use case is better off using this.

Basically, they're pitching using the underlying proven tech from Certificate Transparency (and Go modules) for other similar use cases. To that end, this shouldn't be anything new, beyond documentation / marketing: they want to say this is stable technology.

Re: Tamper-Evident Logs

#22

Post by deathanatos »

throw0101a wrote: post #4

RFC 5848, "Signed Syslog Messages": > This document describes a mechanism to add origin authentication, message integrity, replay resistance, message sequencing, and detection of missing messages to the transmitted syslog messages. This specification is intended to be used in conjunction with the work defined in RFC 5424, "The Syslog Protocol". * https://tools.ietf.org/html/rfc5848

Every time I've seen syslog in the wild, it's been the old "BSD" version (RFC 3164), not the newer RFC 5424 version. And pretty much any newer format, even something basic like JSON-lines over TCP, is going to be nicer to work with, IMO.

(Though I admit, I have no idea how I'd even begin to start signing messages with JSON-lines.)

Re: Tamper-Evident Logs

#23

Post by MertsA »

tleb_ wrote: post #10
cocktailpeanuts wrote: post #8

Maybe I'm missing something, but there is already the term "append only logs" which we use everywhere. How is this different from append only logs? Append only logs rely on cryptography to make the history transparent too. I skimmed through the website but couldn't find a distinction. Also, the website format is kinda weird. As I reach the bottom of the page, it looks like this is a promotional site for Trillian. May…

What cryptography are you referring to when talking about append-only logs? To me, an AOL is just a list of records that has a single operation, append. It could be implemented as a file that is only opened in append mode, multiple files (eg logrotate), a lib that works in memory, a process that exposes an API, etc. I don't see any cryptography here.

In general, yes, an append only log might be weakly "append only". If you want a cryptographic approach look at how forward secure sealing works with systemd. Basically you make a cryptographic ratchet on the system doing the logging such that given some arbitrary key you can find out what the next key is but not the previous one. You generate a verification key that you take off of the system in question at the start and the verification key can be used to efficiently check any part of that series. During operation you sign the log segment you just wrote out on some regular interval and then ratchet the key forward and delete the old key in memory to where even if the system was completely compromised it no longer holds a key that could rewrite the previous log segment.

Re: Tamper-Evident Logs

#24

Post by hardwaresofton »

If anyone wants to see how someone built this in production without any of the "we're building a movement, we have a fancy landing page" hype:

Secure logging with syslog-ng Forward integrity and confidentiality of system logs @ FOSDEM 2020[0].

I'm starting to become really suspicious of things being pushed as standards/new approaches/things-that-should-be-rfcs-but-have-a-marketing-budget. As other posts have pointed out, an RFC for this already exists, and all I can see is Google trying to make another gRPC where new engineers hear the term "gRPC" before they hear and/or take the time to understand HTTP/2.

[0]: https://www.youtube.com/watch?v=8uN4s_m7sno

Re: Tamper-Evident Logs

#25

Post by krrrh »

I’ve said it for years, but straightforward approaches to signing logs and database dumps takes care of most problems blockchains are supposed to solve.

Re: Tamper-Evident Logs

#26

Post by peteretep »

deathanatos wrote: post #22
throw0101a wrote: post #4

RFC 5848, "Signed Syslog Messages": > This document describes a mechanism to add origin authentication, message integrity, replay resistance, message sequencing, and detection of missing messages to the transmitted syslog messages. This specification is intended to be used in conjunction with the work defined in RFC 5424, "The Syslog Protocol". * https://tools.ietf.org/html/rfc5848

Every time I've seen syslog in the wild, it's been the old "BSD" version (RFC 3164), not the newer RFC 5424 version. And pretty much any newer format, even something basic like JSON-lines over TCP, is going to be nicer to work with, IMO. (Though I admit, I have no idea how I'd even begin to start signing messages with JSON-lines.)

Got to believe most JSON parsers can be set to permissive mode to allow comments, and then you could just append `//signature` on to the end of each JSON line?

Re: Tamper-Evident Logs

#27

Post by nexthash »

A cursory skim of the comments reveals that the problem being pushed by Google here seems to already have many existing solutions being discussed for adoption as a possible comprehensive standard. Out of curiosity, can somebody explain to me why Google would feel the need to push its own standard and throw up a sleek website/showcase instead of contributing to what is already out there?

Re: Tamper-Evident Logs

#28

Post by drdeca »

tleb_ wrote: post #10
cocktailpeanuts wrote: post #8

Maybe I'm missing something, but there is already the term "append only logs" which we use everywhere. How is this different from append only logs? Append only logs rely on cryptography to make the history transparent too. I skimmed through the website but couldn't find a distinction. Also, the website format is kinda weird. As I reach the bottom of the page, it looks like this is a promotional site for Trillian. May…

What cryptography are you referring to when talking about append-only logs? To me, an AOL is just a list of records that has a single operation, append. It could be implemented as a file that is only opened in append mode, multiple files (eg logrotate), a lib that works in memory, a process that exposes an API, etc. I don't see any cryptography here.

There is something called an authenticated append only skip list, which I think is kinda neat. It is basically what it sounds like. Iirc it allows certificates showing that something has a particular place in the list, given the assumption of the latest thing added to it, in length at most logarithmic in the length of the list.

Re: Tamper-Evident Logs

#29

Post by hackmiester »

nexthash wrote: post #27

A cursory skim of the comments reveals that the problem being pushed by Google here seems to already have many existing solutions being discussed for adoption as a possible comprehensive standard. Out of curiosity, can somebody explain to me why Google would feel the need to push its own standard and throw up a sleek website/showcase instead of contributing to what is already out there?

My best guess would be NIH. I try not to be pessimistic about Google but that's the best I've got.

Re: Tamper-Evident Logs

#30

Post by kevin_nisbet »

philips wrote: post #2

We built a tamper evident log system for https content. The beta is over here: https://www.transparencylog.com/ Or try out the CLI tool https://github.com/transparencylog/tl#installation

I've scanned through the work you've been doing on this a couple times, going back to trying to use letsencrypt / existing transparency logs. While its great stuff and really interesting, I wanted to point out the last time I looked at the current iteration I really struggled trying to understand how it worked, and as such how the security properties worked.

Not meant to be criticism, just feedback, as it would be ideal to have some sort of transparency mechanism in common use.

Post reply on HN