New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enhancement/design idea: encrypt everything: client-side end-to-end encryption using OpenPGP JavaScript implementation, not requiring additional software to be installed [$25] #106

Open
Wikinaut opened this Issue Oct 26, 2012 · 86 comments

Comments

Projects
None yet
@Wikinaut
Contributor

Wikinaut commented Oct 26, 2012

I file this as suggestion to overcome several problems with the server-side encryption of pre-4.5 versions.

Situation ownCloud (as far as I understand it)

  • when using the server-side encryption, you cannot share files. Files are encrypted per single key for all files in the user directory. Sharing would require to pass the key to the person with whom you want to share the file.

Current developments:

Using the mentioned techniques it would become possible

  • to have a possibility for a platform independent (browser-) client-side encryption and decryption of files. All data traffic to the server would be encrypted, all files are only stored encrypted on the server, and no server-side encryption will be necessary any longer.
  • to assign all users a user key (each user has their own user key), and all their files got encrypted (client-side) with their specific user's key
  • to share (encrypted) files, given that they are encrypted with more than the key of the user, for example the user key and a key for another user, or for another group who shares one group key.
  • enterprise users, where in enterprises usually the installation of additional software is prohibited, can participate as any other user, because the en/decryption takes place in their browsers and does not require installation of any software (GPG, openPGP, ...) except a contemporary HTML5 browser which is capable to run the client-side crypto algorithms.
  • all traffic is encrypted
  • no plain files on the server

[0] https://github.com/openpgpjs/openpgpjs/wiki/Introduction#wiki-impl-js Other OpenPGP JavaScript implementations
[1] http://www.openpgpjs.org/
This project aims to provide an Open Source OpenPGP library in JavaScript so it can be used on virtually every device. Instead of other plugins that are aimed at using e.g. NPAPI (meaning they are intended to run native code), OpenPGP.js is meant to bypass this requirement (i.e. people will not have to install gpg on their machines in order to use the software). The idea is to implement all the needed OpenPGP functionality in a JavaScript library, to reuse it in other projects and to provide example applications and browser plugins. It should allow you to sign, encrypt, decrypt, and verify any kind of text - in particular e-mails - as well as managing keys.

[2] openpgpjs/openpgpjs#12 Feature: PGP encrypted file upload/download
[3] https://github.com/hellais/up-crypt client side AES encrypted file upload.

[UPDATED 20121210]

[4] http://www.mailvelope.com/ Mailvelope is a browser extension that allows to exchange encrypted emails following the OpenPGP encryption standard.
[5] https://github.com/toberndo/mailvelope

[updated 20130102]

[6] http://www.dp-dhl.com/en/media_relations/press_releases/2012/docwallet_documents_manager_for_the_ipad.html Deutsche Post AG end-to-end AES-256 encryption for documents
[7] http://www.heise.de/ct/inhalt/2013/02/42/ "PDF-Tresor von der Post" article in "c't" 2013/2 page 42

[updated 201304261]

[8] mailvelope/mailvelope#45 regarding private key security

[updated 20131114]

I just found these cloud services claiming to offer end-to-end encrypted cloud services

[9] SpiderOak https://spideroak.com/
[10] TeamDrive http://www.teamdrive.com/de/

@LukasReschke

This comment has been minimized.

Show comment
Hide comment
@LukasReschke

LukasReschke Oct 28, 2012

Member

@samtuke @schiesbn May I ask you to have a look at this request?

Member

LukasReschke commented Oct 28, 2012

@samtuke @schiesbn May I ask you to have a look at this request?

@jancborchardt

This comment has been minimized.

Show comment
Hide comment
@jancborchardt

jancborchardt Oct 28, 2012

Member

The problem with encryption is not the implementation, but the simple fact that if you lose your password, your files are gone.

This doesn’t map to anything we know in the physical space about security, so we can’t advertise it as that. When I lock my apartment and lose my key, I can still get in somehow. But when I forget my password (which happens often to many people) everything is gone.

We have people losing data even when not using encryption, so we shouldn’t move forward with heavier features before we have the core working. I get that it’s interesting and encryption is very relevant, but it’s also really easy to lose all your data. And we don’t want that to happen, ever.

Member

jancborchardt commented Oct 28, 2012

The problem with encryption is not the implementation, but the simple fact that if you lose your password, your files are gone.

This doesn’t map to anything we know in the physical space about security, so we can’t advertise it as that. When I lock my apartment and lose my key, I can still get in somehow. But when I forget my password (which happens often to many people) everything is gone.

We have people losing data even when not using encryption, so we shouldn’t move forward with heavier features before we have the core working. I get that it’s interesting and encryption is very relevant, but it’s also really easy to lose all your data. And we don’t want that to happen, ever.

@Wikinaut

