21–30 of 37 posts
[1] https://tresorit.com/features
[2] https://tresorit.com/files/encrypted-link-whitepaper.pdf
As others have point out this just means you have to trust Sharelock. While its slightly less user friendly, and it has its own security issues would the following be viable: 1) Sender clicks 'share a file' and no file is uploaded yet. 2) Email is sent to recipient, explaining that they have an encrypted file waiting for them, and takes them through creating a public key done in their browser via JavaScript (biggest…
You are right in your observation that the exchange of secrets through Sharelock.io is only secure if you trust the integrity of the service and the people behind it. To mitigate this concern we offer Sharelock as an open source project on GitHub, which allows anyone to create their own island of trust by hosting an instance and controlling cryptographic keys. There are many ways to organize a secure exchange of secr…
Earlier quoted context omitted.
You are right in your observation that the exchange of secrets through Sharelock.io is only secure if you trust the integrity of the service and the people behind it. To mitigate this concern we offer Sharelock as an open source project on GitHub, which allows anyone to create their own island of trust by hosting an instance and controlling cryptographic keys. There are many ways to organize a secure exchange of secr…
Then how is your service any more secure than any file upload service with ssl? It just seems misleading, whats the point of a safe when the key is glued to the door. An encryption service that requires people trust its owners just isnt secure. You could be perfect with the utmost of integrity even under insurmountable legal pressure, but even then, if your system has a way of knowing the keys its leaving the door op…
Having said that, exposure of the user of sharelock.io can be argued to be lower than in case of a service which durably stores user's data. While sharelock.io keeps the cryptographic credentials, it does not durably store users' secrets or ciphertext.
Earlier quoted context omitted.
Then how is your service any more secure than any file upload service with ssl? It just seems misleading, whats the point of a safe when the key is glued to the door. An encryption service that requires people trust its owners just isnt secure. You could be perfect with the utmost of integrity even under insurmountable legal pressure, but even then, if your system has a way of knowing the keys its leaving the door op…
We aspired to create a service that is similarly secure to a file upload service with SSL, but more usable at the same time by not tying the user to a partcular data exchange mechanism (you can sent the sharelock URL via e-mail, Tweet it, or publish in a New York Times). Having said that, exposure of the user of sharelock.io can be argued to be lower than in case of a service which durably stores user's data. While s…
If it's text only, there's also zerobin ( http://sebsauvage.net/wiki/doku.php?id=php:zerobin ) that has a lot of features and the added bonus of not storing the key on the server (it's using the anchor part)
Source with demo: https://github.com/alfg/jot
What is Sharelock adding here other than a false sense of security? Are we supposed to trust Sharelock more than the aforementioned services?
Earlier quoted context omitted.
Regarding the access logs angle, the image shown on the front page shows a URL that starts with " https://sharelock.io/1/cuwcRv64IR5ivYP..." . Presumably that garbage text is the start of the secret. It would probably be a really good idea to move the secret into the fragment of the URL instead. Fragments aren't sent to servers, so they can't possibly show up in access logs. But the client can still access the fragme…
The decryption happens server-side - the server is the sole holder of encryption keys. Besides, it is the server that generated that ciphertext in the first place, so it already had access to the secret at that point.
If it's happening server-side then it seems like this is only appropriate to use when you're hosting your own instance. Using anybody else's instance (for anything that actually needs to be encrypted) means handing your plaintext to the server operator.
As others have point out this just means you have to trust Sharelock. While its slightly less user friendly, and it has its own security issues would the following be viable: 1) Sender clicks 'share a file' and no file is uploaded yet. 2) Email is sent to recipient, explaining that they have an encrypted file waiting for them, and takes them through creating a public key done in their browser via JavaScript (biggest…
Works almost exactly as you said, although you quickly run into problems with how much data you can store in javascript before the page blows up.