Client: Adding ownCrypt : client-side encryption

[orion1024]

Hello,

This issue is created so that we can discuss the details on how ownCrypt should be integrated in the current code, both for the initial integration and as work on it progresses.

Some discussion material

General documentation about ownCrypt

• Design, intents and features (finished)
• Crypto design :
  
  
  
  • Crypto design (ongoing work)
  
  
  • Crypto design basic graph (finished)
  
  
  • Crypto design advanced graph (finished)
    
    

    Integration discussion

  
  

To start the discussion I created a more specific document.

Here is a quick brief of its content :

• Section 1 to 3 is an analysis of the sync algorithm code.
• Section 4 is where I detailed my proposal and what needs to be discussed with the client team.

While section 1 is for the most part a verbose description of what the code does, and not very interesting for someone familiar with the existing code, section 2 and 3 are more "meta" and are an attempt at documenting things to get a better overall understanding of the code structure.
NB : Section 1 to 3 are not completely finished but most of the remaining analysis is not critical for the initial integration.

I also created a "state graph" that describes how the discovery and reconcile phase decides what to do with each file. This is the graph (not included here because it too big).

While not very useful for someone who knows this by heart, it is a good reference when one needs (for instance) to know the possible paths for how an item could end up with the XXXX instruction.

Next steps

@ogoffart @danimo @dragotin @jturcotte

Starting point

The first thing I would like to do is reach an agreement with the client team on the proposals I made in the document, so that I can start coding.
Further discussion will be needed on other topics after this one, but I believe this is the most structuring code-wise.

Integration tests

I plan to use Jenkins to run proper integration tests. Is there any templates I could use to speed up the initial set up of Jenkins (for instance, to configure the building test) ?

I'm also considering tools such as Sikuli to test more things than the current torture tests. I read about Smashbox but it seems more about testing server-side functionality.
Comprehensive integration tests are pretty critical for ownCrypt since it will be implemented in the deepest layer of the client, so the risk of introducing regression is great.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[menelic]

@orion1024 looks promising! Looking forward to using this asap - more grease to your elbow, mate for the coding and support from the core and client devs!

[jospoortvliet]

@LukasReschke @karlitschek fyi ;-)

[karlitschek]

Yes. Pretty cool. Looking forward to pull requests ;-)

[gcollins]

This is fantastic! Will it have support for all clients or just PC/Mac? I'd be interested in it for use on Android as well.

[orion1024]

Ultimately I want to add the feature to the mobile clients too yes.
But (and it's a big but) the priority is to get the desktop version right before spending time on the mobile clients.
It is also a lot of additional work that needs a different skill set so as long as it's just me working on ownCrypt I really wouldn't expect mobile apps support before 2017.

[danimo]

Scoping this for 2.2 tentatively, so we can have the conversation once 2.1.1 is out. We haven't forgotten about it!

[orion1024]

@danimo
What is the general time frame for 2.1.1 and 2.2 ?

[scheppi2610]

Hello orion and all others,
(@danimo: 2.1.1 Beta is planned for tomorrow - see wiki - release dates)

Thank you for opening this request.
Having read only your initial design document V. 0.7 i want to remark some of my thoughts:

• your approach seems well-thought. Despite of your intention i think all "sharing" features should be re-thought. If I want an Ende-2-End encryption I do not want to share it. If I work on theese files as a team, every member needs the same key.
• I would like to contribute but i am not well in programming though i am manager in an IT company and could provide hardware, software or what else you might think about.
• i have collected MY needs in a brief document

Owncloud client.docx

[orion1024]

Hi Scheppi,

thanks for your interest.
I read your document, and first I need to clarify something because I'm not sure of what you want there : ownCrypt will do client-side encryption, but not "local disk encryption" (like EncFS/LUKS/TrueCrypt/BitLocker...).
That is to say, the files will be stored unencrypted locally.
Why ?

• It's a whole different product, loads of additional development work.
• There are already very good alternatives out there (for Windows enterprise clients, BitLocker is easy to setup by an administrator)
• It only provides good protection against a random thief who's only after your hardware IMHO. If your adversary wants _your_ data and can access your computer physically, it's not so hard for him to plant a hardware keylogger and get the password to decrypt your disk.

I agree with pretty much everything in your document. The distribution model I aim for is to have the feature baked into the standard client, to leverage ownCloud existing user base.
Not only because i want to make something useful and easily available to more people, but also because the more people use it, the more feedback I get to enhance/bugfix it.

The only point where we seem to disagree is sharing.
Sharing will be optional in ownCrypt. It's the user's choice whether to share part of its encrypted content to other people or not, or different parts with different people, so what are the reasons not to do it in your opinion ?

If you're interested in contributing, well first know that you're already doing it :) discussing and giving your opinion is a big help. Spreading the word around you about the project is also good.

If you're interested to contribute more (outside of coding), more opportunities will come. Designing an easy-to-use GUI and workflow, for instance, is a big part of ownCrypt, and one that needs as much feedback as possible from end-users.
Beta testers will also be very appreciated further down the line.

What exactly do you mean by "hardware and software" ?

One last thing : I work on ownCrypt on my spare time, so the development speed is very much dependent on the amount of time left by my professional/personal life otherwise.
I'm not sure when you need this feature, but ownCrypt won't be ready for production before several months. Just don't get your hopes too high if you need this feature quickly :)

[scheppi2610]

Hi orion,

i agree with all what you say. Local encryption is not necessary at least for first version.
Adding hard- or software now seems to me like a thumb idea as the whole development environment fits into a virtual box. Maybe i can contribute by asking a programmer to support you with code / GUI work.
by the way, would it make sense not to update all the different files for design documentation but to create a wiki page for discussion and documentation?

[scheppi2610]