This comment has been minimized.

Show comment
Hide comment
@Wikinaut

Wikinaut Oct 29, 2012

Contributor

@jancborchardt

The problem with encryption is not the implementation, but the simple fact that if you lose your password, your files are gone.

You misunderstood my suggestion. Please let me explain.I wanted to give admins who like ownCloud a tool for enhanced privacy and security. This requires an end-to-end encryption which the former (user-data based, server-side) encryption could not offer.

My design idea lists all current third-party development, which could probably be used to develop a robust plugin for ownCloud to allow such an end-to-end, client-side encryption.

The issue of "if you lose your password, your files are gone" is a no-issue and valid for everyone, everywhere. When using a "cloud" solution, this does not solve users' backup problems, which are users' issues.

  • I suggest you label this bug as "enhancement". and leave it open for further discussion.
Contributor

Wikinaut commented Oct 29, 2012

@jancborchardt

The problem with encryption is not the implementation, but the simple fact that if you lose your password, your files are gone.

You misunderstood my suggestion. Please let me explain.I wanted to give admins who like ownCloud a tool for enhanced privacy and security. This requires an end-to-end encryption which the former (user-data based, server-side) encryption could not offer.

My design idea lists all current third-party development, which could probably be used to develop a robust plugin for ownCloud to allow such an end-to-end, client-side encryption.

The issue of "if you lose your password, your files are gone" is a no-issue and valid for everyone, everywhere. When using a "cloud" solution, this does not solve users' backup problems, which are users' issues.

  • I suggest you label this bug as "enhancement". and leave it open for further discussion.
@jancborchardt

This comment has been minimized.

Show comment
Hide comment
@jancborchardt

jancborchardt Oct 29, 2012

Member

Yeah, I’m just saying we need to be aware of it. Because in the free
software community we have this discussion on encryption all the time. But
we have to see that it’s really hard and it will lead to problems if we
don’t do it right. And to data loss, which is simply not acceptable.

On Mon, Oct 29, 2012 at 8:38 AM, Wikinaut notifications@github.com wrote:

The issue of "if you lose your password, your files are gone" is a
no-issue and valid for everyone, everywhere.

How is it a non-issue if you lose your files? Also, it’s valid for almost
no one, as most web service allows you to reset your password somehow. It’s
only a problem if you lose the encryption key (if your files are encrypted
with your password).

Member

jancborchardt commented Oct 29, 2012

Yeah, I’m just saying we need to be aware of it. Because in the free
software community we have this discussion on encryption all the time. But
we have to see that it’s really hard and it will lead to problems if we
don’t do it right. And to data loss, which is simply not acceptable.

On Mon, Oct 29, 2012 at 8:38 AM, Wikinaut notifications@github.com wrote:

The issue of "if you lose your password, your files are gone" is a
no-issue and valid for everyone, everywhere.

How is it a non-issue if you lose your files? Also, it’s valid for almost
no one, as most web service allows you to reset your password somehow. It’s
only a problem if you lose the encryption key (if your files are encrypted
with your password).

@BernhardPosselt

This comment has been minimized.

Show comment
Hide comment
@BernhardPosselt

BernhardPosselt Oct 29, 2012

Contributor

This will be hard to do without problems. We are currently trying to get dependency injection going so we can create unittests more easily, so this will very likely be taking a long time to implement. But I like the idea and i think i get the usecase.

But maybe talk to Sam Tuke, he's the guy in charge of the encryption app.

Contributor

BernhardPosselt commented Oct 29, 2012

This will be hard to do without problems. We are currently trying to get dependency injection going so we can create unittests more easily, so this will very likely be taking a long time to implement. But I like the idea and i think i get the usecase.

But maybe talk to Sam Tuke, he's the guy in charge of the encryption app.

@schiessle

This comment has been minimized.

Show comment
Hide comment
@schiessle

schiessle Oct 30, 2012

Member

@samtuke and I are working on a new encryption system at the moment. It will be based on openssl to avoid any additional dependencies and will provide server- and client-side encryption without loosing other features like file sharing.

@Wikinaut thanks for your detailed description of OpenPGP JS. It is always good to know about alternatives. But if you don't mind I would like to close the issue since we are already working on it, even if we decided to use something different.

Member

schiessle commented Oct 30, 2012

@samtuke and I are working on a new encryption system at the moment. It will be based on openssl to avoid any additional dependencies and will provide server- and client-side encryption without loosing other features like file sharing.

@Wikinaut thanks for your detailed description of OpenPGP JS. It is always good to know about alternatives. But if you don't mind I would like to close the issue since we are already working on it, even if we decided to use something different.

@Wikinaut

This comment has been minimized.

Show comment
Hide comment
@Wikinaut

Wikinaut Oct 30, 2012

