
Time to Encrypt the Cloud - dansup_
https://blog.cryptpad.fr/2017/02/20/Time-to-Encrypt-the-Cloud/
======
the8472
The problem with in-the-browser encryption is that it is fundamentally
insecure until websites can be made immutable. You're executing remote,
mutable code to handle your secret data. Which means at any point the website
operator could replace it with something that exfiltrates the data the moment
you access it.

Even if the operator is not malicious they could receive a court order or the
connection loading the code could be MITMed even if you think you're
secure[0].

[0] [https://medium.com/@karthikb351/airtel-is-sniffing-and-
censo...](https://medium.com/@karthikb351/airtel-is-sniffing-and-censoring-
cloudflares-traffic-in-india-and-they-don-t-even-know-
it-90935f7f6d98#.jktc9i7r6)

~~~
josephg
Its a bit harder to exploit, but this is also a problem with mobile apps. The
developer could be compelled to release an update which leaks data to a 3rd
party for specific users. Even for opensource projects there's no guarantee
that the published version of the app matches anything in the commit history.
And I doubt anybody looks inside the binaries that get published to the app
stores when there's source code available.

So right now on web or mobile you simply have to trust the app developers.

Apple & Google could easily fix this by copying the docker registry. Just run
a build process themselves directly from a specified git SHA. Publish that &
name the repo & git SHA they used for the build. That way security researchers
could go read the sourcecode and know that its the actual code running on
everyone's phones.

Mind you, doing this would make it easier for the US government to compel
apple or google to modify a binary for just one user. But apple and google can
already do that if they want to.

Another approach would be to make the whole toolchain build reproducible
binaries, so a researcher can run the build process themselves and verify the
binary hashes match.

But lets not pretend that somehow apps are more secure because you download a
sandboxed app from an app store instead of sandboxed JS + HTML. The tech
stacks used to deploy code are more similar than they are different.

~~~
pwg
> Even for opensource projects there's no guarantee that the published version
> of the app matches anything in the commit history.

But at least for opensource, if you are willing you can build your own binary,
using your own tools, from the source in the commit history, and get an app
that matches the commit history [1].

[1] Exclusive of the issues detailed in "Reflections on Trusting Trust" by Ken
Thompson regarding the actual build tools themselves
([https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thomp...](https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf))

------
Canada
There's nothing Zero Knowledge about this.

I'm starting to think that Spider Oak has destroyed the meaning of the term.
Apparently Zero knowledge now means E2E.

~~~
dredmorbius
If the system relies on user Peggy demonstrating to service Victor that Peggy
knows the keys that decrypt or access information, then the system approaches
the traditional meaning of "zero knowledge". (Peggy being Prover and Victor
being Verifier, see the ZKP Wikpedia page.)

If the system can work with Victor knowing _anything else_ about Peggy, e.g.,
_entirely taking the question "who are you" out of the equation_, well, then,
we've got an interesting situation.

~~~
Canada
If Alice can share notes with Bob in a manner where the service itself cannot
determine that Alice and Bob have any connection at all, then go ahead and
market that as Zero Knowledge. If the service can determine who is talking to
who, though either passive or active means, then it is disingenuous to claim
the service is Zero Knowledge.

Unless the anonymity set is very small or bandwidth is infinite, accomplishing
metadata privacy requires some kind of zero knowledge proof.

I don't think such systems necessarily require E2E encryption. If the term
zero knowledge continues to be misused, it's going to cause more confusion
later when services get around to protecting metadata.

~~~
dredmorbius
Fair points. I've misused the term myself (in ignorance), and can see how this
could easily get transformed by a nonexpert public.

------
lgierth
I love ansuz's and cjd's work on CryptPad! I use it daily as my personal notes
wiki synced between 3 computers, and occasionally for collaborative notes
taking in video calls with ~15 people. My happiness levels have increased with
every new iteration of features and fixes.

I recently suggested to add a frontend for collaborative agile retrospective
boards, similar to Retrium. CryptPad seems pretty pluggable in that regard,
and actually TIL it can even edit presentation slides now :)

~~~
metilda
CryptPad is pretty solid, definitely a step up from Etherpad Lite. Curious how
CryptPad's encryption could be leveraged in a replacement for uppit, as
another reddit from source install is obviously not a great idea.