Just to check that we have thought about it:
What do you folks think about integrating a full-featured encryption product instead of programming all along newly?
As i am not a real programmer i found this (https://veracrypt.codeplex.com/wikipage?title=Command%20Line%20Usage) for veracrypt. Unfortunately i did not find any hint to an API or something similar. But integration should be possible anyway, shouldn't it?

[romainvieme]

Hi orion !
I am very interested by this project. I wonder if it would be possible to let the user manage some of the keys : instead of having one key per file, you let the user maintain a set of custom keys (and insert a reference in the file metadata). This way you can encrypt a bunch of files with the same key. I see three advantages in letting the user do that:

• you save some entropy (advantageous in mobile devices, if I understand correctly !)
• you don't have to create many hidden files on the server to store the information for each user
• sharing a bunch of files together is easy : you just encrypt the key with the other user's public key and give it to him

Of course there are also some drawbacks e.g. :

• It's more difficult to share just one file with someone : you'd have to re-encrypt it in order not to reveal the other files encrypted with the same key
• It's a bit more involved for the user to manage his/her own keys
  But the way I see it, the first issue is more the user's responsibility, and the second could be resolved by not choosing this mode as default.

Please let me know if you're interested, I can describe the more precisely ! I think it could be built on top of the app. Though I'm not a professional developer, not sure I could really be too helpful...

[karlitschek]

@romainvieme Pull request welcome.

[orion1024]

@scheppi2610

No existing product, to my knowledge, can fit the requirements.
We need something :

• cross-platform (Windows/Linux/MAC/mobile)
• file-based (because synchronization would be a nightmare with container-based solutions like VeraCrypt)
• that allows sharing (so the key management must be open so we can share the keys)

Overall that's too specific I think...

Also, I just saw your suggestion regarding a wiki page, or something to handle suggestions in a better way, but I will give it some thought.

@romainvieme

Thanks for your interest. I'm not so sure about your suggestion regarding key management though.

• what do you mean by "saving some entropy" ?
• there is only one hidden file per folder as per current design, so we would gain nothing there
• From a developer point-of-view, I think it is actually simpler having "1 file = 1 key" true at all times : less corner cases to handle in the code
• From an end-user point-of-view, key management is hidden anyway (because ease of use is critical) so no change for them. The GUI will make it easy to share a bunch of files, that's one of the design objectives.

[scheppi2610]

orion, you are right. syncing the container does not make sense. I could imagine that it makes sense if we integrate the syncing algorithm into the encryption module. But therefore you would need to re-implement the encryption process.

[romainvieme]

Thanks for your response. What I suggested is to let some users (the ones who choose it) manage their own keyring. But you're right in that it would probably break the ease of use for everyone.
For the record, I'd like to explain what I thought (maybe you'll find it useful somehow).

• The issue with entropy presents itself mainly on the first upload of encrypted data. Probably some users at least will upload at once a lot of files : for instance, suppose I want to upload my photos on an owncloud server I don't trust. That could be ~ 10^4 files to be uploaded at once, i.e. 10^4 keys to generate. I do that on my laptop which has typically ~500-1000 bits of entropy available (browsing with HTTPS already eats some entropy). If lack of entropy is non-blocking, there could be some weak keys among the whole. If not, the process could take longer. Anyway, that's something to think about
• I read the crypto design (maybe too quickly) and I was under the impression that there was 1 hidden file for each device / user, encrypted by MPuK (§ 4.1.8.2). Are those stored on the client ?

As for the two other points, I totally aggree with you, all the more because I'm not the one writing the code ;) and it's maybe too early to talk about possible improvements !

[orion1024]

Regarding entropy : yes, the issue you mentioned with first upload is something I identified, but didn't fully thought out yet. I need to get myself familiar with how entropy works and affect key strength.
The (still quite vague) idea I have in my mind is to use the device entropy and some kind of user input (like : moving the mouse) to seed a CSPRNG. Hopefully the resulting entropy will be high enough for the CSPRNG to generate strong keys, but I need to think it through.

For hidden files : I misunderstood your 1st feedback actually. You are right, letting the user manage its keys would remove the need for hidden files for each device. But, it would kill usability IMHO. Think about someone wanting to share files with 20 people, it would be a nightmare.

Le 27 janv. 2016 à 13:31, romainvieme [email protected] a écrit :

Thanks for your response. What I suggested is to let some users (the ones who choose it) manage their own keyring. But you're right in that it would probably break the ease of use for everyone.
For the record, I'd like to explain what I thought (maybe you'll find it useful somehow).

The issue with entropy presents itself mainly on the first upload of encrypted data. Probably some users at least will upload at once a lot of files : for instance, suppose I want to upload my photos on an owncloud server I don't trust. That could be ~ 10^4 files to be uploaded at once, i.e. 10^4 keys to generate. I do that on my laptop which has typically ~500-1000 bits of entropy available (browsing with HTTPS already eats some entropy). If lack of entropy is non-blocking, there could be some weak keys aming the whole. If not, the process could take longer. Anyway, that's something to think about
I read the crypto design (maybe too quickly) and I was under the impression that there was 1 hidden file for each device / user, encrypted by MPuK (§ 4.1.8.2). Are those stored on the client ?
As for the two other points, I totally aggree with you, all the more because I'm not the one writing the code ;) and it's maybe too early to talk about possible improvements !

—
Reply to this email directly or view it on GitHub.

[menelic]

@orion1024 Hi, have you had a look at https://github.com/duplicati/duplicati ? tagline: "Store securely encrypted backups on cloud storage services". It does scheduled encrypted backups to owncloud, offers restore etc. Seems like the implementaion adressses most of the above?

[orion1024]

Hi menelic,

Duplicati is interesting, but the purpose is not the same : duplicati is a backup solution, which protects data against loss or corruption, while ownCrypt aims to protect it against server-side spying, while still allowing the user to work, sync and share these protected files _as usual_ .

