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

91–100 of 157 posts

Re: Mailpile – taking e-mail back

#91

Post by tlrobinson »

noselasd wrote: post #87
tlrobinson wrote: post #69

Earlier quoted context omitted.

The usual argument against JS crypto is that a compromised (either technically or legally) host could send a malicious version of the code to steal your keys/data. A browser extension could in theory be used to verify the code against a signature or something to that effect, or it could sandbox the crypto routines and keys from the app itself (though that wouldn't prevent the app from stealing the decrypted data)

What needs to happen for this to become generally usable is for the crypto part to be built into the browser - that way you only need to trust your browser and not a somewhat random plugin, nor the .js being served from a particular server. And it'll "just work", so ordinary people have a chance to use and trust it too.

Sure, eventually, however I'd be just as comfortable using a plugin from, say, the EFF as I would having it built into the browser. It would be a fine stepping-stone (similar to how Google Gears contained many features which influenced HTML5)

And as I mentioned, merely having the crypto parts and key management built into the browser isn't good enough because a malicious site could still trick you into decrypting data which it could then steal, even if the keys themselves are perfectly safe.

Re: Mailpile – taking e-mail back

#92

Post by ds9 »

stbenjam wrote: post #51
crocowhile wrote: post #38

Earlier quoted context omitted.

No, it does not. Take this message: From: anonymous_acct_101@mailpile.is To: anonymous_acct_77@mailpile.is Mime-shit.... DEFKJiwfou3hoqwdnhoqiwfhoqifowqihwqoidhqwod== This is quite a secure message and it would be as easy to send as any other email with mailpile or similar services. My point is that security is not a black&white concept. There is a continuous of security, and part of the job of mailpile could be to g…

No. That really looks like another anon.penet.fi. If that is the case, then if 101 (let's call 101 Alice) or 77 (let's call 77 Bob) are using providers that are in bed with the NSA, the NSA can easily still grab the metadata from this. If Mailpile is the MTA, and the NSA is following the connections to Mailpile's servers they can use time correlation to find out the metadata. Metadata is hard to hide^. Anyway, as the…

So, Alice encrypts message with Bob's public key, that's EM1. Then Alice encrypts EM1 with the server's public key, outputing EM2. And sends that to Bob thru the MTA.

The server decrypts EM2 revealing EM1 and some plaintext metatdata arbitrarily specified by Alice. The MTA random-delays to keep them all out of order, and sends it on to Bob with encrypted body, whatever Alice felt like putting in the plaintext metadata supposedly representing the prior travels, and no attempt to disguise the MTA's IP, etc..

NSA now can see Alice's post to the MTA, but none of the mails coming out of the MTA match the text of Alice's email. The best the wiretapper can do is decide "someone in set A sent to someone in set B", and maybe apply statistical analysis. It is easy for the wiretapper if there are only a few people using this and hard if there are a lot.

The objection will be, but NSA/FBI etc. will trojan the code, coerce the secret keys, make the server deceive users. So the server owner would like to put in something that makes it all unavoidably, and conspicuously break if the code is compromised. Securing the latter behavior remains a problem when the adversary has, one must assume, physical control of the server.

Re: Mailpile – taking e-mail back

#93

Post by sesteel »

samstave wrote: post #57
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…

It's amazing how this is all coming about. Lots of people are thinking about the problems we have right now. I have been thinking of the following and want to get some feedback on the idea: ComBoxen! Comm box is a VM image that, when run, launches with a set of services that allow fully encrypted communications between other ComBoxes. Basically a secure linux distro on full lockdown that will register with a central…

I've had similar ideas for a long while. My flavor is using the router as an encrypted protocol gateway and some other centralized user queues. The centralized queue would hold encrypted messages for first time connections. Subsequent messages could be delivered p2p utilizing the fact that most people's routers are publicly available 90% of the time. A local standard mail client connects to a trusted mail server (router) for short haul com (LAN). For long haul, an app could be developed to decrypt the messages locally.

Re: Mailpile – taking e-mail back

#94

Post by mikegioia »

noselasd wrote: post #90
mikegioia wrote: post #22

Earlier quoted context omitted.

Why even bother with S/MIME? How long until the government corrupts the certificate for it if Mailpipe becomes as important to them as Lavabit was, in the future? The way I see it, Mailpile won't be issuing certificates for people to use, they merely enable you to use your existing certificate infrastructure. I have a machine with a certificate authority that issues S/MIME certs for us to use internally for sensitive…

I'd say the people that can set up and manage their own CA, and the people that need a new mail client to be able to send/receive encrypted email are non-overlapping groups. If you're right - what does Mailpile solve ?

The reason why I need something like Mailpile (and the problem they will hopefully solve) is to have a client-side app with a user-friendly system for managing S/MIME certificates.

I can set up the CA and generate user (employee) certificates on my own, there's no way the end-user should have to do that. But what's frustrating right now is that the current tools for configuring S/MIME signing and encryption for email either (a) don't exist, or (b) are heinously complicated to use.

Have you ever tried getting S/MIME certificate auth set up in Mac Mail? It's doable but I had difficulty walking my tech-savvy brother through the process over the phone.

If Mailpile has a simple method of selecting a certificate file for an email account then the hard part is done IMO. The process just becomes IT issuing new certificates every year to employees, and employees uploading said certificates through their (web) mail app.

The biggest value here is having a web mail client, hosted locally, that can support PGP/SMIME in a user friendly way. Then signed/encrypted emails are that much easier to configure for the masses.

Re: Mailpile – taking e-mail back

#95

Post by nollidge »

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.

Re: Mailpile – taking e-mail back

#96

Post by samstave »

sesteel wrote: post #93
samstave wrote: post #57

Earlier quoted context omitted.

It's amazing how this is all coming about. Lots of people are thinking about the problems we have right now. I have been thinking of the following and want to get some feedback on the idea: ComBoxen! Comm box is a VM image that, when run, launches with a set of services that allow fully encrypted communications between other ComBoxes. Basically a secure linux distro on full lockdown that will register with a central…

I've had similar ideas for a long while. My flavor is using the router as an encrypted protocol gateway and some other centralized user queues. The centralized queue would hold encrypted messages for first time connections. Subsequent messages could be delivered p2p utilizing the fact that most people's routers are publicly available 90% of the time. A local standard mail client connects to a trusted mail server (rou…

Yeah, I have been talking about this with people for some time - and while the idea of a box is great - and needed for the long term, a VM is ideal to begin with because it can be widely, swiftly and freely distributed.

Further, I was thinking of the following scenario for message validation - (this is just a thought experiment, so it really needs some critical examination I am not sure this even gains one anything):

You run two instances of your VM. One is run locally to you - another is hosted. When a message is sent to you from another peer - it must reach both the hosted and the local one to be opened. When both instances are online at the same time - a hash is shared of the message between both instances and the local master can trust and open the message.

When you're locally off line and a message is sent - Thus, if your locally offline - your hosted instance receives the message. When you come online - your local instance will receive the message from your hosted instance AND a hash from the senders hosted instance. If the hash from the sender matches the message hash from your hosted instance - the message is trusted and can be opened. Else it is dropped.

The problem is that all these p2p secure connections can still always be slurped.

The addresses are only within the system and one would never know which hosted instance belongs to what actual address.... (This area needs a lot more thought)

Re: Mailpile – taking e-mail back

#97

Post by malandrew »

spindritf wrote: post #86
moxie wrote: post #52

Earlier quoted context omitted.

I don't think Mailpile is potentially valuable because it immediately solves the encryption problem, but because it solves the MUA problem. All innovation in the secure email space has been blocked for the past 13 years by one primary problem: webmail . It is simply not possible to develop a secure email solution if webmail is the only viable option for accessing mail, so most people who would be interested in innova…

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…

Can't we also make a server that is physically hardened against tampering? If servers get small enough and cheap enough and only need to support one individual, then you can always try encasing that server in some material that is physically difficult to penetrate without risking destruction of the server itself. i.e. encase the server in concrete or opaque resin with a thin lead shielding to prevent x-raying of the device for precise drilling and exposing only the power leads and the network interface. As long as the network software interface is totally secure, you leave no way for any other attacks that I can think of. You could go further and booby trap the enclosure so that it destroys it's contents. At the end of the day, many of these ideas have already been explored in the safe manufacturing industry, such as glass panels that shatter upon drilling, permanently locking the safe. A glass enclosure with a strong liquid corrosive could be used around a small server. Tampering with the outer enclosure could result in likely breakage of that glass vessel, thereby destroying the server beyond recovery.

Re: Mailpile – taking e-mail back

#98

Post by aravenel »

swdunlop wrote: post #62
tokenizer wrote: post #3

So will this bypass prism-like surveillance methods?

Not at all. "Mailpile will download your e-mail from a mail server much like Thunderbird or Mail.app and process it locally." PRISM and other efforts at tracking associations operate at the server and header level, this is not a useful countermeasure. It may reduce the amount of mail you leave on the server -- but so would a reasonable mail reader configuration.

If it makes it easier to use encrypted email, then it does a little--any emails with someone with whom you have exchanged keys would be encrypted, and thus while they do indeed still fly across insecure channels, they are (presumably) uncrackable.

Obviously, the vast majority of emails would still be unencrypted, and this does nothing for metadata. But anything that makes encryption less cumbersome to use is a good thing in my book.

Re: Mailpile – taking e-mail back

#99

Post by astrodust »

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…

UUCP is an interesting example because it was completely understood that your messages would be routed through semi-trusted intermediaries.

SMTP is presumed to go directly between trusted parties, but this is clearly not the case any longer.

Re: Mailpile – taking e-mail back

#100

Post by bdcravens »

nine_k wrote: post #48
seiji wrote: post #43

Earlier quoted context omitted.

Fast? IE6 was released in 2001 and people didn't start "dropping support" until 2008 or 2009. Unencrypted email is like unencrypted telephone calls. Imagine how to get the world to switch to using encrypted handsets.

GSM communication is actually encrypted [1], albeit lightly. I remember having an unencrypted NMT handset and ditching it circa 2000 in favor of a GSM handset. NMT support was dropped by my service provider 3-4 years later. So transitions like this are definitely possible, though not overnight. Remember the slow introduction of https. [1] http://en.wikipedia.org/wiki/GSM#GSM_service_security

You're forgetting POTS lines. I can call someone on a POTS line, with a 1992 handset, and it works the same as if I called someone with a brand new GSM phone.
Post reply on HN