Contributor

@samtuke and @schiesbn I agree to close this enhancement "bug". Please keep me informed about progress of your client-side projects, and let me participate in user interface tests.

Contributor

Wikinaut commented Oct 30, 2012

@samtuke and @schiesbn I agree to close this enhancement "bug". Please keep me informed about progress of your client-side projects, and let me participate in user interface tests.

@Wikinaut Wikinaut closed this Oct 30, 2012

@Wikinaut

This comment has been minimized.

Show comment
Hide comment
@Wikinaut

Wikinaut Oct 30, 2012

Contributor

added http://forum.owncloud.org/viewtopic.php?f=4&t=2184#p4079

citation from there:

To protect against the vulnerabilities and attack vectors you describe in your response, client-side encryption is a solution. I used to work for Amazon Web Services; I would often recommend client-side encryption to customers who were concerned about confidentiality. I would recommend that customers retain possession of keys or escrow them with an unrelated third party. When an application needs to perform some work, it should request the keys (over a secure channel) and retain them only in memory for only so long as necessary to do the work.

You might be interested in something called homomorphic encryption, an area of research that is exploring ways to perform work on encrypted information without decrypting it first.

Contributor

Wikinaut commented Oct 30, 2012

added http://forum.owncloud.org/viewtopic.php?f=4&t=2184#p4079

citation from there:

To protect against the vulnerabilities and attack vectors you describe in your response, client-side encryption is a solution. I used to work for Amazon Web Services; I would often recommend client-side encryption to customers who were concerned about confidentiality. I would recommend that customers retain possession of keys or escrow them with an unrelated third party. When an application needs to perform some work, it should request the keys (over a secure channel) and retain them only in memory for only so long as necessary to do the work.

You might be interested in something called homomorphic encryption, an area of research that is exploring ways to perform work on encrypted information without decrypting it first.

@Wikinaut

This comment has been minimized.

Show comment
Hide comment
@Wikinaut

Wikinaut Nov 4, 2012

Contributor

addition:

see also https://www.boxcryptor.com - it's a partial solution of my proposal. Partial, because it does not run in the browser.

You want to encrypt Dropbox, Google Drive or Microsoft SkyDrive and access your data from everywhere without worrying about data security or give up comfort? Then BoxCryptor is the perfect software for you. It has never been easier and more user-friendly to encrypt your data without losing the advantages of cloud storage.

You want to store highly sensitive files in the cloud? Your contracts, your bank details or your dissertation? BoxCryptor uses the AES-256 standard to encrypt and protect your files. AES-256 is classified by the U.S. Government to protect “TOP SECRET” information. In the Unlimited versions you can add an additional security layer by encrypting filenames.

Read also http://www.howtogeek.com/67074/how-to-encrypt-your-cloud-based-drive-with-boxcryptor/ (Loss of security of your saved data when password for your cloud account has leaked)

Contributor

Wikinaut commented Nov 4, 2012

addition:

see also https://www.boxcryptor.com - it's a partial solution of my proposal. Partial, because it does not run in the browser.

You want to encrypt Dropbox, Google Drive or Microsoft SkyDrive and access your data from everywhere without worrying about data security or give up comfort? Then BoxCryptor is the perfect software for you. It has never been easier and more user-friendly to encrypt your data without losing the advantages of cloud storage.

You want to store highly sensitive files in the cloud? Your contracts, your bank details or your dissertation? BoxCryptor uses the AES-256 standard to encrypt and protect your files. AES-256 is classified by the U.S. Government to protect “TOP SECRET” information. In the Unlimited versions you can add an additional security layer by encrypting filenames.

Read also http://www.howtogeek.com/67074/how-to-encrypt-your-cloud-based-drive-with-boxcryptor/ (Loss of security of your saved data when password for your cloud account has leaked)

@Wikinaut Wikinaut referenced this issue Nov 7, 2012

Open

Encryption #1140

@Wikinaut

This comment has been minimized.

Show comment
Hide comment
@Wikinaut

Wikinaut Nov 10, 2012

Contributor

not fully related to client-side encryption but touching security aspects which are relevant for ownCloud in some aspects, too:

Forensic dropbox documentation and links in article

Contributor

Wikinaut commented Nov 10, 2012

not fully related to client-side encryption but touching security aspects which are relevant for ownCloud in some aspects, too:

Forensic dropbox documentation and links in article

@samtuke

This comment has been minimized.

Show comment
Hide comment
@samtuke

samtuke Nov 20, 2012

Contributor

@Wikinaut it looks like the client side encryption will be release after the server side version, I'm not sure when. You might be interested in this person's explanation of why client side encryption in the browser is not secure: http://secushare.org/end2end

This boils down to "A web browser just isn't suited for 100% private communications as it is built to do what the web server tells it to. "

