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

141–150 of 157 posts

Re: Mailpile – taking e-mail back

#141

Post by bhitov »

gioele wrote: post #21
sipior wrote: post #13

Earlier quoted context omitted.

Okay, Harry, let us know when you're done with that :-) I suspect most of the rest of us would prefer the perfect not be an enemy of the good.

In encryption there is no "good": it is either "perfectly working" or "fundamentally compromised". If there is only a small flaw in an encryption system, be assured that it will be exploited to break down the whole system. A simple example are all the issues with random number generators producing not perfectly random numbers; yes, it is just a slight problem in an otherwise good solution but that problem completely…

That is not correct. There can exist flaws that cause loss of entropy that do not entirely compromise a cryptosystem.

Re: Mailpile – taking e-mail back

#142

Post by reeses »

anigbrowl wrote: post #130
reeses wrote: post #50

Earlier quoted context omitted.

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 priva…

Oh my, the miniature safe analogy was one of the methods I used to try to explain to my wife why messaging privacy was an issue. :-) "OK, I don't know the combination, I just have a bunch of safes with your name on them, and only you know the combination..."

I'm not so concerned about the "timeliness" issue on a sub-yearly scale. It was a throwaway possible benefit of using multiple keys, cryptosystems, and decentralized transmission. As one of the elements is compromised by advancements in the art, they can be deprecated in favor of a stronger one.

By timely, I meant that it would be less economical to slurp up everything with the goal of SNA on a cohort of college friends or whatever.

I'd like an increase in the reasonable expectation of privacy with email. I would of course comply with a legal demand, authorized by a judge in my country, to surrender cleartext emails that are on my systems or in my accounts. I would expect my partners in conversation to do the same.

What I do not like, and I think we agree, is the convenient slurping of all the traffic, storing that, and then mining it for correlations with "un-American" conduct.

What I've found to be a more useful explanation trying to explain "security" as we usually mean it is to get to the reason why I think people should have privacy from their government or the agencies to whom they willingly transmit information about individuals. We've come a long way in securing rights for people who are not white, christian (of accepted denominations), straight, men. We have a lot longer to go.

I am really quite uncomfortable with a HUAC-style group having access to all electronic communications. It was communism fifty years ago, it's obviously terrorism now, but it will always be some threat to "national security" that is used as an excuse to be proactive about looking for suspicious characters because of what crimes they may be inclined to commit.

(And I kept using my own boot-root installation on my first Linux box (which could now legally buy alcohol in the USA) until 2000 or 2001, when I tried this "Redhat" thing. :-))

Re: Mailpile – taking e-mail back

#143

Post by 616c »

What bothers me a little is this is basically a reinvention of the wheel for sup-mail, developer by a Twitter developer and was/is very cool (I use it on Mac occasionally for backups of email I have in a Maildir). Maipile would add the web interface, and they just started transitioning to that idea in the sup community, calling it heliotrope.

https://github.com/sup-heliotrope/

Re: Mailpile – taking e-mail back

#144

Post by puzzlingcaptcha »

enterthemist wrote: post #54
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…

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…

You probably realize that doing crypto right in js is very challenging. This has been discussed several times on HN, usually this article is brought up: http://www.matasano.com/articles/javascript-cryptography/

Re: Mailpile – taking e-mail back

#146

Post by ds9 »

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…

And when someone connects to a Commbox, how can they tell (across the network) whether it's operating as described, or an imposter box reporting to the bad guys while pretending to be trustworthy?

This is a problem for a lot of these ideas, not only yours and mine (see my other post where the difficulty comes down to verifying the server).

Logically, the solution would seem to be a tamper-proof (or tamper-evident) hardware subsystem, working much like the evil, so-called "Trusted computing" scheme, except with the owner having full control of all the keys.

Re: Mailpile – taking e-mail back

#147

Post by samuelfine »

Each time someone attempts to make email more secure, the HN response is "no use! need to start from scratch, do it right!"

So, I guess what I'm saying is:

1) Are you working on an inherently-secure messaging protocol? Awesome! Link to the project?

2) If you're not, shut the fuck up. Any improvement is better than no improvement, and dismissing any attempts to fix some of these problems while you wait for The Perfect Solution™ is why we're in this mess in the first place.

Re: Mailpile – taking e-mail back

#149

Post by kyrias »

balabaster wrote: post #137
sorbits wrote: post #45

Earlier quoted context omitted.

Why is it a hack job? I would say it’s patching a hole, and it’s the feasible way to make email secure, rather than throw it all out and convince the world to switch to a new system. Most (internet) standards evolve this way. That’s the curse of evolving a standard that is already in widespread use.

Mostly because it rests on CA's and if the government can compel the CA to give them a signed cert for something that your security relies on, all they have to do is pose a MITM attack and you're blissfully clueless that they're spying on you. The whole system is broken and if you don't fix the foundations upon which your house is built, no amount of band-aids are going to keep the walls standing.

No, with DANE nothing rests on CA's. With DANE domain owners store their keys in the DNS, and the DNS records are signed with DNSSEC

Re: Mailpile – taking e-mail back

#150

Post by cdjk »

malandrew wrote: post #133
cdjk wrote: post #106

Earlier quoted context omitted.

It's called a hardware security module (HSM) [1]. The basic idea is to store the private key in the tamper-resistant hardware, along with a microprocessor to perform the basic encryption options you need. They can be relatively cheap, like a smart card + usb smart card reader, to very expensive, like an IBM 4764. Yubikey sells a usb HSM if you want to run your own authentication server for around $500. There's a whol…

Cool info. Upvote. As far as some of the issues you raised like battery replacement, I would treat them as disposable. In the next few years a complete computer will be available for so little that we will consider it disposable. Prepare a server once, enclose it, make sure the only way in or out is an SSH connection. When it's time to set up a clone to replace it, clone everything via an SSH session and trash the fi…

That could work, but the advantage of an HSM is that the key material is physically prevented from leaving the device, barring acid/x-rays/other attacks. All encryption happens on the device itself. With an open ssh connection you could still remove the key material from computer.
Post reply on HN