11 ms·
Scramble.io: secure email for everyone
- davedx 13y agoFantastic. Tighten up the user interface and this should gain traction. Checking out the Github repo now.
- woah 13y agoWorking on it! New interface should be out in the next few weeks. Check out the "frontend-makeover" branch if you are interested.
- davedx 13y agoSounds great. I'd love to contribute to something like this.
- dcposch 13y agoThanks! We're working on improving the UI. A few upcoming fixes: * Clear visual distinction between encrypted and unencrypted mail * Keep track of read vs unread mail * Allow users to enter a public key for an external (non-Scramble address) and sent encrypted mail to existing PGP users * Basic search
- special 13y agoIt prompts you if you try to send an email to someone without using their public key. I dig it. Edit: Also links you to xkcd if you pick a crappy password: http://i.imgur.com/TJ3QPP7.png http://i.imgur.com/TJ3QPP7.png
- frank_boyd 13y agoEncryption done in the browser? Why would you take that risk and not encrypt in a client using GPG?
- tptacek 13y agoAnother week, another Javascript cryptography project. See: https://news.ycombinator.com/item?id=6637915 https://news.ycombinator.com/item?id=6637915 https://news.ycombinator.com/item?id=6420739 https://news.ycombinator.com/item?id=6420739 https://news.ycombinator.com/item?id=6353137 https://news.ycombinator.com/item?id=6353137 https://news.ycombinator.com/item?id=6317685 https://news.ycombinator.com/item?id=6317685 (That's just the last few weeks). We are also developing a browser extension which will verify the Javascript loaded from the server. (Until then, an attacker who gained control of a server could tamper with the JS to steal a user's credentials the next time they log in.) Baffling. If you're going to build a browser extension, put the crypto code in the extension. This still isn't a great solution, but it's better than trying to "verify the Javascript code". How exactly do you plan to do that? Surely you realize you can't just digest the JS asset files.
- DigitalJack 13y agoI'm not a programmer. Why can't you just digest or hash the JS?
- ozh 13y agoJust curious : what does a non-programmer come to HN for? Everything seems fairly programming centric to me here...
- blakerson 13y agoNon-programmer here. I've gotten great advice on work and links to great resources that have helped me change the way I work. It's not an overstatement to say that great writers like patio11 and Zach Holman have thoroughly changed how I see work, collaboration, and how it should interface with my private life. I don't run a SaaS app (yet) and I certainly don't make open-source contributions, but the principles of their posts can apply to a lot of fields that aren't purely technical. In the last year and a half since I started regularly reading I brought a lot of great ideas to my previous employer and then changed my career for the better. tldr: Everything I've read here has given me immense clarity in how I personally view life and work, and I'm happier for it.
- lazyant 13y agohow do I create/add the public key of a contact?
- jaekwon 13y agoWe plan to add functionality soon! As well as exporting your public/private key.
- JulianMorrison 13y agoUnvetted cryptography is worth 1 cereal packet sekrit decoder ring.
- mdip 13y agoPrecisely which vetted, client side, JS crypto library would you prefer the authors use to satisfy your concerns? I haven't looked at the code, and only recently started paying attention to the JS-Crypto space. I'm aware of implementations where scrypt was compiled to target the asm.js subset, however, this doesn't really mean the resulting JS running on platform x, in browser y is as secure as the resulting binary on the platform/OS it was targeted for. Scramble has not been widely vetted, so don't rely on it to protect you just yet. The authors put the above line as part of the very first bit of marketing you encounter. Until the JS has full (vetted, industry standard) crypto functions designed to be secure for the each target platform, vetting this kind of crypto is going to be hard. The addition of a cryptographically sound PRNG is a big move in the right direction. That said, I believe the authors got it right with what is currently available: Inform the user in such a way that there is no confusion, open source the code so others can participate in vetting, get some attention to the project so others are motivated to participate in vetting, and continue to improve as problems are discovered. That's really the best you can do, IMHO. In security, the author of a library needs to be correct 100% of the time while an attacker needs to be correct only once.
- JulianMorrison 13y agoThis is like printing "may contain arsenic" on candy.
- galapago 13y agoCode: https://github.com/dcposch/scramble https://github.com/dcposch/scramble
- acoleman616 13y agoWhenever I see a site with the fixed background images and scrolling content panels (where the background image is periodically visible again), I spend more time trying to figure out what's contained in the background images through those gaps than I do reading the content.
- eCa 13y agoIt's a bright night sky: http://dcposch.github.io/scramble/img/night_sky_bright.jpg http://dcposch.github.io/scramble/img/night_sky_bright.jpg
- ihsw 13y agoNow the question is -- why doesn't Google do this with Gmail?
- zokier 13y agoTheir whole business model revolves around data mining. You can't really mine encrypted mail. If you can then the encryption is worthless.
- tptacek 13y agoBecause it would be deeply irresponsible for them to do that.
- jamiek88 13y agoWhy?
- orthecreedence 13y agoYou can't serve dynamically-loaded crypto code. What happens when someone hacks gmail and replaces crypto.aes.js with crypto.plaintext.js and suddenly every gmail user who thought they were sending encrypted mail are just sending plaintext messages? Crypto code needs to be packaged/signed/verified and cannot load in code dynamically without running the risk of completely compromising its security. This is why it's just not possible to securely serve code that does crypto in a web app. Browser extensions are the next step up, but they also have to be careful to never load code from any external locations (among other considerations they have to make when running in a browser environment).
- tejaswiy 13y agoThis would only work within gmail though. Non gmail users still will have to manually decrypt any emails they receive.
- gnidan 13y agoI'm glad to see more projects taking off with the goal of secure email. I found it really annoying that this service has xkcd style password requirements. My 9-character password with non-alphanumeric characters should be sufficient.
- tehwalrus 13y agoCool, this was the architecture I sketched in my head for a user-friendly PGP app, although I would have offered to sync the private keys between device clients, rather than doing it all in browser (that way, someone can opt out and keep a key just on their phone or whatever.) I had a damn good name, too, but good job someone else did it so I don't have to! :)
- mdip 13y agoIt's nice to see so many projects attempting to solve this problem. I have a question specific to the documentation on the main page: Private keys are stored on the server in encrypted form. The key derivation function used is as follows: K = scrypt(Passphrase, Username) I'm going to skip the "JS crypto is bad". What I'd like is clarification of the Zero Knowledge section that the keypair is decrypted client-side only and the passphrase is never transferred to the server for any reason. This is important because a state actor or other person with sufficient influence--such as a big wrench--could intercept this via code installation on whatever servers perform this work. There's still the issue of JS being modified by the same evil actor (which you mention), and I'm not sure if signing with a browser extension is much insurance (that's just replacing code that can be modified in transit/on update with other code that can be modified in transit/on update), but with so much attention being paid to this problem as of late, an adequate solution will be discovered (if it doesn't exist already).
- jmccree 13y agoEven with the brute protection provided by scrypt, it's very worrying that you can assume the encrypted private key will A) Be available to authorities via (secret) court order B) Captured and stored by NSA types. The security of the key could only be assumed to be as high as the weakest passphrase ever used by the user. With what we know about most user's password security (especially the type not already capable of using GPG, which would seem the target market of this) this seems like a very bad idea. Why go through all the trouble of attempting strong client side crypto, only to store the private key secured only by a passphrase on the server?
- jrochkind1 13y agonice. secure end-to-end encryption with a good browser-based UI is kind of a holy grail. They say it's open source, but I can't find links to the source anywhere. Anyone?
- wanda 13y agohttps://github.com/dcposch/scramble https://github.com/dcposch/scramble
- blahbl4hblahtoo 13y agoI have to disagree. I'm not sure that is the "holy grail"...i think its not even possible with common browser runtimes.
- jrochkind1 13y agoYes, I agree; the fact that it's unclear if it's possible is what makes it the holy grail, it's unclear if the holy grail actually exists, but lots of people really want it. :)
- brown9-2 13y agoUsers don't have to manage and back up their keys---or even know what a key is. Scramble does it for you. As a user, why would I want to delegate my key management to you? Encrypting the email I want to send to a person with their public key is what gives me a sense of trust that what I am sending is encrypted and only readable to that person. However--as the example of Tormail and others show us--the server cannot be trusted to serve uncompromised client-side code, even if the organization behind it is well intentioned. So then why am I trusting you with my PGP keys?
- dcposch 13y ago> As a user, why would I want to delegate my key management to you? The beauty of it is that Scramble encrypts and signs whenever the recipient is also a Scramble address--automatically. The goal is to protect even users who don't know what a "PGP key" is. (Don't get me wrong, we're planning improvements for power users as well--for example, we want to make it easy to use Scramble over Tor. But the goal really is "Encrypted email for everyone".) > So then why am I trusting you with my PGP keys? No, as explained in the writeup, the server stores your private key encrypted with your passphrase. The server never sees your passphrase, or your private key. We've used a good key derivation function (scrypt)---this makes it difficult to brute-force the password. In short: Yes, the server stores things so that you get the Gmail experience, sit down at any computer and it just works. No, the server never sees your plaintext private key. Thanks for the feedback! If I get a chance, I'll paraphrase your questions and add them to the upcoming FAQ.
- kingzero 13y ago> No, as explained in the writeup, the server stores your private key encrypted with your passphrase. The server never sees your passphrase, or your private key. The only place a private key belongs to is the users machine (preferably somewhere without internet access).
- blahbl4hblahtoo 13y agoIf you just expose your service as an API then you don't have to worry about users trusting code given to them by the site. Then use a native client app that doesn't suck to interact with the service...all of the encryption is done client side with all of the messages being encrypted end to end. JavaScript encryption just isn't really valid in browsers...the browser runtime is to blame. Its funny that people have to all learn the same lessons over and over again...it's a worthwhile goal...keep at it, just try a different approach.
- Procrastes 13y agoThat sounds much more interesting. Solving key exchange and message transport in a friendly way, then using a native client has possibilities. I think that's the direction [Hemlis](https://heml.is/ https://heml.is/) is taking.
- mdip 13y agoIts [sic] funny that people have to all learn the same lessons over and over again That pretty much defines what the field of computer security is. From DES to AES, we learned the same lesson: As things designed to be secure are put out in the real world, with sufficient enough time, they're broken. It's important not to make the same mistakes again and again, and that's nearly impossible to do with JS-Crypto since there are so many permutations of platform X on implementation (browser) Y. As long as the numbers of platforms is large and the numbers of browsers are large, having one implementation that works properly in all platforms isn't practical. However, a specific implementation targeted at a specific browser/platform could be vetted provided the JS engine handles random numbers in a cryptographically sound manner. Ideally, the browsers would expose ways to call vetted cryptographic APIs directly via JS.
- jaekwon 13y agoThat's already happened w/ the crypto.getRandomNumber function, which openpgp.js uses/
- blahbl4hblahtoo 13y ago
- Procrastes 13y agoI understand the attraction. You want to solve this problem as if it was just a straightforward hack. I spent a few days looking at this same problem (harpomail.com) and abandoned it because, in then end, It seemed like I could only provide a false sense of security to people who could conceivably lose their lives because they trusted me. If it had just been a technical risk or a financial risk to myself I would have pursued it, but some risks are heavier than others.
- peterwwillis 13y agoso, you want to send someone a message. you don't care if someone sees you sending it. but you don't want anyone to know whom you sent it to, or what the message contains. requirement 1. message integrity and security 1a. use public-key cryptography - step 1. Person A writes a letter to Person B. - step 2. Person A encrypts a message using Person B's public key. - step 3. Person A sends encrypted message to Person B. - step 4. Person B receives and decrypts the message using Person B's private key. requirement 2. clandestine recipients 1a. coded messages - con: coded messages are usually broken after enough messages pass 1b. steganography - not difficult to detect if messages sent often 1c. dead drops - pro/con: MITM has to monitor the drop box to determine recipient 1d. peer-to-peer message passing - can still determine recipient using statistical analysys i think if you took the tor model for private services and removed the open circuits, and added a more evenly-distributed constant stream of garbage messages sent to random peer addresses, it would be much less likely that any one message could be linked to any two nodes with certainty. this would hinge on the premise that all nodes are constantly receiving messages (mostly garbage) at random. this would probably be a horrible thing for network bandwidth, but luckily most e-mails are very small.
- jaekwon 13y agoYes, we're on the same page! We have an idea for how fake messages would be passed around fake friends, and how to grow this "dark" network organically. Let's collaborate!
- peterwwillis 13y agoI think you're going to be disappointed. The only way this could work is based on network participants, and that's highly subjective. But here's an idea that might be plausible. You have four nodes in your network: B, C, D, E. B wants to send E a message, but doesn't want anyone who might be observing the whole network to know. B sends garbage messages all day at random to all active peers on the network, or as close as possible. We'll assume an even distribution of these random messages. When it comes time to send the correct message, it gets delivered just like all the others. This really only works if each message is received by a real peer. What you get is a constant stream of communication at random, in which case you know 99.9999% of it is junk, and maybe 0.0001% is real. At this point the observer will start drilling down into everything possible to increase the probability of detecting the authentic message. You'll have to prove none of their methods would be able to improve that quality, but an actual cryptographer would be a better person to ask about that.
- DanBC 13y agoWhat articles have you / your team had published in crypto journals? Where did you / your team study cryptography? The logo is a Rubik's cube. That's not a great logo for a cryptographic app because Rubik's cubes are trivially solvable.