Le 4 févr. 2016 à 00:19, menelic [email protected] a écrit :

@orion1024 Hi, have you had a look at https://github.com/duplicati/duplicati ? tagline: "Store securely encrypted backups on cloud storage services". It does scheduled encrypted backups to owncloud, offers restore etc. Seems like the implementaion adressses most of the above?

—
Reply to this email directly or view it on GitHub.

[ghost]

Hi, I am not fully aware of what is going on but IIRC the Mega.nz sync client does exactly what is intended here. The point is that sync client source code is now available and may be useful for you:

https://github.com/meganz/MEGAsync

[orion1024]

Thanks for the information.
Coding has begun but it's definitely worth checking how Mega is doing it.

[ghost]

Every time I saw something about end-to-end encryption on ownCloud there are a very valid concern about the breakage of the web interface. I do not know if there is anything already implemented or planned to that issue but I took a look (I do not code) on what may be useful and I find out ProtonMail is using openpgpjs there:

https://github.com/openpgpjs/openpgpjs
https://github.com/ProtonMail/WebClient

[orion1024]

As of now, there is no plan to implement client-side encryption for the Web interface.
This is intended : from what I gathered there is currently _no secure way of running client-side code in a browser_, which is a very insecure environment to run code by design.
Now, I know that this is a fast evolving field and it will probably change in the future.
And sooner than later, since there are a lot of incentives for it to happen.

Meanwhile, what does it mean for ownCrypt ? as you guessed it means that the encrypted files won't be usable from the Web interface.
But ownCrypt is designed to be a feature that you enable selectively, for your most critical files, not something you enable for everything (you _could_ do that, but you don't have to).

[e-alfred]

Will this make it still into 2.2? Until then, there is another open source software to encrypt files client-side in a cloud-friendly (service-agnostic) way:

https://github.com/cryptomator/cryptomator

[danimo]

No, 2.2 is closed.

[orion1024]

Given the current pace, I wouldn't expect anything before several months.
I'd like to at least have a beta version for this summer, but this is highly dependent on how much spare time "real-life" leaves me to work on this.

[dumblob]

@orion1024 thanks a lot for your initiative! I read quickly through your proposal and reactions to suggestions of others and from the position of an IT Project Manager responsible for a new enterprise secure data storage, I must agree with every single decision you made.

One think I'm curious about and I didn't see it anywhere is the question of deployment of ownCrypt over existing deployments of ownCloud client (e.g. to avoid refetching all the data). Will ownCrypt allow easy switching of the client-side encryption on and off (including an option to encrypt all current data)?

[orion1024]

Thanks for your support !

You will be able to switch CSE on and off flexibly yes, that's the goal.
Switching it on or off means at least once re-uploading the data to the server obviously.
But I would also like to avoid any fetching from other clients after that. This adds extra complexity to the sync algorithm though, and I don't have a full grasp yet on how to do it properly, so I can't guarantee this feature will make it.

[ghost]

Hi,
this is a very good initiative!
Would you be able to spend more time on the development if you received financial support?

Best regards!

[orion1024]

Hi @splashote ,

Thanks for your support and the proposal.
I'm afraid it wouldn't help, I have a full-time job which I don't plan to quit, so...
I hope to get some contributors interested once the project is more fleshed out though.

If you're willing to help there are other ways, even if you're not a contributor yourself : just spreading the word about the project around you, to people that you think might be interested is a big help, in and of itself.

[dumblob]

@orion1024 we could send a "Thank you" letter/certificate for you to your company, so that they are aware of your contributions and your value.

[orion1024]

@dumblob Thank you that's nice, although since my company does not employ me as a developer, they would not care much I think. Not that they don't value my work, just that that it's not in the same field ; I'm closer to what you do yourself.
In any case, as long as ownCrypt isn't delivered, usable and stable there is little to thank me for :)

@splashote actually I thought about some ideas where some money might help.
Later on in the project it would be good to either have a bug bounty or some cryptographers auditing ownCrypt. It's definitely not the time yet for that, but I'll keep thinking about it.

[ghost]

fine!

i have a server running owncloud based on the principles of economic
solidarity. every Euro not spent for the server is donated in order to
support open source software. I'd love to support owncloud with this money.

On Sat, May 7, 2016 at 12:28 AM, Orion1024 [email protected] wrote:

@dumblob https://github.com/dumblob Thank you that's nice, although
since my company does not employ me as a developer, they would not care
much I think. Not that they don't value my work, just that that it's not in
the same field ; I'm closer to what you do yourself.
In any case, as long as ownCrypt isn't delivered, usable and stable there
is little to thank me for :)

@splashote https://github.com/splashote actually I thought about some
ideas where some money might help.
Later on in the project it would be good to either have a bug bounty or
some cryptographers auditing ownCrypt. It's definitely not the time yet for
that, but I'll keep thinking about it.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/owncloud/client/issues/4327#issuecomment-217578843

[orion1024]

@splashote : I won't have any use of it for now, but if you're willing to help ownCloud I'm sure there are some ways you can spend it the regular ownCloud development. I'm not familiar with what is possible though, so you might want to ask someone more experienced.

[orion1024]

This is a quick brief on the status of integrating ownCrypt in ownCloud.
As usual, feedback is welcome.

1. Preliminary work

Goals

• make the transparent use of either normal or encrypted versions of network job possible.
• enforce some practices around network jobs to make ownCrypt integration over time less time-consuming (such as : avoiding direct creation of job, or direct access to the internal state of jobs)
• do not change any actual behavior at this point

Status

This is done through several PR to the master branch, several of which are ongoing :

• [ ] removing dependencies of propagator job on network job internal objects.

Status : _PR #4724 submitted, ready to review_

• [ ] enforcing job creation through job factories

Status : _PR #4816 submitted for feedback, 80% finished_