Contributor

samtuke commented Nov 20, 2012

@Wikinaut it looks like the client side encryption will be release after the server side version, I'm not sure when. You might be interested in this person's explanation of why client side encryption in the browser is not secure: http://secushare.org/end2end

This boils down to "A web browser just isn't suited for 100% private communications as it is built to do what the web server tells it to. "

@Wikinaut

This comment has been minimized.

Show comment
Hide comment
@Wikinaut

Wikinaut Nov 21, 2012

Contributor

@samtuke : when you have the javascript code locally and trust the code, it's as safe as a local installation of e.g. GnuPG.exe and when you load the encryption libraries from your own ownCloud server which you control, it's also safe.

Contributor

Wikinaut commented Nov 21, 2012

@samtuke : when you have the javascript code locally and trust the code, it's as safe as a local installation of e.g. GnuPG.exe and when you load the encryption libraries from your own ownCloud server which you control, it's also safe.

@samtuke

This comment has been minimized.

Show comment
Hide comment
@samtuke

samtuke Nov 27, 2012

Contributor

@Wikinaut How would the user get the JS onto their local machine if not via their web browser? I agree that if the user is also the ownCloud server admin then they could trust the JS received from that server, but people in that situation constitute a small use case. Most ownCloud users access a server administrated by somebody else and would find it difficult to authenticate the JS they receive in my view.

Contributor

samtuke commented Nov 27, 2012

@Wikinaut How would the user get the JS onto their local machine if not via their web browser? I agree that if the user is also the ownCloud server admin then they could trust the JS received from that server, but people in that situation constitute a small use case. Most ownCloud users access a server administrated by somebody else and would find it difficult to authenticate the JS they receive in my view.

@LukasReschke

This comment has been minimized.

Show comment
Hide comment
@LukasReschke

LukasReschke Nov 27, 2012

Member

How would the user get the JS onto their local machine if not via their web browser?

For example shipped as an extension

Member

LukasReschke commented Nov 27, 2012

How would the user get the JS onto their local machine if not via their web browser?

For example shipped as an extension

@Wikinaut

This comment has been minimized.

Show comment
Hide comment
@Wikinaut

Wikinaut Nov 27, 2012

Contributor

How would the user get the JS onto their local machine if not via their web browser?

  • from read-only CD/DVD .....
  • from a secured, peer-reviewed, open source repository like github
<!-- just as an example -->

<script src="https://raw.github.com/Wikinaut/fdiff/master/fdiff.js"></script>

This works: to pull in Javascript directly from a github repo. You may like the idea or not.
Yes, I also read this http://rdist.root.org/2010/11/29/final-post-on-javascript-crypto/

Contributor

Wikinaut commented Nov 27, 2012

How would the user get the JS onto their local machine if not via their web browser?

  • from read-only CD/DVD .....
  • from a secured, peer-reviewed, open source repository like github
<!-- just as an example -->

<script src="https://raw.github.com/Wikinaut/fdiff/master/fdiff.js"></script>

This works: to pull in Javascript directly from a github repo. You may like the idea or not.
Yes, I also read this http://rdist.root.org/2010/11/29/final-post-on-javascript-crypto/

@butonic

This comment has been minimized.

Show comment
Hide comment
@butonic

butonic Dec 6, 2012

Member

@schiesbn can you provide more details on the planned implementation? Or can you point me to a branch?

Member

butonic commented Dec 6, 2012

@schiesbn can you provide more details on the planned implementation? Or can you point me to a branch?

@schiessle

This comment has been minimized.

Show comment
Hide comment
@schiessle

schiessle Dec 6, 2012

Member

@butonic Be have a branch files_encryption both in core and mirall.

the idea is quite simple:

  • all files are encrypted by a symmetric key
  • users have a asymmetric RSA key (similar to GnuPG)
  • the public keys and the private keys are stored on the server
  • the symmetric file-key gets encrypted with all public keys from users which should have access to the given file

The differences between client and server side encryption:

server side encryption:

  • key gets generated on the server
  • password of the private key is the same as the account password so that the server can encrypt the files

client side:

  • keys are generated on the client
  • user can choose an arbitrary (strong) password for his private key so that only the user at the client can encrypt his files
Member

schiessle commented Dec 6, 2012

@butonic Be have a branch files_encryption both in core and mirall.

the idea is quite simple:

  • all files are encrypted by a symmetric key
  • users have a asymmetric RSA key (similar to GnuPG)
  • the public keys and the private keys are stored on the server
  • the symmetric file-key gets encrypted with all public keys from users which should have access to the given file

The differences between client and server side encryption:

server side encryption:

  • key gets generated on the server
  • password of the private key is the same as the account password so that the server can encrypt the files

