Hacker News Reader

Comment by winterdeaf | Hacker News Reader

This speaks volumes about the need of standardized encrypted cloud storage protocols.

It always surprises me how fragmented the entire space is: Syncthing "untrusted devices" support is still experimental, Nextcloud does support encryption, but it's hard to judge how trustworthy it is. Gocryptfs and ecryptfs should be solid, but they are hard to use in a browser or on mobile. Resilio, Borg, Tarsnap, EteSync -- yet more protocols, and without clear security analyses.

Same holds for commercial cloud operators: support for client-side encryption is starting to appear (Google Drive), but without an open, standardized client you still need to trust software from the cloud provider, which mostly defies the point of encrypting in the first place.

View on HN

Resilio, Borg, Tarsnap, EteSync -- yet more protocols, and without clear security analyses.

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

Tarsnap does not actually look bad. But any client-to-server protocol that is not TLS1.3 will make cryptographers twitch, and (as noted in the documentation pages) compression is bound to offer a side-channel attack (if only an impractical one, with hundreds of queries per recovered byte).

Using TLS makes this particular cryptographer twitch.

Not GP, but a wannabe level 3 [1] cryptographer.

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

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

TLS 1.3 is definitely better than previous versions. Note however that it wasn't published until 2018; Tarsnap's transport layer has been in use since 2007, before even TLS 1.2 was published. If I had used TLS at the time, it would have been TLS 1.1. Hopefully you agree that would have been a bad thing?

I mean, TLS 1.1 isn't a good thing, but which <TLS1.3 bugs actually would have impacted Tarsnap? SMACK, maybe? Probably not POODLE, given the ciphersuites you'd have locked down to. Not BERserk (you'd never use NSS). The TLS BB'98 attacks didn't hit any library you'd actually use. No Triple Handshake, since you wouldn't do renegotiation. No BREACH, TIME or CRIME (they don't fit Tarsnap anyways). No RC4 (lol). No Lucky13, for the same reason as no POODLE. No BEAST, because you don't do Javascript. And now we're back to 2007 (or pre-2007) for attacks on TLS.

It's possible that I could have taken TLS 1.1 and removed all the broken parts, sure. I mean, that's pretty much what TLS 1.3 is.

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?)

Heartbleed isn't a TLS vulnerability any more than an overflow in GnuTLS is.

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.

That seems like the wrong question. My options were "write my own protocol" or "use openSSL" -- writing my own TLS stack was never on the table.

Right, I get that, but you could have done the two config things I just mentioned with OpenSSL.

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

What are real world implementations of the Noise Protocol? https://github.com/noiseprotocol/noise_spec/blob/v34/noise.m...

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.

I found a page by Duo Labs listing Noise in Production.

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

There's a bunch of them, but part of the point of Noise is to be extremely prescriptive in order to simplify implementation. WireGuard is based on Noise, but has a lot more than just Noise in it.

Yes, of course. I was just confused because it seemed like you were saying that even the new version of TLS was bad.

>This speaks volumes about the need of standardized encrypted cloud storage protocols

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.

I'd argue the opposite actually. Device owners pay a much higher cost in maintaining multiple, incompatible, devices that each require their own procedure to upgrade, means of notification, etc.

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.

This isn't how cryptography engineers think about cryptography. It isn't like a PHP program, where there's inevitably going to be some bug found somewhere, and you do what you can to find as many as you can and react responsibly when more are found later; cryptography engineers use formal methods (among other things) to foreclose on vulnerabilities. The vulnerabilities documented in this paper are "own goals", not cryptographic inevitabilities.

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

>This isn't how cryptography engineers think about cryptography.

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.

These are cryptography researchers, talking about cryptography vulnerabilities. The premise, both of the paper and to the comment upthread, is: we should have fewer cryptography vulnerabilities, and could accomplish that by not having people come up with random authentication and key escrow protocols.

Nextcloud's E2E encryption is at best very half baked, with very limited features.

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.

I completely agree, that was one of our main goals with Etebase (protocol behind EteSync).

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.

Restic had some professional cryptanalysis, and was very well received.

rclone already provides such a client and it is fully open source. In general, to have a zero-trust system, you need to have client and server developed by independent parties.

Reply on news.ycombinator.com