C2SP VS sigsum

Age is a modern, respected crypto solution: https://github.com/C2SP/C2SP/blob/main/age.md

Argon2 is the best choice, but scrypt may be more easily available: https://github.com/C2SP/C2SP/issues/10

Hi! I read and appreciated your issues and discussions, sorry I didn't get to respond to them yet, but I've been thinking about it.

Although I don't disagree that parsing text is hard, I also think that parsing variable-size binary formats is hard (and there is a tall, tall pile of bugs to confirm that). Really, parsing is hard. Rather than count on one design or the other to be bug-proof, I worked on a large test suite to help implementations catch their parsing bugs. [https://c2sp.org/CCTV/age] I think it would have found one of the issues you reported if that implementation had integrated it, and I am going to add vectors for various resource exhaustion scenarios which I hope would have found the other. (I am not going to look at what it is exactly, so I will know if I made the suite comprehensive enough without being too specific about this bug.)

I also liked your observation that it would have been nice if the header was streamable. [https://github.com/C2SP/C2SP/issues/28] It went on the pile labeled "regrets / for v2 when it comes", thank you.

I think it's ironic that you imply a "dozen of immature crypto libraries" are used in the Age spec. It's quite the opposite and the Age spec provides a reduction in so-called "yolo crypto" versus the OpenPGP spec. See: https://github.com/C2SP/C2SP/blob/main/age.md and also give https://latacora.micro.blog/2019/07/16/the-pgp-problem.html# for a pretty accurate overview of what's wrong with OpenPGP.

… okay, then look at the spec, which is beautifully simple: https://github.com/C2SP/C2SP/blob/main/age.md#the-scrypt-rec...

I had the same question. I believe it refers to “Actually Good Encryption” (https://github.com/C2SP/C2SP/blob/main/age.md).

Exactly! It's a growing ecosystem including things like https://transparency.dev, the Go Checksum Database, https://www.sigsum.org, SigStore, and even key transparency solutions like WhatsApp's.

One thing you end up needing to deploy tlogs is a way to reassure clients the tree is not forked, and for that you mostly need witness cosigning, where a quorum of third parties attest that a signed tree head is consistent with all the other ones they've seen. I've worked with the Sigsum project and the Google TrustFabric team on an interoperable specification for witnessing (which Sunlight interoperates with), and I am now working to develop a public, reliable ecosystem of witnesses.

Once you have witnessing, running a log can be as easy as hosting a few files in a GitHub repo or S3 bucket, updated with a batch script. I am very excited to make it possible for any project to get better-than-CT accountability for ~free.

(You might want to catch my RWC 2024 talk about this once it comes out!)

> one of the ways you can evaluate companies is to recognize when they're making sketchy, not-relevant claims to create an air of legitimacy.

This is an excellent heuristic. Personally I like to evaluate trustworthiness in terms of integrity and competence - can I trust their values and can I trust that they know what they are doing? Words are cheap of course. Consistent action across several years is much harder to fake. It also overlaps with another heuristic I use to model and predict the behaviour of a company; a company's behaviour will converge on the shareholders' goals over time.

> This "our servers have no disks" thing is kind of thing is marketing.

You are correct that we considered that aspect while writing the blog post, but please read the content before passing judgement. See the section titled "To recap about “no disks in use”" in particular.

On the topic of "air of legitimacy" I'll just leave these here:

* Our apps have been open-source since we launched in 2009

* Our response to Shellshock: https://news.ycombinator.com/item?id=8385332

* Our thoughts on WireGuard in 2017: https://mullvad.net/en/blog/2017/9/27/wireguard-future/

* Experimental post-quantum KEM support in 2017: https://mullvad.net/en/blog/2017/12/8/introducing-post-quant...

The blog post you commented on also talks extensively about how it was one of our first steps in making our infrastructure transparent. Here are just two things we've done as part of that project:

* "This is the first time a modern off-the-shelf server platform gains coreboot support, and it is an integral part of realizing our vision of transparent and independently auditable VPN servers." - https://mullvad.net/en/blog/2019/8/7/open-source-firmware-fu...

And finally, we've spent 2-3 years designing a transparency log with distributed trust assumptions. One of many critical parts necessary to achieve our vision of transparent server infrastructure. I'll wager that there's no transparency log with a stronger threat model than ours. https://www.sigsum.org

We're certainly not without fault, but hopefully this helps inform your opinion of Mullvad.

Best regards,