Earlier quoted context omitted.
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 metadat…
Mailpile – taking e-mail back
101–110 of 157 posts
Re: Mailpile – taking e-mail back
#102Earlier quoted context omitted.
Well (E)SMTP works effectively by connecting, then knocking on the door and asking for a list of capabilities (EHLO). When the remote SMTP server says "no I don't support TLS", what are you supposed to do? Email only works at the moment because in this scenario, usually the sending MTA just says "what the hell" and delivers it over the wire in plain text anyway. The moment you force TLS as a requirement, the internet…
> Any fucker can buy an SSL certificate and > masquerade as someone else. You lost me there. I'm not entirely convinced on that. How might I simply buy an SSL certificate and masquerade as https://www.google.com ?
Re: Mailpile – taking e-mail back
#103Earlier quoted context omitted.
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...
Some key differences are that we do not store your emails, your email provider does. We do not ever, at any point, have access to your unencrypted keys. Therefore, we cannot, even if forced to turn over access to your data. That being said, as with all secure systems there may be bugs. The client however, is (will be) open source so that everyone can help solve whatever problems that may arise. The key point is that…
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. A step in the right direction, but all m00t unless everyone is using encryption and it becomes the defacto when communication via email.
Re: Mailpile – taking e-mail back
#104Earlier quoted context omitted.
Is your browser extension a generic solution to the "browser JS crypto" problem, or specific to your application? Solving that problem would go a long way in making secure communication more accessible, but it's a hard problem.
Rome wasnt built in a day, as the saying goes. Our solution here tries to solve a few of the problems to start with. The goal, however, is to maintain a list of urls, sha1 hashes, update times, and a list of verifiers. The sha1 hashes make sure that the js that you have is the one being distributed (although the hash may soon be upgraded to a different one). The update times and list of verifiers are used to be able…
Re: Mailpile – taking e-mail back
#105How 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…
Re: Mailpile – taking e-mail back
#106Earlier 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…
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…
There's a whole chapter dedicated to HSMs in Security Engineering [2], which is available online. There are clever ways to attack them, and yes, the booby trap idea has been done, typically by using something light-sensitive. I'm not aware of any concrete-encased HSMs, however...
It's an interesting topic. That are lots of challenges around them too. It will probably have a battery backup, so how do you allow someone to replace the battery without wiping the keys? Or can only people with access to the keys replace the batteries? That won't work if you're doing mathematical secret sharing, however, since there's no physical way to do that.
[1] http://en.wikipedia.org/wiki/Hardware_security_module
[2] http://www.cl.cam.ac.uk/~rja14/book.htmlRe: Mailpile – taking e-mail back
#107Earlier 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…
Interesting idea. Instead of a VM though, what about a small, low-power box that you plug into your home network that handles secure communication transparently to the user? I'm thinking something like AdTrap ( http://www.kickstarter.com/projects/600284081/adtrap-the-int... ) but for email or other sorts of communication.
But that is only one of many things it can do. Could it establish secure end-to-end connections with other people running the same System? Of course. Could you form your own overlay networks? Yes. Could you run email on top of these overlays? Yes, you could. In fact, you could run almost any program over these networks that you could run on a LAN.
This has all been possible for many years. More than a few people know how to implement it.
Whether there is consumer demand (cf. enterprise demand) for this solution is an open question. At least, so I thought.
Re: Mailpile – taking e-mail back
#108Earlier quoted context omitted.
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.
I can't remember calling a landline last couple years, except for public offices and banks.
Re: Mailpile – taking e-mail back
#109Earlier quoted context omitted.
I've spoken to one of the Mailpile guys on twitter, and his answer was that they're trying to improve adoption and implementation of existing standards, before they look at improving transports. Giving their timescales are already measured in years, I don't think Mailpile will significantly change the game. Kudos to them, but they'll just be Yet Another Commercial Pseudo-Secure-Email Seller . I agree that the problem…
Erm, isn't that what Thunderbird and Enigmail were doing/already do? https://addons.mozilla.org/en-US/thunderbird/addon/enigmail/ What am I missing that Mailpile will do, aside from possibly a better interface and lots of marketing?
Jk, the main difference is that mailpile wants to be fully web-based, whereas Enigmail is a fat client. I guess they plan on working heavily on key generation and storage (which is typically the sore point in tools like Enigmail).
Re: Mailpile – taking e-mail back
#110Earlier quoted context omitted.
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…
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…