It's not particularly useful here since if someone got access to your remote encrypted file and knew it was made with sdees, the pepper is public. However if the value was configurable by the user then it could provide an extra layer of protection against someone brute forcing the hash and getting your password.
A better approach would be to not store a hash of the password at all. The author uses it to check that the user supplied the correct password when attempting decryption - instead you can decrypt the file using whatever password the user provides (getting either correct or garbage output back), and check for a magic value in the output.
I was excited for a moment. Then found out neovim doesn't support -x. And this is why: https://github.com/neovim/neovim/issues/694 (tldr; vim encryption is unsecure and thus removed from neovim for the time being). Would have been nice, though.
Server-less is the new paradigm where the server is in the cloud. More specifically, you're not maintaining any server, you just supply callbacks written in the language of your choice, and the infrastructure figures out how to package them in containers, deploy, run, scale and dispose when no longer needed.
Can you explain what you mean with "server is in the cloud", is it like literal placing a fog machine to make some kind of cloud around your servers or placing a server inside another server, such as a raspberry pi within a PC box?
It is, but taken literally and not helpful in infrastructure discussions.
"Serverless service" as recently coined means you're not concerned with the server layer. Either the hardware one, or the "http request server" one. What you provide is functions that execute on some action. As long as the API is preserved it doesn't matter if it's one server of one/multiple providers, cloud deployment, room filled with monkeys at keyboards, linux running unicorn, windows running iis, or anything else.
It's one level above "set up your services and upload code for specific server" PAAS. And two or so levels above "set up your own servers and services" IAAS.
PS. I don't think sdees matches the definition of serverless as it's commonly understood.
> Ah I see, so serverless service is a way to say "I am so high up higher than your puny little cloud down there".
I don't believe there's any judgement in "serverless service". Depending on your requirements you may want this solution or you may prefer something else. It got a name, because when you get tired of saying "model more abstract than PAAS but based on the same principles of being independent of the infrastructure" you invent a short name - servers got abstracted, so it's "serverless".
> its just funny how our industry invents new words every year or so, it gets hard to keep uptodate.
The industry doesn't invent words. It invents new solutions. If they get popular they get names, so it's easier to communicate. That's how every industry works.
I call it "serverless" in the sense that it doesn't require any server-side code. The "decentralized" is because it also doesn't require stable internet connections to work properly - you can edit on multiple computers simultaneously with or without internet and the edits can still all be merged correctly when they finally sync up.
Sorry to confuse folks! The original acronym actually just meant "sync down, decrypt, edit, encrypt, sync up" which is maybe less ambiguous of a description.
I think I agree with you, but I'll just clarify my naive thinking.
Most synchronization tools (Owncloud, Synthing, Dropbox) perform similar functionality but they require server-side code of some sort. So compared to these, in my mind, sdees is "severless" (but also sdees has a tiny fraction of the actual functionality of those awesome programs).
Decentralized as defined by Rhoit Khare [1] is a system where multiple parties make individual decisions which may conflict. This, to me, is the scenario that occurs when two people edit the same document offline, but may want to merge later via a remote host. However, maybe a better term is "distributed" because in a lot of ways its similar to git, which is considered so [2], also then I can still use the same acronym :)
As much as it pains me to say it, that ship sailed around the time AWS Lambda was announced. "Serverless" now means "a server you don't need to think about".
Friend of mine is working on Cryptpad [1] which is encrypted collaborative web editor. There are multiple connection modes, most common websockets relay server but he is also working on WebRTC transport.
Everything is modular so you can create encrypted applications as you see fit by changing transport, storage, crypto and frontend.See for example [3].
In case of using a relay server the content is encrypted so the server doesn't know what the content is.
Thanks for sharing this. I had an old hackathon project that seemed cool but didn't really have a good application (essentially, end-to-end encrypted Socket.IO implemented on top of Keybase filesystem: https://github.com/lgessler/kbrpc). Maybe I'll try to get it to work with Cryptpad.
Why not use GPG directly? I get the wish to not add more binary dependencies, but the recent couple of issues with Go's math and crypto libraries doesn't fill me with confidence. Not to mention that there's no real benefit to adding your own wrappers around the crypto primitives when GPG already exists.
Initially I did. However, I tend to use lots of Windows computers, so I really wanted something where I didn't have to install Cygwin+GPG+rsync each time.
The Windows release also bundles vim into the binary so you don't even have to have vim installed if you're using Windows!
I had the same need, so I created a zero-install, client-side encrypted, browser-based editor using SJCL+CodeMirror in Vim mode: https://github.com/srpeck/encryptedgist
38 comments
[ 3.4 ms ] story [ 81.1 ms ] threadCode and comments get out of sync so quickly.
Out of interest, why the static salt in addition to bcrypt?
It's not particularly useful here since if someone got access to your remote encrypted file and knew it was made with sdees, the pepper is public. However if the value was configurable by the user then it could provide an extra layer of protection against someone brute forcing the hash and getting your password.
A better approach would be to not store a hash of the password at all. The author uses it to check that the user supplied the correct password when attempting decryption - instead you can decrypt the file using whatever password the user provides (getting either correct or garbage output back), and check for a magic value in the output.
vim -x scp://.../...
Glad I found the solution with the problem.
Am I the only one around here? http://i3.kym-cdn.com/entries/icons/original/000/010/856/4fc...
What is the cloud if not other peoples servers?
It is, but taken literally and not helpful in infrastructure discussions.
"Serverless service" as recently coined means you're not concerned with the server layer. Either the hardware one, or the "http request server" one. What you provide is functions that execute on some action. As long as the API is preserved it doesn't matter if it's one server of one/multiple providers, cloud deployment, room filled with monkeys at keyboards, linux running unicorn, windows running iis, or anything else.
It's one level above "set up your services and upload code for specific server" PAAS. And two or so levels above "set up your own servers and services" IAAS.
PS. I don't think sdees matches the definition of serverless as it's commonly understood.
No offense to you personally, its just funny how our industry invents new words every year or so, it gets hard to keep uptodate.
I don't believe there's any judgement in "serverless service". Depending on your requirements you may want this solution or you may prefer something else. It got a name, because when you get tired of saying "model more abstract than PAAS but based on the same principles of being independent of the infrastructure" you invent a short name - servers got abstracted, so it's "serverless".
> its just funny how our industry invents new words every year or so, it gets hard to keep uptodate.
The industry doesn't invent words. It invents new solutions. If they get popular they get names, so it's easier to communicate. That's how every industry works.
sdees requires a file server, specifically it prompts the user for one and saves it to ~/.config/sdees/config.json, therefore it is not serverless.
Sorry to confuse folks! The original acronym actually just meant "sync down, decrypt, edit, encrypt, sync up" which is maybe less ambiguous of a description.
Now in a world without web servers, Firefox would not be very useful at all. The same with your tool.
Decentralized, its not, not requiring a stable internet connection is called working "offline".
Please avoid ambiguity.
Most synchronization tools (Owncloud, Synthing, Dropbox) perform similar functionality but they require server-side code of some sort. So compared to these, in my mind, sdees is "severless" (but also sdees has a tiny fraction of the actual functionality of those awesome programs).
Decentralized as defined by Rhoit Khare [1] is a system where multiple parties make individual decisions which may conflict. This, to me, is the scenario that occurs when two people edit the same document offline, but may want to merge later via a remote host. However, maybe a better term is "distributed" because in a lot of ways its similar to git, which is considered so [2], also then I can still use the same acronym :)
[1] http://isr.uci.edu/projects/pace/decentralization.html
[2] http://stackoverflow.com/questions/7212740/why-git-is-called...
Everything is modular so you can create encrypted applications as you see fit by changing transport, storage, crypto and frontend.See for example [3].
In case of using a relay server the content is encrypted so the server doesn't know what the content is.
The source is open on AGPL license.
---
[1]: https://beta.cryptpad.fr
[2]: https://github.com/xwiki-labs/cryptpad/
[3]: https://beta.cryptpad.fr/poll/#173f2db91c58169a22a005ebb85c2...
The Windows release also bundles vim into the binary so you don't even have to have vim installed if you're using Windows!
And thats serverless?