client side:

  • keys are generated on the client
  • user can choose an arbitrary (strong) password for his private key so that only the user at the client can encrypt his files
@Wikinaut

This comment has been minimized.

Show comment
Hide comment
@Wikinaut

Wikinaut Dec 6, 2012

Contributor

@butonic wrote under point 3

the public keys and the private keys are stored on the server

"private keys stored on the server" are usually a "no go". But let me ask for what purpose (other than to apply a signature) do we need private keys on the server ?

Contributor

Wikinaut commented Dec 6, 2012

@butonic wrote under point 3

the public keys and the private keys are stored on the server

"private keys stored on the server" are usually a "no go". But let me ask for what purpose (other than to apply a signature) do we need private keys on the server ?

@schiessle

This comment has been minimized.

Show comment
Hide comment
@schiessle

schiessle Dec 6, 2012

Member

@Wikinaut You need the key on the server to easily transfer it to other devices. Let's say you set up client side encryption on your mobile phone and don't upload the keys to the server. Afterwards you want to access your files with your laptop, personal computer, tablet,... Somehow the key needs to be able to move between this devices in a user friendly way.

Regarding security. There were some security experts involved when we made this decision. Their opinion was, that this is not a problem as long as the user uses a strong pass phrase. But I was not involved in this part of the planing. If necessary, @karlitschek can say more about it.

Member

schiessle commented Dec 6, 2012

@Wikinaut You need the key on the server to easily transfer it to other devices. Let's say you set up client side encryption on your mobile phone and don't upload the keys to the server. Afterwards you want to access your files with your laptop, personal computer, tablet,... Somehow the key needs to be able to move between this devices in a user friendly way.

Regarding security. There were some security experts involved when we made this decision. Their opinion was, that this is not a problem as long as the user uses a strong pass phrase. But I was not involved in this part of the planing. If necessary, @karlitschek can say more about it.

@Wikinaut

This comment has been minimized.

Show comment
Hide comment
@Wikinaut

Wikinaut Dec 6, 2012

Contributor

@schiesbn wrote

You need the key on the server to easily transfer it to other devices. Let's say you set up client side encryption on your mobile phone and don't upload the keys to the server. Afterwards you want to access your files with your laptop, personal computer, tablet,..

You can avoid storing the users' private keys on the server. It's a "no go".

You only only need to

encrypt also to the file owner

  • encrypt the files you want to have on your other devices also to yourself
  • using your public key stored on the server.

Decrypt such files as any other user on your local device.
This common practice for mails etc. I do not see the (dangerous) need to store the users private key on the server.

Contributor

Wikinaut commented Dec 6, 2012

@schiesbn wrote

You need the key on the server to easily transfer it to other devices. Let's say you set up client side encryption on your mobile phone and don't upload the keys to the server. Afterwards you want to access your files with your laptop, personal computer, tablet,..

You can avoid storing the users' private keys on the server. It's a "no go".

You only only need to

encrypt also to the file owner

  • encrypt the files you want to have on your other devices also to yourself
  • using your public key stored on the server.

Decrypt such files as any other user on your local device.
This common practice for mails etc. I do not see the (dangerous) need to store the users private key on the server.

@Wikinaut

This comment has been minimized.

Show comment
Hide comment
@Wikinaut

Wikinaut Dec 6, 2012

Contributor

I am pretty much against storing any private key on the server, but will leave a final decision to the security auditors.

And storing of private keys on servers can be avoided in most cases by using key agents such as "Pageant".

Contributor

Wikinaut commented Dec 6, 2012

I am pretty much against storing any private key on the server, but will leave a final decision to the security auditors.

And storing of private keys on servers can be avoided in most cases by using key agents such as "Pageant".

@schiessle

This comment has been minimized.

Show comment
Hide comment
@schiessle

schiessle Dec 6, 2012

Member

@Wikinaut but to decrypt your files you need the private key on all devices. A key agent doesn't solve the problem that you need to be able to move the private key between many different devices.

Member

schiessle commented Dec 6, 2012

@Wikinaut but to decrypt your files you need the private key on all devices. A key agent doesn't solve the problem that you need to be able to move the private key between many different devices.

@Wikinaut

This comment has been minimized.

Show comment
Hide comment
@Wikinaut

Wikinaut Dec 6, 2012

Contributor

@schiesbn wrote

but to decrypt your files you need the private key on all devices.

Yes, of course. But everyone can deploy this key using a second "channel" - by encrypted mail for example, by encrypted zip file or by USB-cable or the like,, and the transmission is only required one time per device (if you store the private key on the device, for example like APG does).

I am only saying, that storing on a server is a "no go". I am not alone with this view.

Please correct me, if I am wrong with my view, or my proposal to also encrypt to the file owner.

Contributor