• [ ] creating abstract network job classes for each kind of network job (see this document, section 4 for more detail)

Status : _not started, requires the previous PR_

2. Add code that will actually introduces changes (and thus, risks)

Goals

• add first priority features (list TBD at the moment)

Status

• [ ] Encryption library

Status : _ongoing_

• [ ] client code making use of the encryption library (network jobs, GUIs, etc.)

Status : _not started, requires preliminary work to be done_

On @jturcotte advice, those changes would probably be pushed first to a feature branch, not directly to master.

[ash663]

@orion1024
I am a CS undergrad. I just started working on ownCloud as part of my internship. I would love to help you and contribute to ownCrypt in anyway possible. I do not know where to begin, could you help me and point me in the right directions?

[orion1024]

@ash663 thanks for your proposal ! Are you planning to contribute as a part of your internship ?

As a start you should read the documents linked in the top posts of this issue. I would start with "design, intents, etc.", then the crypto design graphs, then the crypto design doc (but this one is quite long, and not especially easy to read).
This will give you a rough idea of what needs to be done, and help you in deciding how and where you can contribute. It can be code, UX design, ideas, remarks...

We can discuss this on IRC if you want.

[mlmedia]

OwnCrypt sounds like something I'd definitely be interested in as well and can lend a hand if possible.

Seafile does client-side encryption for their cloud file sharing application, so perhaps some of the design for this can be borrowed from that application? So we could also avoid the same issues they had - for example with the web interface (which would cause problems for the strict client-to-client transaction).

https://github.com/haiwen/seafile/issues/824

[e-alfred]

Wouldn't it be possible to do the decryption on the client side in a web browser as well? Mega does this for example: https://github.com/meganz/webclient

[mlmedia]

RE: Mega NZ web browser encryption -

Where is the decryption key stored? How is it passed from the client (desktop) application to the web browser?

If the (private) decryption key is passed from the server to the client (and then JS performs the necessary decryption), then you run into the same issues giving a server administrator (or hacker) the ability to decrypt files with server access to the decryption key.

My understanding of how the client-side end-to-end encryption would work would be similar to OpenSSL public private key encryption. The public keys would be managed by the server application (similar to the way you add your public keys to Github) and the private keys allowing the decryption would always remain on the client side and NEVER on the server.

I'm new to this discussion however so I don't want to speak out of turn. It may be that the intent is to use something like symmetric key crypto where the same encryption and decryption keys are passed (via phone / email / carrier pigeon) between users.

EDIT: Interesting - it appears that Seafile uses symmetric key crypto using a master key which is encrypted, passed between users, and decrypted in order to decrypt the encrypted file(s). From what I can tell the password used to encrypt and decrypt the master key is stored in the client only and never on the server.

See here: http://manual.seafile.com/security/security_features.html

[orion1024]

@e-alfred

Wouldn't it be possible to do the decryption on the client side in a web browser as well? Mega does this for example: https://github.com/meganz/webclient

It would be possible technically, but it is not planned for ownCrypt for several reasons :

1. you break the threat model : even though the decryption code runs in your web browser, not on the server, the _code_ itself is provided by the server. So you implicitly trust the server with providing you non-malicious code. Trusting the server is exactly what we _don't_ want to do when using ownCrypt.
2. even if there was a reliable way to run trustworthy browser code to decrypt the file, web browsers are very insecure platforms to run critical code ; they were not designed to do that.
3. finally, implementing access through web-browser wouldn't be such a big gain for ownCloud users. While you could certainly access your files, since the decryption is done on the client, any app that runs on the server wouldn't be able to leverage the decrypted file (since it runs on the server). That means you still can't use the gallery app, calendar app, etc. on your encrypted files.

Point 1 & 2 might be resolved at some point in the future ; there are definitely steps in the right directions ; but it's not quite there yet.

[orion1024]

@mlmedia

ownCrypt will use a combination of symmetric and asymmetric encryption.
This is described in detail in the documents posted in the OP, but the gist of it is :

• files are encrypted using a symmetric key (1 file = 1 key)
• the symmetric keys are encrypted with a public key (1 device = 1 pair of public/private key)

When device A wants to share files with device B (they can belong to different users) :

1. A & B exchanges their public keys first
2. A encrypts the file keys with B public key and store it on the server
3. B can then fetch this and decrypt it with its private key, giving him access to the files keys.

OwnCrypt sounds like something I'd definitely be interested in as well and can lend a hand if possible.

Sounds great, how do you think you could contribute ?

[mlmedia]

@orion1024 I'm LAMP/LEMP full stack + front end. 8+ years.

A cloud files app like this would be fairly new to me, but I'm experienced enough to figure out what's needed.

I use ownCloud daily and could definitely make use of a more secure application for more sensitive files that I would never trust to the current ownCloud app (or Dropbox, Google Drive, etc.). I currently use Syncthing for secure (TLS) syncing of files between 3 of my computers (Mac, PC, and Linux). Something like ownCrypt would be better, which is why I'd be up for helping it along. I have some bandwidth...

[orion1024]

@mlmedia

The bulk of ownCrypt happens on the client, but ownCrypt usability can be enhanced with some helper features that need some development on the server-side :

For the web interface users convenience, and the overall reliability of ownCrypt :

• displaying encrypted files as such in the web interface ; and prevent any modifications through the web interface
• hiding ownCrypt metadata files in the web interface

To make key exchanges easier between users (these are still rough ideas) :

• an app that would store hashes of user profile information ; this would help users to discover if people they already know are hosted on this server, in order to initiate a public key exchange. It will be done in a way that would prevent any data leakage between the user and the server.
• an app to make the server act as a key server. This is the roughest idea, I'm not entirely sure it's a good idea to do this yet.

If you're interested on working on any of these, let me know.
If you don't have enough bandwidth it's fine as well ; any feedback or clever idea you might have on the existing material, what you would like to see in ownCrypt, etc. is welcome.

