I did analyse the security of Tarsnap as I was writing it, for what it's worth.

Why does TLS make you twitch? Does that apply to TLS 1.3?

[1]: https://loup-vaillant.fr/articles/rolling-your-own-crypto

But frankly I trust my ability -- both now and in 2007 -- to use standard cryptographic algorithms to build a new protocol far more than I trust my ability to remove all the crap from TLS 1.1.

(Did you deliberately not mention heartbleed?)

The threshold question is, "could this vulnerability be reasonably expected to recur in independent implementations of the protocol?"

As for stripping back TLS 1.1 --- it wouldn't take much more than simply picking a single ciphersuite and requiring TLS 1.1. You wouldn't need to know, for instance, about export ciphers.

I get why you didn't use OpenSSL. The normal thing for someone like you to do in 2022 would be to use Noise.

Quick search shows WireGuard protocol, but I am not sure if how much of the WireGuard protocol is the same as the Noise Protocol.

https://www.wireguard.com/formal-verification/ https://www.wireguard.com/papers/wireguard-formal-verificati...

  The WireGuard protocol is extensively detailed in [2], which itself is based on the NoiseIK [3] handshake.

https://duo.com/labs/tech-notes/noise-protocol-framework-int...

  Noise is used today in several high-profile projects:
    WhatsApp uses the "Noise Pipes" construction from the specification to perform encryption of client-server communications
    WireGuard, a modern VPN, uses the Noise IK pattern to establish encrypted channels between clients
    Slack's Nebula project, an overlay networking tool, uses Noise
    The Lightning Network uses Noise
    I2P uses Noise

I worry this then just means government actors only will need to find 1 vulnerability to have open access to a standardized web and those vulnerabilities will exist, nothing is perfect. I genuinely believe a non-standardized approach is more effective even if they are each more vulnerable individually.

Android presents a decent corollary here vs iOS. Finding an iOS device exploit may cost more money but you get access to such a massive amount of devices it is worth it.

For instance, the weird authentication scheme that gives rise to the RSA key recovery attack --- that problem is what PAKEs are for.

That is my point exactly, it should be how they think about it. Attacks to the cryptography math itself are only a single vector, the software implementation of it is going to have holes not to mention those beyond it from the hardware at the chip level to the firmware that runs it there are vulnerabilities well outside the math itself.

In addition a lot of security when things are fragmented tends to become "security through obscurity". Something that is a small player in a market can still have all sorts of issues that a state-funded actor can find via analysis and exploit. It's also much less likely to have a public actor find and disclose the issue due to the small install base.

They make it look like its designed as a core part of the product on the website, while in reality its an after thought and its behind on updates too.

As good as Nextcloud sometimes is, a parts of it feel very legacy and unmaintained.

For whatever it's worth, we had an external analysis of the protocol done recently at EteSync. Though even before it, we (intentionally) only used known and common primitives (from libsodium) to ensure that we have a solid base from both the cryptographic schemes, and the actual implementations.