Wikinaut commented Dec 6, 2012

@schiesbn wrote

but to decrypt your files you need the private key on all devices.

Yes, of course. But everyone can deploy this key using a second "channel" - by encrypted mail for example, by encrypted zip file or by USB-cable or the like,, and the transmission is only required one time per device (if you store the private key on the device, for example like APG does).

I am only saying, that storing on a server is a "no go". I am not alone with this view.

Please correct me, if I am wrong with my view, or my proposal to also encrypt to the file owner.

@Wikinaut

This comment has been minimized.

Show comment
Hide comment
@Wikinaut

Wikinaut Dec 10, 2012

Contributor

UPDATE 20121210

[4] http://www.mailvelope.com/ Mailvelope is a browser extension that allows to exchange encrypted emails following the OpenPGP encryption standard.
[5] https://github.com/toberndo/mailvelope

Contributor

Wikinaut commented Dec 10, 2012

UPDATE 20121210

[4] http://www.mailvelope.com/ Mailvelope is a browser extension that allows to exchange encrypted emails following the OpenPGP encryption standard.
[5] https://github.com/toberndo/mailvelope

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Dec 17, 2012

+1 for @Wikinaut ideas and implementation
Using a browser extension could verify the js to de/encrypt stuff
All files would really be encrypted
Public sharing could be assumed to not use encrypted files or have the decryption key in the url... (one time key for each file, not sure if applicable)

ghost commented Dec 17, 2012

+1 for @Wikinaut ideas and implementation
Using a browser extension could verify the js to de/encrypt stuff
All files would really be encrypted
Public sharing could be assumed to not use encrypted files or have the decryption key in the url... (one time key for each file, not sure if applicable)

@Wikinaut

This comment has been minimized.

Show comment
Hide comment
@Wikinaut

Wikinaut Dec 17, 2012

Contributor

@seetheprogress wrote:

Public sharing could be assumed to not use encrypted files or have the decryption key in the url... (one time key for each file, not sure if applicable)

These concepts ( decryption key in the url after #hash part ) are described here http://sebsauvage.net/wiki/doku.php?id=php:zerobin

The decryption key is in the anchor part of the URL (#…) which is never sent to server.

code see https://github.com/sebsauvage/ZeroBin

<img src=http://sebsauvage.net/wiki/lib/exe/fetch.php?media=php:zerobin:zerobin_figure_encryption.png>

Contributor

Wikinaut commented Dec 17, 2012

@seetheprogress wrote:

Public sharing could be assumed to not use encrypted files or have the decryption key in the url... (one time key for each file, not sure if applicable)

These concepts ( decryption key in the url after #hash part ) are described here http://sebsauvage.net/wiki/doku.php?id=php:zerobin

The decryption key is in the anchor part of the URL (#…) which is never sent to server.

code see https://github.com/sebsauvage/ZeroBin

<img src=http://sebsauvage.net/wiki/lib/exe/fetch.php?media=php:zerobin:zerobin_figure_encryption.png>

@Wikinaut

This comment has been minimized.

Show comment
Hide comment
@Wikinaut

Wikinaut Jan 2, 2013

Contributor

[updated 2013-01-02][reopened, because the issue of "encrypting everything" (i.e. end-to-end) is still "hot"]

Deutsche Post AG end-to-end AES-256 encryption for documents

Citation from http://www.dp-dhl.com/en/media_relations/press_releases/2012/docwallet_documents_manager_for_the_ipad.html Deutsche Post's technical lead for DocWallet says:

"Our security concept responds to the troubling development today that central servers are increasingly the target of hacker attacks," ... "This is why DocWallet only transfers and saves encrypted documents."

Contributor

Wikinaut commented Jan 2, 2013

[updated 2013-01-02][reopened, because the issue of "encrypting everything" (i.e. end-to-end) is still "hot"]

Deutsche Post AG end-to-end AES-256 encryption for documents

Citation from http://www.dp-dhl.com/en/media_relations/press_releases/2012/docwallet_documents_manager_for_the_ipad.html Deutsche Post's technical lead for DocWallet says:

"Our security concept responds to the troubling development today that central servers are increasingly the target of hacker attacks," ... "This is why DocWallet only transfers and saves encrypted documents."

@Wikinaut Wikinaut reopened this Jan 2, 2013

@orion1024

This comment has been minimized.

Show comment
Hide comment
@orion1024

orion1024 Feb 28, 2015

Hello,

an update on things.
As I finished the first document describing intents and features, I moved on to the design of the crypto system.
As of now, it is far from finished, but I think it is at a point where someone that wants to contribute ideas/remarks has enough material to get a good idea of where I'm headed.

Here is the document (remember : this is ongoing work !) :
https://cloud.airmail.fr/public.php?service=files&t=d475f3c9d77e99d8b413977729be5f0e

And the first document with intents and features (needs some updates with the release of ownCloud 8). Still open for review of course :
https://cloud.airmail.fr/public.php?service=files&t=a9fe1a55a59374dd6bc399f4ff4d60db

Frank/jos : thanks for the support :)

orion1024 commented Feb 28, 2015

Hello,

an update on things.
As I finished the first document describing intents and features, I moved on to the design of the crypto system.
As of now, it is far from finished, but I think it is at a point where someone that wants to contribute ideas/remarks has enough material to get a good idea of where I'm headed.

Here is the document (remember : this is ongoing work !) :
https://cloud.airmail.fr/public.php?service=files&t=d475f3c9d77e99d8b413977729be5f0e

And the first document with intents and features (needs some updates with the release of ownCloud 8). Still open for review of course :
https://cloud.airmail.fr/public.php?service=files&t=a9fe1a55a59374dd6bc399f4ff4d60db

Frank/jos : thanks for the support :)

@PVince81 PVince81 referenced this issue Mar 4, 2015

Closed

encryption 2.0 - early stage #14376

0 of 1 task complete
@jospoortvliet

This comment has been minimized.

Show comment
Hide comment
@jospoortvliet

jospoortvliet Mar 5, 2015

@LukasReschke I bet you want to have a look ;-)

jospoortvliet commented Mar 5, 2015

@LukasReschke I bet you want to have a look ;-)