[ash663]

How would you recover files if user's disk gets wiped out due to some accident?

[e-alfred]

There is a new option available to encrypt files on the client side: https://www.cryfs.org/

[orion1024]

How would you recover files if user's disk gets wiped out due to some accident?

If the user gave access to its files to other devices he owns, or to other users, he can use those to recover them.
If only one device accessed the files, ownCrypt will provide an easy way for the user to backup its encryption keys (protected with a password or something similar), in order to be able to restore its files from the encrypted version on the server. If the keys backup get lost, however, the files are permanently lost.

There is a new option available to encrypt files on the client side: https://www.cryfs.org/

Those solutions can't be used if you want to share your encrypted files unfortunately.

Also, a short update : progress has been very slow in the last few months thanks to my dayjob being very busy.
The high workload should abate after the summer though, and I'm still set on delivering the feature.
The goal is to have a beta out at the end of the year.

[scheppi2610]

Orion, is there anything particular I can give my programmer to solve ? Is there any code to download and verify?

[orion1024]

@scheppi2610 nothing ready yet.
I'm currently busy designing the code so that ownCrypt can be used as an API by different clients (ownCloud desktop, IOS and Android) ; as a bonus it will also be easier for several developers to work on different sections of the code.
I expect the first draft of the API to be ready by mid-september.

[vx28643]

I can't wait for this feature, thank you for working on it. I would just like to say that I hope you include the choice in the desktop client to exempt specific folders or accounts from the encryption, for cases where encryption is not desired - for sharing purposes and web access to certain files on Owncloud, while encrypting the other files.

[orion1024]

@vx28643

Yes, you will be able to selectively enable encryption on folders ; it won't be an "all or nothing" option.

[sushidave]

@orion1024 I guess this will be a real treat for people who like to keep their data protected and I wish you all the best for this enhancement.
At the moment, contact and calendar data is stored in plain text in the OC database. Does this new feature cover encryption of this data, too?
Bare with me, I didn't read the document because the browser said the connection was insecure (SEC_ERROR_UNKNOWN_ISSUER).

[orion1024]

Hello,
encrypting calendar and contacts information wouldn't work.
Unlike files where we use a specific sync client, contacts and cals are usually synced using a very diverse variety of clients : mobile embedded apps, thunderbird, outlook, and so on. You would have to modify all those clients in order to make sure users can still use their calendar and contacts as before. Clearly something out of reach.
If CSE for this kind of data was to ever happen, it would be through the addition of the feature in CalDAV/CardDAV standards I think.
Then all the editors would be incentivized to add it to their clients.

Le 15 août 2016 à 21:26, sushidave [email protected] a écrit :

@orion1024 I guess this will be a real treat for people who like to keep their data protected and I wish you all the best for this enhancement.
At the moment, contact and calendar data is stored in plain text in the OC database. Does this new feature cover encryption of this data, too?
Bare with me, I haven't read the document because by browser said the connection was be insecure (SEC_ERROR_UNKNOWN_ISSUER).

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[sushidave]

@orion1024 Thank you very much. From your point of view, would it make sense then to cover it by some server-side encryption (feature request) similar to what exists for files?

[crowetic]

How far along is this project? I'm very excited for the chance to make use of it. Thanks!

[chrsch]

@orion1024 If there is anything I could do to support this great project let me know. I can do reviews or even coding. Keep up the good work :-)

[orion1024]

Sorry for the late reply, for some reasons I didn't get any notifications from Github these past months.

@sushidave : it could make sense yes ; it mainly depends on how calendar information is stored today, which I'm not sure of. If calendar information can be stored on external storage then definitely. Otherwise, it may not.

@crowetic : thanks for your interest ! I didn't make any progress the last few months unfortunately, due to lack of time. Work has been crazy. My plan is to release the first version of the API at the end of the year ; integration with the ownCloud client and encryption polishing should take several months after that, unless other contributors step in of course.

@chrsch : thanks for your proposal ! Your help with review/code will be more than welcome once I released the first version of the API (ETA is end of year). Regarding coding, do you have any preference as to which area of the project to contribute to ?

[wasimshaik]

Hi ,

Is there any update on this project??

Thanks,
Walter

[orion1024]

Hi @wasimshaik

Thanks for your interest ; no update yet, see my previous comment.

[chrsch]

@orion1024 I can help in any part of the project. I have a lot experience in backend stuff and quite reasonable Qt experience as well. Just let me know :-)

[crowetic]

hello @orion1024 - I would be interested in donating to help this project move faster, if that would be of any assistance, I may also have some developers on my team who would be helpful.

Let me know if a bit of donation would help, and/or if you'd like me to talk to any of my development team and see if they would be open to helping.

[ghost]

I totally agree on pushing the development of this feature.

I already raised some money to spend on FOSS in my project, but I think this should be communicated more broadly on another scale.

So, I'm in for managing it and general communication. Who's willing to do the coding and how much money shall we raise?

[orion1024]

Hello all,

first an update : no progress has been made yet ; I'm currently moving away from Paris and didn't have any time for the project. Once I'm settled at my new place (should occur next month) I will have a lot more time to spend on ownCrypt.

@crowetic : thanks for your proposal. Money wouldn't change anything for me, but it may help getting more contributors involved. Since @splashote seems to have experience in this he may have more ideas than I do on how to spend this money.

@splashote : I would be glad to have your help in management and communication. What do you say about a chat on IRC or Skype in early January ? Note that I already started the coding, although there is not much to see yet for the API. I also submitted some PRs to the client repo earlier this year, but they have not been merged and they will probably need to be scrapped ; the base code has changed too much since submission.

@chrsch : I didn't forget you :) I would be happy to discuss the API design I have in mind with you, before the first version is out. Would you be interested in that ?

[ghost]

@orion1024

Sounds great! As nextcloud is really dynamic and they have a nice forum, I'll open a thread over there to raise awareness and see whether we gather other people that could support you in coding.

IMHO we could set a date and time for a hangout and everyone interested in supporting the development in any kind is welcome to join it. What do you think?

I'm abroad till the 5th, but the 6th, 7th or 8th January would suit me.

[orion1024]

Sounds good, although I'm not available for these 3 days (moving out) ; any day (except Tuesdays) after the 8th is fine for me.

[ghost]

Ok, you're in France, right?

At what time does it suit you?

[orion1024]

Yes, I'm in France.
As for the time, after 9 PM during the week (after 11 PM on Thursday), anytime during the weekend.

[KDB2]

@orion1024
Thanks for taking time to implement such an amazing feature.
SpiderOak claims to do client side encryption. And some of their code is opensource. I don't know if you have looked at it already, but it may be worth it.

[orion1024]

Hi Emmanuel,

Thanks for your support.
Thanks for the suggestion, I knew about SpiderOak by fame since they were mentioned by Snowden. I definitely plan to analyze their code, and others as well. Iirc, Seafile code is open source as well.

Le 12 janv. 2017 à 18:24, Emmanuel [e-mail] a écrit :

@orion1024
Thanks for taking time to implement such an amazing feature.
SpiderOak claims to do client side encryption. And some of their code is opensource. I don't know if you have looked at it already, but it may be worth it.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[colans]

SpiderOak's library is Crypton. I opened an issue to get information on how compatible it is with W3C's Web Cryptography API, but no response yet.

We're hoping to see if we can get something like this done in Drupal as a GSOC project this year. If it goes through, maybe we can collaborate somewhat. Thank you ownCloud for last year's idea!

In other news, I just heard about a proprietary hosted solution that may be worth looking at as an example: Sync.com. See their white paper.

[rugk]

Another proprietary client is called Tresorit.

[e-alfred]

@rugk Tresorit doesn't seem to offer third party access, it is basically yet another cloud service (and mostly proprietary, so I am not so sure about how secure they really are even though they claim it as their most important feature). Anyway, there are a some things on their official Github account (Zerokit mostly):

https://github.com/tresorit

[gaspar-ilom]

@orion1024 Are you still working on delivering ownCrypt? I am really looking forward to having the feature and apparently a lot of the design work has already been done. Thanks for that!

I understand that it is crucial to have a stable and usable desktop client first. However, I have been thinking that it would be great to be able to have Web access to encrypted files.
One way to realize that would be to encrypt the user's private key with a password and store it on the server. The browser could then retrieve and decrypt the key in order to provide Web access to the encrypted files. Obviously this does not solve all the issues you mentioned (like trusting the mobile code delivered by the server) and a weak password would compromise data security. Anyway I think it would be nice to have it as an optional feature. What do you think?

[chrsch]

Maybe integrating https://cryptomator.org/de/ into the ownCloud client is cool. They are looking for partnerships as well.

[hodyroff]

Chattet with them. Not sure a full integration makes sense. But Cryptomator can be used very much in addition to the ownCloud Client. Eg: Sciebo is recommending it to their 80k users for secret documents.

[chaos-prevails]

Why not integrate it with the existing GPG private/public key environment? Everything is already there: key management, pinentry. It is widely used, e.g. with thunderbird and enigmail. Also it's user-based and not share based like cryptomator.

client-side encryption would obsolete the webinterface, so even uploading could be problematic. One could think of an addon like mailvelope to be able to at least upload and download and (probably) view images.

[chaos-prevails]

@orion1024 If I understand you correctly, it seems that you were planning also a symmetric key to prevent having to (re-)encrypt all files again if a file is (re)shared to another person.

I really think the existing GPG environment could be used, an external keyserver could be used (no need to reinvent the wheel).

Another I think important issue: client-side encryption has it's biggest advantage when you use owncloud/nextcloud on foreign infrastructure (e.g. your provider). If you use nextcloud on your own server which is maintained regularly, I think the main security issue is client security. And then client-side encryption doesn't help at all, except: if you have a share offline on your computer, all files stay encrypted as long as you don't open them (so they are not decrypted automatically when received from the server). Only when you open them, they get decrypted (into a temporary save folder). When you save them, the encrypted file is saved back to the share and uploaded to the server by nextcloud. So there would be a need to handle files within nextcloud exclusively by the nextcloud app (e.g. with a special extension so they can also be easily identified as encrypted?).

I could help in the planning phase, I'm not sure if I can help with the code ...

[chaos-prevails]

BTW there is a browser addon for cryptomator: https://blog.cyberduck.io/2017/01/19/cryptomator/

I haven't tried it out yet. But it seems there is already a lot out for client-side encryption for owncloud/nextcloud

[e-alfred]

Indeed. With Cyberduck and Webdav it is even possible to have a client with Cryptomator integrated. Sadly not for Linux.

The only problem with their own client is that they use an integrated Webdav server to enable access to the unencrypted files which is not that great if using tools that don't support this.

[orion1024]

Hello,

thanks all for the interest, I'll try to answer every question :

@gaspar-ilom : there has been no progress unfortunately since the last 12 months, as I have been more busy with other stuff than I had anticipated. I'm hopeful I will have more time soon, since a lot of what was keeping me from this work is about to clear up.
On your idea regarding storing the key encrypted on the server : I don't see why not on first glance, but these topics needs thorough analysis. I also think other solutions do exactly that, so it's probably feasible ; but more consideration is needed anyway.
And in any case, the web client won't be a priority as long as the desktop client (and, probably, the mobile ones) is not ready.

@chaos-prevails : I studied the possibility of using GPG, but as I see it we wouldn't get a lot of benefit from it :