------
hashtagInsecure

      We do this by adding a hash character (#) to a link. 
      By design, browsers don’t share anything after this 
      character.
    

...and I stopped reading there.

It is astonishing to read that. Just absolutely mind blowing.

Browsers absolutely _can_ and _DO_ share things coming after the hash (#)
character in a URL. How?

JavaScript! It's _absurdly_ easy to siphon anchor hashes out of the address
bar with JavaScript, and send them back to the mothership, or anywhere else
for that matter. It's basically how oh-so-many Very Big Websites work.

Are you kidding me?!

~~~
ianopolous
It's not the browser sharing the hash content, but the javascript in the page.
In something like this you clearly have to trust the javascript you download
each time in the page.

~~~
hashtagInsecure
[https://www.schneier.com/blog/archives/2015/05/detecting_qua...](https://www.schneier.com/blog/archives/2015/05/detecting_quant.html)

~~~
ianopolous
Is that attack possible over https, without compromising a CA or a local hack
like sslStrip? If a page is doing secret stuff over http it's even more
broken.

~~~
saycheese
>> "The usage of HTTPS in combination with HSTS can reduce the effectiveness
of QI. Also using a content delivery network (CDN) that offers low latency can
make it very difficult for the QI packet to win the race with the real
server."

Above is from the researchers: [https://blog.fox-it.com/2015/04/20/deep-dive-
into-quantum-in...](https://blog.fox-it.com/2015/04/20/deep-dive-into-quantum-
insert/)

~~~
ianopolous
It's not clear to me how it is possible over https only sites without forging
a certificate or MITMing the connection. The new content would have to be
encrypted with the correct key.

If indeed this is possible then the internet is totally broken. "Reduce the
effectiveness" implies that it is still possible though.

~~~
saycheese
Not sure it means the internet is broken, but would mean SSL is broken.

------
javajosh
People don't care about privacy in the abstract, and won't, until they are
really harmed by the loss of it.

It's not only ordinary people who don't care about privacy. Even businesses
who have a great deal to lose from loss of privacy, still use Slack and Gmail.
(Indeed, I bet _even Google competitors use Gmail_ ).

The real angle is _theft_ , not privacy. _Companies are always stealing all of
our data_ , which is why it's so cheap. If we took steps to protect it,
serious steps that actually denied companies the knowledge that drives their
growth, then we'd have gained something valuable. The unfortunate truth is
that people won't protect what they've come to believe is worthless, and so it
will remain worthless. A chicken-and-egg problem, to be sure.

~~~
dredmorbius
It's kind of a Gresham's Law dynamic in that regard.

Thing is, when people _do_ realise they care about privacy, they're going to
_really_ care about it.

[https://cryptpad.fr/pad/#/1/view/+VGaPJa1oHnDhNfGTugy+Q/gTSc...](https://cryptpad.fr/pad/#/1/view/+VGaPJa1oHnDhNfGTugy+Q/gTScFm4inC0DOdWXm36WHpS4lHILt8cIjev6eKIGvws)

------
ereyes01
I think a world where I could use cloud services for
pictures/documents/driving/social/etc. without being tracked and exploited for
either profit or manipulation would be wonderful. However, what would be the
economic incentive to provide such a service at Google- or Facebook-scale,
free of charge (via up-front subscription fees, of course)? Is there a
business model that is able to ignore the advertising and marketing value of
your data, yet still provides enough value to fuel the growth that Google,
Facebook, and others have experienced? Asked another way, would these
cloud/social services still be able to exist as we know them if their
providers were not allowed to collect and exploit this data?

~~~
Twisell
Theoretically what you are describing is Apple iCloud business model.

But some might say that because it's not open source you can't trust them.

Personally I trust the money I give them, they promised me privacy, I pay
monthly, if I am ever betrayed I'll leave apple ecosystem forever and they
will get less money. So they basically have no incentives to lie to me. Yes
it's all based on trust but this always come to that at some point.

~~~
balladeer
> But some might say that because it's not open source you can't trust them.

And should it not be the case? Theoretically.

As for the reasoning why they do not have incentive to lie to you goes same
for anyone and pretty much anything where a wrongdoing takes place that
shouldn't have happened in the first place. It could be anything. If we go for
examples it will be stretching it just too far.

The middle ground can be - an easy backup/sync/mail service that does the
heavy lifting - the transport work and we encrypt decrypt on the client side.
For example, we can't have a transportation company if all we have to do is
send a few packets every month across the company or globe. But we can have an
unbreakable lock/safe/package in which package the stuff and the receiver is
the only person how to open the stuff. I have never really been good at
analogies but I hope you get the drift.

If only they could write an easy app that uses the service APIs and code for
that app is open source and all it does is encryption decryption (generally
speaking) on the client machine. Something BackBlaze and CrashPlan claim to do
(they are closed source btw) and so does Tarsnap (haven't used it - too
complex and pricey for my use case; and not sure if it's open source).

~~~
cperciva
_Tarsnap (haven 't used it - too complex and pricey for my use case; and not
sure if it's open source)._

FWIW, Tarsnap is not under an open source _license_ , but you do get the
client source code (and you're encouraged to audit it before compiling).

------
danjoc
Encryption will only solve a portion of the problem. Google knows how old I
am. They know my sex. That can be fairly accurately derived by browsing habits
alone. I receive targeted ads for common health problems for people of my sex
in my age group. If I ever click on one of those ads, they now 'know' that I
have that condition... and consequently, now my data is worth more at the time
of sale. Same for Amazon. Same for Facebook.

It's not an easily solved problem. The best solution I've seen is Tor, but
then, using that will put you on several watch lists. If that is to ever
change, we need something like Tor built into a browser as incognito mode to
make it widely accessible.

~~~
rb808
> If I ever click on one of those ads, they now 'know' that I have that
> condition... and consequently, now my data is worth more at the time of
> sale. Same for Amazon. Same for Facebook. >It's not an easily solved
> problem.

If everyone clicked on stuff they aren't interested in that helps solve the
problem.

Also try getting children to use your computer and click ads - that really
confuses them. :)

~~~
megous
> Also try getting children to use your computer and click ads - that really
> confuses them. :)

It confuses the children? :)

------
abalone
The biggest problem with encrypting cloud storage by default for everyone is
not technical. It's that the consequences of losing keys is 100% data loss.
That is not generally speaking a good default design choice for average users
who want to entrust, say, a lifetime of photos to the cloud.

Encrypted storage is a great tool to have, but because the consequences of
losing keys are so severe it should usually be an opt-in choice where the user
has to positively acknowledge the consequences of losing their key. For most
consumers that's going to be for special cases.

It's probably the reason why Apple, which has been at the forefront of E2E
encryption with iMessage, does not offer general E2E encryption of iCloud. It
does however offer it in the form of encrypted notes in their Notes app. So
you can opt in to encrypted storage of secrets, but you'll still recover your
photo library if you forget your keychain password.

~~~
bigbugbag
If apple's primary concern for not offering icloud zero knowledge encryption
was that people may lose their data through loss of key why do they offer
exactly that option with their secure vault ?

It is expected that encrypted data will be lost when the key is lost, security
comes at the price of convenience.

I disagree that this should be an opt-in choice for an encrypted online data
storage service, the whole point of it being encrypted is to make sure it
cannot be accessed without the key thus preventing the service provider from
being a potential privacy breach point. In post-Snowden times where online
privacy requires encryption, always-on encryption for a third party data
storage service makes sense and caters to the growing demand for online
privacy.

~~~
abalone
_> why do they offer exactly that option with their secure vault?_

You mean FileVault, their disk encryption? Time Machine backups are not
encrypted by default. You have to opt in.

If you mean Keychain, their password manager, that's a good example of a high-
security special case. And there are usually ways of resetting lost passwords
so you may still survive the loss of your Keychain key.

This is not a matter of "convenience"... Apple does not want a million
customers crying at the Genius Bar over the permanent loss of a lifetime of
photo memories because they lost their key, ok? You have to design systems
expecting that normal people will lose their key at least once in their life.
Have you ever lost the keys to your home? For most people, if you offered to
improve the security of their home at the cost of _incinerating the house_ if
they lose their key, that would not on balance be a good default setup. Maybe
for their safety deposit box it would, and only in cases where they'd rather
destroy the contents than let them get into the wrong hands. But certainly
it's not a one-size-fits-all good default config in all cases.

------
fauigerzigerk
_" All data, over time, approaches deleted, or public."_

So which one is it in this case?

I think if you're offering something that isn't actually zero knowledge then
the way to create trust is to use something our societies have invented a long
time before web apps: Legally binding contracts that give sensible privacy
guarantees and support a viable business model.

I fear that's the best we will ever be able to do when it comes to web apps
that do more than just backup or data transfer.

------
franciscop
I did something similar* with CKEditor and the id+key after the "#" like 3-4
years back _when I was learning_ about real time and cryptography.

There were few practical problems that could not be easily resolved, the main
one being that the server could send a different javascript payload (by
modifying the HTML src) that leaks everything for specific clients and they
wouldn't even know.

The most reasonable solution would be a plugin of sorts that freezes the
front-end code and checks that the html+javascript has not been modified since
last time, but this wouldn't be practical and has a totally different set of
problems.

This scenario could happen if we consider real-world scenarios (imperfect/bad
actors):

\- Rogue hosting or admin: someone who controls the server decides to change
the javascript. They are smart enough to change the checksum in the <script>
so things still validate.

\- Cracked ("Hacked"): there is a vulnerability in some part of the stack and
the javascript gets changed unknowingly by the server admins.

\- MITM for a badly configured server that accepts "http:" instead of "https:"
and the user connects through a public network. Actually, the fact that it
redirects http to https has its own set of problems for the people who might
need this:
[http://security.stackexchange.com/q/44849/9161](http://security.stackexchange.com/q/44849/9161)

Did you solve this? If so, how?

*I did the proof of concept mixing front with back-end and never fully ported it to front-end for the problems explained above.

~~~
captn3m0
For the MITM Part, I can think of:

\- Send HSTS header in your code, instead of relying on the server). \- Drop
the connection if it is not secure. This breaks a reverse-proxy setup though.

------
netheril96
Tangentially related is my open source project on an authenticated encryption
filesystem:
[https://github.com/netheril96/securefs](https://github.com/netheril96/securefs).

------
pavfarb
The whole idea of relying core security guarantee (provable 'no knowledge' on
server side) on unreliable mechanism (in-browser cryptography) is feels really
wrong.

There are many services which attempt to base their security on in-browser
javascript cryptography.

What could be really valuable is not building Yet Another Service That Helps
Privacy (but really, doesn't), but investing effort into building trusted
execution models within the browser any website could utilize.

Secure apps will follow just instantly.

------
maturz
I might be a bit late to the party with this one but I just found
[https://github.com/duplicati/duplicati](https://github.com/duplicati/duplicati)
and it seems to be a very nice solution for encrypted cloud backups.

There's also [https://github.com/ncw/rclone](https://github.com/ncw/rclone) if
you would rather do it more like rsync.

~~~
arthurfm
... and Cryptomator. It's open source and has clients for Windows, macOS,
Linux, iOS and Android.

[https://cryptomator.org/](https://cryptomator.org/)

------
homakov
Two components left: 1) storage of credentials to encrypt the vault (see my
profile for a solution) 2) browser extension that verifies hashes of every
HTML response

------
kybernetikos
This looks a lot like monod

[https://monod.lelab.tailordev.fr/](https://monod.lelab.tailordev.fr/)

I've been using it as a private, sharable wiki for quite a while now.

------
richardwhiuk
The usability implications of not being able to access information if you lose
track of the link will be enough to ensure this never takes off, let alone the
vast security holes.

~~~
CPAhem
Encrypting locally before uploading to the cloud is probably the best
solution. That way unencrypted data never leaves your local device.

You can do this with an app like VeraCrypt
[https://veracrypt.codeplex.com](https://veracrypt.codeplex.com) for DropBox
or SyncDocs [https://syncdocs.com](https://syncdocs.com) for Google Drive.

Relying on cloud providers to protect your data is not a great idea - just ask
Hillary Clinton about Podesta. Adding a separate layer of security and another
means of authentication is more secure.

------
esseti
what's the source of how much the information are worth in dollars?

~~~
Eupolemos
And how often? Is this a one time sell of information or monthly exchange? I
was really curious about this piece of context as well.

------
womitt
Tresorit is way ahead of these guys...

------
marknadal
Two things:

1\. Don't just use cryptography, understand how Zero Knowledge encryption
works. These 1 minute animated explainer videos do a good job:
[http://gun.js.org/explainers/data/security.html](http://gun.js.org/explainers/data/security.html)

2\. We used the URL hash method they mention in the cryptpad article to create
a beautifully simple P2P payment system (direct bank to bank deposits, no
fees), completely end-to-end encrypted: checkard.com

It works and is a lot easier than people may think / expect to build!

~~~
dredmorbius
I haven't bothered with the video, but the website is not only wrong but
grossly ungrammatical.

"Most websites you use today have fake security. When you log onto their
service, your password gets sent up to their proprietary servers. There they
check to see if it is correct and grant you access to YOUR data."

"Sure, their servers might be in a top secret location. But the problem is
that they know your password. Which means any bad actor, like a rogue
employee, a hacker, or a government agency can snoop on your data without you
knowing."

This manages to _both_ mis-state how _good_ password practices (hashes and
salts) work[1], _or_ what their ultimate failure mode is: your data are
_still_ sitting on someone else's server unencrypted. The password, however
well hashed or salted, isn't proof against a warrant, hack, insider actions,
or poor media disposal.

But given the elementary errors in the text, I'm pretty confident the video is
not worth watching.

________________________________

Notes:

1\. See e.g.,
[https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet](https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet)

~~~
marknadal
We talk about hashes and salt in another episode. You can't cover everything
in 1 minute, especially when you want a 5 year old to be able to understand as
well.

The text is the transcript, which is intentionally conversational not a formal
essay. Maybe it is a good idea for us to change it though.

If your philosophy in life is to ignore learning ideas because you are
offended by a grammar error, then you are probably right to skip out, the
video isn't targeted at people like that.

~~~
dredmorbius
Grammar is an honest signal. It's not surefire, but the scope of errors here
portends quite poorly for the material.

Given issues of the modern Web, including the absolute deluge of information,
finding credible and worthwhile sources is itself a challenge.

Communication -- writing or otherwise -- should be done _for the benefit of
the reader or audience_. To borrow from another item on HN presently
(concerning writing manuals).