@jancborchardt jancborchardt modified the milestones: Maybe someday, backlog Mar 23, 2015

@orion1024

This comment has been minimized.

Show comment
Hide comment
@orion1024

orion1024 Apr 5, 2015

Hello,

a new update. First, I dubbed the "ownCloud client-side encryption" feature as ownCrypt, for brievity sake. This will do at least as a temporary name.

The encrypted storage system (at least the core of it) is stabilized as far as I am concerned, so I switched to making a graph that explains more visually how the system works.
The text document grew a bit too difficult to my taste and I thought a graph would help other people to understand it more easily.

You can get the current graph here. Use yED to read it (free software).
Here is the PDF if you want a quick look at it without needing yED.

What's next :

  • putting more use cases in graph
  • most importantly, I will begin seeking out feedback and advice from others on the cryptographic strength and scalability of the current design before I build further on the current design. As I don't have any prior experience in crypto engineering I need more confidence in the foundation of the cryptosystem.
  • begin work on other aspects of the cryptosystem that are not directly dependant on how the files are stored : key exchange, key management, for instance. Key exchange particularly is a big and interesting topic.
  • integration with ownCloud current capabilities (for instance, the new sharing API coming in OC 8.1 will be instrumental for ownCrypt).

@schiesbn
@Raydiation

I am very interested in your opinion on the current state of the design. Even more so if, according to your knowledge of the current server and client code/roadmap, you think that some of my design intents might conflict with yours, or simply not mesh well together.

orion1024 commented Apr 5, 2015

Hello,

a new update. First, I dubbed the "ownCloud client-side encryption" feature as ownCrypt, for brievity sake. This will do at least as a temporary name.

The encrypted storage system (at least the core of it) is stabilized as far as I am concerned, so I switched to making a graph that explains more visually how the system works.
The text document grew a bit too difficult to my taste and I thought a graph would help other people to understand it more easily.

You can get the current graph here. Use yED to read it (free software).
Here is the PDF if you want a quick look at it without needing yED.

What's next :

  • putting more use cases in graph
  • most importantly, I will begin seeking out feedback and advice from others on the cryptographic strength and scalability of the current design before I build further on the current design. As I don't have any prior experience in crypto engineering I need more confidence in the foundation of the cryptosystem.
  • begin work on other aspects of the cryptosystem that are not directly dependant on how the files are stored : key exchange, key management, for instance. Key exchange particularly is a big and interesting topic.
  • integration with ownCloud current capabilities (for instance, the new sharing API coming in OC 8.1 will be instrumental for ownCrypt).

@schiesbn
@Raydiation

I am very interested in your opinion on the current state of the design. Even more so if, according to your knowledge of the current server and client code/roadmap, you think that some of my design intents might conflict with yours, or simply not mesh well together.

@jospoortvliet

This comment has been minimized.

Show comment
Hide comment
@jospoortvliet

This comment has been minimized.

Show comment
Hide comment
@orion1024

This comment has been minimized.

Show comment
Hide comment
@orion1024

orion1024 Nov 23, 2015

Thanks for the links and the work on the videos Jos !

Right now I'm busy studying the client code and how to best integrate ownCrypt into it, since ownCrypt will need to run deep in the sync logic and we want to avoid my code getting in the way of regular development.
Once I get a good grasp on this I will start working with the desktop guys to get their opinion/approval on my plans.

