[winterdeaf]

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.

[cperciva]

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.

[winterdeaf]

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

[cperciva]

Using TLS makes this particular cryptographer twitch.

[ghoward]

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

[cperciva]

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?

[tptacek]

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.

[ghoward]

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

[jjcon]

>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.

[tptacek]

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.

[jjcon]

>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.

[tptacek]

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.

[er4hn]

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.

[jacooper]

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.

[tasn]

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.

[mappu]

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

[sally1620]

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.