• easy file sharing and multi-device access requires that devices/users have a transparent mean of exchanging their public keys. This is not built-in in GPG, so you would need to create this layer, even if we were using GPG keys
• we also need a combination of asymmetric and symmetric encryption. For key-management purposes as you mentioned, but also for performances issues too since asymmetric cypher are way too slow for general-purpose file encryption. So we would need to build that layer too on top of GPG

And on the drawbacks side, we would be introducing a dependency on a software that is not really aligned with our use case (email vs file encryption), so I would be afraid that further development in GPG would eventually make it impossible to retrofit it in ownCrypt.
But I might be wrong and missing a part of the GPG picture ; I'm open to any counter-argument you might have regarding this.

@e-alfred @chrsch @hodyroff :
Cryptomator would make the implementation of file sharing very difficult and awkward, given the way they work today (local file-based encryption), even more so for the mobile apps.

[rugk]

Actually IMHO a crypto later just as Cryptomator does it would be the first easy step. Of course, just symmetrically with a user-provided password. This already allows many use-cases when users just want to sync files from different devices without accessing them in the web client or sharing them.
Sharing encrypted stuff can be made later like Passman does, which BTW already supports attaching files.

However, I'd rather have this included in the official NextCloud (or OwnCloud) client directly…

[chaos-prevails]

@orion1024 thanks for your thoughts.

• Ad transparently exchanging public keys: we could use the already existing https://www.gnupg.org/gph/en/manual/x457.html. I think the latest version of the enigma roundcube plugin has this implemented.

• file vs email encryption: I'm not sure there will be diverging developments. Attachments get (automatically) encrypted when sending an encrypted email (or decrypted when receiving) and e.g. gpg kleopatra is a encryption interface integrated into the windows file explorer for file encryption/decryption. on linux there is seafile (for ubuntu/nautilus) and for mac there is gpgtools / gpgsuite for file-based encryption/decryption. They all use gpg encryption.

But that's not touching the asymmetric performance problem. It's just a thought because all this is already there: file based and user-specific encryption, exchange of public keys. probably one could think of a combination of symmetric-asymmetric encryption where the asymmetric encryption encrypts the master key of the symmetric encryption. So changing share permissions only re-encrypts the symmetric master key, the encrypted file itself can be left alone.

[orion1024]

on linux there is seafile (for ubuntu/nautilus)

Seafile actually uses AES to encrypt its files. While you can encrypt files with PGP suite, the use case is not quite the same since it's about encrypting one single file each time, whereas for ownCrypt we need to encrypt large amount of files.

It's just a thought because all this is already there: file based and user-specific encryption, exchange of public keys.

I definitely don't want to reinvent the wheel, and I will be using well-known encryption libraries for the project. The design I created for ownCrypt is very much inspired by what other products are doing (Seafile, SpiderOak, TresorIT, and so on).

Regarding public keys, key distribution is actually the easy part (since with the ownCloud server we already have a central repository ready) ; the hard one is implementing a key verification system that is both easy to use, and immune to server-side tampering. PGP fails completely at the first criteria IMHO, since its key management system requires high skills from all its users for proper functionality.

The best proof of that is that almost no one is using it outside the IT community (see Moxie Marlinspike's take on GPG) ; and I think we will agree that people outside this community are the ones that needs the most features such as client-side encryption, since they are generally not that good at protecting their privacy online.

[Hamsterman]

+1 Keep up the good work!

[sushidave]

Cryptomator was announced this week on the Nextcloud blog as a ready-to-use client-side encryption solution. How different is it from the ownCrypt solution?

[rugk]

Cryptomator's Android app is not open-source.

[chrsch]

The Cryptomator lib with all functions needed by a third party app (e. g. Nextcloud Android App) is open source https://github.com/cryptomator/cryptolib - Though I don't know if there are already plans to integrate it.

[e-alfred]

Cryptomator for mobile is "Open Core". The libraries used are Open Source, the desktop clients are fully Open Source.

The Nextcloud announcement says they are examining how they could integrate it. It would be nice if something comes from that, for sure.

[orion1024]

Also note that few work has been done on ownCrypt, so if something comes out of cryptomator-related efforts it would be good news.
The main issue I have with current cryptomator implementation is that it doesn't allow for file sharing, which is a big barrier to adoption.

Le 19 août 2017 à 12:44, e-alfred [e-mail] a écrit :

Cryptomator for mobile is "Open Core". The libraries used are Open Source, the desktop clients are fully Open Source.

The Nextcloud announcement says they are examining how they could integrate it. It would be nice if something comes from that, for sure.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[rugk]

I think for some use cases file sharing is not important and in that case users can just use that cryptomator integration.

[hodyroff]

Cryptomator was introduced to the ownCloud Community in June:
https://owncloud.org/blog/cryptomator-we-talked-to-christian-schmickler/
https://owncloud.org/blog/how-to-set-up-end-to-end-encryption-with-cryptomator/

Nice to see that the ownCloud Fork is catching up ... it has great use cases and is used by many of our 14 Million Users worldwide.

However sharing is not clear and we will continue to look into this, after all ownCloud is a sync and share solution ;)

In absence of an OSS implementation we are starting to offer a commercial E2EE solution from a partner which is ready for trial in the markplace. It is a browser and Outlook based solution for a start, but will get desktop and mobile integration over time.
https://marketplace.owncloud.com/apps/e2eeshare

@orion1024 if you need specific help on anything, please don't hesitate to reach out

[rugk]

NextCloud was faster. They introduce their real integrated (native) end-to-end encryption and already have beta software: https://nextcloud.com/blog/nextcloud-introducing-native-integrated-end-to-end-encryption/

[jospoortvliet]

@orion1024 we would absolutely LOVE feedback on our design from you, as you've been thinking about this for a long time! You can see the full design description in github here: https://github.com/nextcloud/end_to_end_encryption_rfc

We even have a nice white paper with illustrations on https://nextcloud.com/endtoend

Note that this is not comparable to what ownCloud offers except that both use the term 'end-to-end' - we don't support decryption in the browser or anonymous users but work in the client, ownCloud E2EE doesn't work in the clients but works in the browser and with external users. Our solution is explicitly designed to protect against a server breach, the ownCloud solution doesn't protect against server breaches any more than what server-side encryption already does.

[DeepDiver1975]

the ownCloud solution doesn't protect against server breaches any more than what server-side encryption already does.

@jospoortvliet please step back on judging our solution. Looks like you have no understanding on how it works.
Client support is being worked on. So please stop spreading false facts. THX

[unsuckvim]

Wow, it seems that OwnCloud got it right and made access through the browser a priority, showing that user-friendliness and security are not conflicting goals. Awesome work! Too bad NextCloud is not heading the same direction. After all, browser access could be disabled on a per-instance basis, if desired. Also, too bad it's not an open source solution and quite expensive for me as a single, private person (i.e., no enterprise customer).

[LEDfan]

Wow, it seems that OwnCloud got it right and made access through the browser a priority, showing that user-friendliness and security are not conflicting goals

Note that the proposed solution by @orion1024 (https://github.com/owncloud/client/issues/4327#issuecomment-224839775) would also mean disabling access through the web-browser. The only code which can run in a webbrowser is delivered by the server, if you don't trust the server to store your data why would you trust code delivered by the very same server? Even if you use an browser addon, you still can use injected JS to get the decryption key.

the ownCloud solution doesn't protect against server breaches any more than what server-side encryption already does.
@jospoortvliet please step back on judging our solution. Looks like you have no understanding on how it works.

This is actually the same as I noted above, if the server is breached it's really very simple to inject a JS script into oC/NC which will send the decryption key back to the server. That's why @jospoortvliet noted a browser-based implementation doesn't protects from a server breach (since you still have to trust the server)

After all, browser access could be disabled on a per-instance basis,

This would give a wrong idea to end users. By giving users the choice you seem to imply that using the browser (and thus trusting the server) is secure, which is not.

[unsuckvim]

Agreed, there seems to be no solution to this so far. It would be interesting if there could be a solution using a combination of the Subresource Integrity mechanism, and a browser addon. For example the java script code could be loaded from a public github repository while the Browser plugin could locally check the integrity instead of relying on the server. For use cases where a browser plugin is not available (public computer or share to external people), there could possibly be a fall-back solution, maybe using a verification website of some sort.

I think the best approach is to find a possible solution that does not require trust in the server or the Browser. It could even involve some Blockchain-based ideas towards code integrity. Simply saying it is not feasible is not very productive.

This would give a wrong idea to end users. By giving users the choice you seem to imply that using the browser (and thus trusting the server) is secure, which is not.

If the server administrator does not trust the browser solution, it should be possible to disable the access through the browser server wide (i.e. instance-based = server-wide != user-based). I don't see how that would confuse users as they would simply not be able to access encrypted storage.

[jospoortvliet]

@unsuckvim you're right that it is not entirely impossible, just very hard. We did debate it and we have inhouse experience building browser addins (done chrome and firefox for our video calls apps before) but doing it really secure is hard.

Plus the main benefit of browser support is in giving ppl from outside the server user base access - eg customers or friends. But then they would have to install an add-in, that decreases the user-friendlyness a lot. So it is a bit low on the list of priorities but we explicitly kept the option open in the design, see the white paper.

We wouldn't want to disable browser access instance-wide, the whole benefit of this is you get to choose: use E2EE for your financial data for example; and happily use commenting, search and collaborative editing on the rest of your data. Have your security; have your productivity. That's what sets our solution apart from almost all other fully end-to-end encrypted solutions on the market.

[dumblob]

Server trustworthiness checking using a web browser is a very very hard issue (seems actually currently not solvable). See the comments in https://github.com/jasonmunro/cypht/issues/185 .

If anyone knows about existing solutions for reliably checking the server trustworthiness using a web browser (i.e. not theories, but a functional code), please let me know immediately.

[orion1024]

@jospoortvliet sure I'll read it. On first glance it seems you nailed most of what I envisioned with ownCrypt. Great job !

I'm also taking this opportunity to officially announce that I'm dropping this project. There are several reasons, but it's mainly because I couldn't find the time and motivation to work on it.
Anyone is welcomed to recycle the ideas and materials I produced, although it barely seems necessary with both ownCloud and nextCloud having their own efforts ongoing.
I also thank everyone who expressed support and offered their help ; I wished I could have delivered like i hoped to.

One more thing, and I don't want this to be interpreted the wrong way ; this is not said out of resentment or anything like that.

The lack of followup on the 2 PR I submitted last year (I closed them today) made it very difficult for me to commit a lot of time to the project. Indeed, it wasn't a project that could work without some commitment from the internal team, like a server app could.
With no feedback on those PR, I was faced with the perspective of spending a lot of my personal time on ownCrypt without any guarantee that my code would be integrated in the end. Other personal circumstances made it even harder, but this was the main reason.
While I understand that 100% guarantee is impossible (after all, I could have written crappy code), given the amount of time needed to realize this project at least some insurance was needed.

So nextCloud message about better supporting contributors resonated with me a lot.
I'm giving this feedback in the hope that it helps ownCloud to improve and execute better with future contributors.

[jospoortvliet]

@orion1024 hey, thanks for your efforts, thought and energy you put in! It was a motivation for us in getting a well designed solution together in Nextcloud. If you ever want to help make a difference in private clouds again, we'd more than welcome your contributions!

If you're interested, I gave a talk about the E2EE at 34C3 in Leipzig, it'll probably be online soon and I'll share it then.

[Apromixately]

Hey @jospoortvliet, did you end up giving that talk?