In parallel, there is also ongoing work with a French university in order to get more people involved in the project, especially people knowledgeable in cryptography. Nothing confirmed yet, hence my silence, but I'm hopeful.
Stay tuned...

orion1024 commented Nov 23, 2015

Thanks for the links and the work on the videos Jos !

Right now I'm busy studying the client code and how to best integrate ownCrypt into it, since ownCrypt will need to run deep in the sync logic and we want to avoid my code getting in the way of regular development.
Once I get a good grasp on this I will start working with the desktop guys to get their opinion/approval on my plans.

In parallel, there is also ongoing work with a French university in order to get more people involved in the project, especially people knowledgeable in cryptography. Nothing confirmed yet, hence my silence, but I'm hopeful.
Stay tuned...

@jospoortvliet

This comment has been minimized.

Show comment
Hide comment
@jospoortvliet

jospoortvliet Dec 13, 2015

/me just occasionally likes to kick @orion1024 to get some status info 😇

jospoortvliet commented Dec 13, 2015

/me just occasionally likes to kick @orion1024 to get some status info 😇

@orion1024

This comment has been minimized.

Show comment
Hide comment
@orion1024

orion1024 Dec 13, 2015

We said no kicks :)

I've been at nearly full throttle for the past month, so if everything goes as planned you will hear from me around new Eve.
Fingers crossed !

orion1024 commented Dec 13, 2015

We said no kicks :)

I've been at nearly full throttle for the past month, so if everything goes as planned you will hear from me around new Eve.
Fingers crossed !

@orion1024

This comment has been minimized.

Show comment
Hide comment
@orion1024

orion1024 Dec 30, 2015

Here is the promised update.

I created a new issue in the client repository to kick off the ownCrypt integration discussion.
First step is to agree with the client team how the integration should happen codewise, and then off we code.

I will keep posting updates here but most of the technical discussion will now take place at the new issue.

orion1024 commented Dec 30, 2015

Here is the promised update.

I created a new issue in the client repository to kick off the ownCrypt integration discussion.
First step is to agree with the client team how the integration should happen codewise, and then off we code.

I will keep posting updates here but most of the technical discussion will now take place at the new issue.

@jospoortvliet

This comment has been minimized.

Show comment
Hide comment
@jospoortvliet

jospoortvliet Dec 31, 2015

Awesome! Let's see what people say. I guess you'll have to wait a bit until they're all back on the job, though...

jospoortvliet commented Dec 31, 2015

Awesome! Let's see what people say. I guess you'll have to wait a bit until they're all back on the job, though...

@tflidd

This comment has been minimized.

Show comment
Hide comment
@tflidd

tflidd Mar 14, 2016

Contributor

There is a new client-side transparent encryption solution (open source): https://cryptomator.org/
It should be possible to use this on top of owncloud.

Contributor

tflidd commented Mar 14, 2016

There is a new client-side transparent encryption solution (open source): https://cryptomator.org/
It should be possible to use this on top of owncloud.

@fpietrosanti

This comment has been minimized.

Show comment
Hide comment
@fpietrosanti

fpietrosanti Apr 16, 2016

OpenPGP.js as per 13 Feb 2015, do support entire operation via native WebCrypto API https://github.com/openpgpjs/openpgpjs/releases/tag/v2.0.0 .

fpietrosanti commented Apr 16, 2016

OpenPGP.js as per 13 Feb 2015, do support entire operation via native WebCrypto API https://github.com/openpgpjs/openpgpjs/releases/tag/v2.0.0 .

@JonasDralle

This comment has been minimized.

Show comment
Hide comment
@JonasDralle

JonasDralle May 8, 2016

+1
this would be awesome

JonasDralle commented May 8, 2016

+1
this would be awesome

@xlyz

This comment has been minimized.

Show comment
Hide comment
@xlyz

xlyz commented May 22, 2016

+1

@Ardakilic

This comment has been minimized.

Show comment
Hide comment
@Ardakilic

Ardakilic Jun 19, 2016

+1 for this, too.

Ardakilic commented Jun 19, 2016

+1 for this, too.

@DeepDiver1975 DeepDiver1975 changed the title from Enhancement/design idea: encrypt everything: client-side end-to-end encryption using OpenPGP JavaScript implementation, not requiring additional software to be installed to Enhancement/design idea: encrypt everything: client-side end-to-end encryption using OpenPGP JavaScript implementation, not requiring additional software to be installed [$25] Feb 7, 2017

@DeepDiver1975 DeepDiver1975 added the bounty label Feb 7, 2017

@Hamsterman

This comment has been minimized.

Show comment
Hide comment
@Hamsterman

Hamsterman commented Mar 29, 2017

+1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment