Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mailpile – taking e-mail back

indiegogo.com

Post reply on HN
Print view View original

121–130 of 157 posts

Re: Mailpile – taking e-mail back

#121

Post by cwp »

FedRegister wrote: post #8
modoc wrote: post #7

Earlier quoted context omitted.

Did you read what Mailpile is doing? Basically making PGP easy to use which solves the lions share of the issues at stake here with the NSA and your complaints.

Except it doesn't solve the traffic analysis problem. It doesn't because it can't. Out of the list posted by the GP the following aren't fixed by mailpile and can't be because it has to use SMTP: modern content encapsulation / PKI / mandatory authentication / SPAM control.

What do you mean by modern content encapsulation?

Re: Mailpile – taking e-mail back

#122

Post by bradleyjg »

enterthemist wrote: post #116
kamjam wrote: post #103

Earlier quoted context omitted.

So now I really don't understand how this is any different from using Thunderbird and EnigMail/PGP to encrypt your mail - and if I've understood correctly then it actually isn't any different, you are just providing a glossier interface. I think it's a worthwhile project, but beyond the tech community, I'm not entirely sure how much traction usage will get... Thunderbird/Enigmail is a PITA to setup and use for sure.…

It is different in that it creates a key distribution interface for the average person. This interface allows things like decrypting emails in the browser and transparent security. It also allows you to know who has security and who doesnt (this allows people to incrementally start using encryption without the headaches of wondering who else is using it). These are problems that are not solved with any PGP type inter…

Lavabit had a similar architecture, only with the password could the server-side email be unencrypted. Although we don't know for sure, it appears that the government insisted that they trojan their client side code to retrieve the password.

Your secret sauce, if I understand it correctly, is open sourcing the client side code and providing some mechanisms to assure end users that what they are executing matches the publically published code.

That makes sense to me, but I don't see why you wouldn't go one step further and store the secret key in the browser plug-in. Is it an multiple-installation issue?

Re: Mailpile – taking e-mail back

#123

Post by enterthemist »

bradleyjg wrote: post #122
enterthemist wrote: post #116

Earlier quoted context omitted.

It is different in that it creates a key distribution interface for the average person. This interface allows things like decrypting emails in the browser and transparent security. It also allows you to know who has security and who doesnt (this allows people to incrementally start using encryption without the headaches of wondering who else is using it). These are problems that are not solved with any PGP type inter…

Lavabit had a similar architecture, only with the password could the server-side email be unencrypted. Although we don't know for sure, it appears that the government insisted that they trojan their client side code to retrieve the password. Your secret sauce, if I understand it correctly, is open sourcing the client side code and providing some mechanisms to assure end users that what they are executing matches the…

> Your secret sauce, if I understand it correctly, is open sourcing the client side code and providing some mechanisms to assure end users that what they are executing matches the publically published code.

Yes, the js client is fully intended to work exactly this way.

> That makes sense to me, but I don't see why you wouldn't go one step further and store the secret key in the browser plug-in. Is it an multiple-installation issue?

There are a few issues here.

1. The first is the general crypto principle: minimize your TCB. I want the key to have to touch as few places as possible. For this reason, I have plans on moving the keys from the server to a clients machine(s). Doing so, however, involves a lot more problems including: NAT and the lack of a fallback. In the future, when I have more time to work on these details, I want to try and make that an option for people.

2. Another problem with placing the key in the browser is as you say: it allows anyone who is able to access the browser to access your key (including malware and other users).

3. Lastly, where would this key come from (remember rule #1: the server never has access to an unencrypted key)? If it is generated on the local machine that would then mean that you have no way of distributing it to your other machines (or at least not in ways that your grandmother will be able to do). Even if there were some super snazzy interface, it would be prone to attack as well.

Re: Mailpile – taking e-mail back

#124

Post by bradleyjg »

enterthemist wrote: post #123
bradleyjg wrote: post #122

Earlier quoted context omitted.

Lavabit had a similar architecture, only with the password could the server-side email be unencrypted. Although we don't know for sure, it appears that the government insisted that they trojan their client side code to retrieve the password. Your secret sauce, if I understand it correctly, is open sourcing the client side code and providing some mechanisms to assure end users that what they are executing matches the…

> Your secret sauce, if I understand it correctly, is open sourcing the client side code and providing some mechanisms to assure end users that what they are executing matches the publically published code. Yes, the js client is fully intended to work exactly this way. > That makes sense to me, but I don't see why you wouldn't go one step further and store the secret key in the browser plug-in. Is it an multiple-inst…

Thanks for the response. I would look back at some of the articles that came out on the imessage protocol several months back. They face a similar key distribution problem given that iMessages can potentially be delivered to multiple devices. I don't remember if the reverse engineering ever figured out exactly how they cracked that nut, but I seem to remember that there were some reasonable hypothesis.

Re: Mailpile – taking e-mail back

#125

Post by benedikt »

tga_d wrote: post #111
spindritf wrote: post #86

Earlier quoted context omitted.

Wouldn't Mailpile make things better even if you kept your GPG keys on the server? Sure, if the authorities targeted you specifically, they could probably pry the unencrypted keys from the server's memory (although with considerable effort it it was a dedicated or collocated machine) but widespread adoption of that model would completely stop dragnets. Only narrowly tailored investigations would be feasible, no mass…

Only the public key should be stored on the virtual mail server, since all it's doing is encrypting incoming mail. It's your local email client (e.g. Thunderbird) that then downloads the encrypted emails to your local machine and decrypts them with your private key. Signing and outgoing encryption are also done locally. At that point, all that someone raiding your VPS gets is a bunch of encrypted messages, which good…

What about the VPS provider being coerced into logging network traffic to the VPS? Then incoming un-encrypted mail is compromised..

Re: Mailpile – taking e-mail back

#126

Post by Zoomla »

kamjam wrote: post #67
enterthemist wrote: post #54

Earlier quoted context omitted.

Firstly, I want to applaud mailpile for their efforts. Next, I'd like to respond to you with what our product is aiming to solve (because that is what I know best). > All innovation in the secure email space has been blocked for the past 13 years by one primary problem: webmail. We are working on solving this very problem. We do this via js crypto. The main problem with js crypto is modification of the crypto with th…

How trust worthy is the js crypto? For a long time people believed hushmail to be safe: http://en.wikipedia.org/wiki/Hushmail#Compromises_to_email_p... Regardless of how safe it is, the problem is still social engineering hacks, key loggers etc (you'll always have this issue) - just wondering to what lengths a government will go...

they might go as far as implementing back-doors in OSes according to past rumors

Re: Mailpile – taking e-mail back

#127

Post by Zoomla »

nollidge wrote: post #95
ghc wrote: post #58

Okay, so we're crowd-funding an email client now? Is there any reason to not just put up all of my random project ideas on indiegogo and see if they get funded? If I'm having trouble financing the development new features for my SaaS application, should I just create a funding project for it? Because I'm really not seeing the difference between that and this...I wish someone could explain this phenomenon to me.

> If I'm having trouble financing the development new features for my SaaS application, should I just create a funding project for it? Sure, why not? No one is stopping you. > I wish someone could explain this phenomenon to me. Many people invest small amounts of money in a person or group of people. There are risks, like any investment, and the payoff is a product which the investors will find useful or entertaining…

it is not really an investment, it is more like charity... you more then likely never get more then what you paid for and you have a risk of loosing it all.

Re: Mailpile – taking e-mail back

#128

Post by rst »

benedikt wrote: post #125
tga_d wrote: post #111

Earlier quoted context omitted.

Only the public key should be stored on the virtual mail server, since all it's doing is encrypting incoming mail. It's your local email client (e.g. Thunderbird) that then downloads the encrypted emails to your local machine and decrypts them with your private key. Signing and outgoing encryption are also done locally. At that point, all that someone raiding your VPS gets is a bunch of encrypted messages, which good…

What about the VPS provider being coerced into logging network traffic to the VPS? Then incoming un-encrypted mail is compromised..

This is pretty much the reason that Silent Circle shut down their email product. Their other offerings use custom protocols with full end-to-end encryption (and are still up and running), but for email, they were trying to interoperate with the legacy stuff, which left them handling plaintext in some cases.

It's also the focus of some of the speculation about the unknown demand that triggered the Lavabit shutdown.

Re: Mailpile – taking e-mail back

#129

Post by brown9-2 »

So there are no actual "perks" for the $1 and $8 contribution levels listed under the "Select a Perk" table?

$1 Binary E-mail User: You're part of the revolution, baby! - the revolution that started in the 1960's with the creation of the first e-mail systems.

$8 Futurist Telegrapher: Having not spent a dime on webmail for the last decade, you've realized that the telegraph operators of the world have been keeping copies, and it's time to change that. Thanks for helping us help you!

So what do the contributors actually get for $1 or $8?

Re: Mailpile – taking e-mail back

#130

Post by anigbrowl »

reeses wrote: post #50
harrytuttle wrote: post #4

How many times do people have to say this: There is no such thing as secure email. Assume everything is being read. You can't bolt security on (SSL, mailbox encryption, PKI). You have to design it in from the start. SMTP/IMAP etc have crudely hacked on TLS implementations which aren't even guaranteed to be operational site to site. PGP is just an encapsulation which is rarely used. It's a mess. This is just a repacka…

We have options already, although we abandoned them once the Internet became ubiquitous. UUCP would allow encrypted envelopes that would only allow trusted nodes to decrypt enough to forward to the next destination or to the local user. It would be ungainly, especially at first, and just as easy to scoop associations between users (although, not subject lines or other metadata) by tracing the limited paths. As a crit…

Amusingly, it seems like we've come full circle to the early days of Linux when getting your own domain was the definition of hardcore (and Linux itself typically involved booting from floppy).

timely interception of content would be significantly reduced

The thing is, most people are not interested in such security because they don't see themselves as engaged in a race against government surveillance. You want privacy on general principles, that makes perfect sense. But if you're proposing obfuscation of message paths as a temporizing tactic, it becomes attractive of attention because the naturally question to ask is 'what's the rush, exactly?'. If anything, this gives ammunition to the proponents of 'ticking time bomb' scenarios, notwithstanding the inherent flaws in their arguments. I don't really think that the smart response to their claims is to propose that everyone carry loud mechanical alarm clocks, for the same reason that the 4th amendment is not best upheld by advising everyone to carry miniature safes.

Post reply on HN