Brother, can you spare a DIME for holy grail of secure webmail? Lavabit founder Ladar Levison promised attendees at security conference DefCon that he'd carve out a secure messaging service from the wreckage of the email service favoured by rogue NSA sysadmin Edward Snowden within six months. The Dark Internet Mail Environment (DIME) project is promising, but recent problems experienced by …
Since the press are now happily associating "dark internet" with "pædophiles and perverts" it seems just a little foolish to call this the "Dark Internet Mail Environment", no?
And will the truly paranoid ever believe that any service which depends on systems you don't own is secure? Secure webmail is an oxymoron, the points made in the article are valid. If you're relying on an app downloaded on the fly from a server to handle your security, you may well have no security.
is that it seems to define you automatically as an enemy of the state.
Until we manage to persuade the state - whom we allegedly allow to represent *our* interests - that 'mind your own business' is a valid response to any and all questions, there seems no way to avoid this.
Nothing to hide == nothing to fear, my arse. It's none of your business. Period.
The biggest problem with encrypted email is not everyone is using it. Crims already do and that leaves regular folks email accounts open to government intrusion. Their going into your email account is no different than going into your home searching for evidence of wrong doing. Believe me, if this activity is not stopped soon and the paranoia curtailed that is exactly what will happen in the future. Those web cams and mics built into your TV, PC, tablet, phone, and fridge will be under government control soon.
One of the more important revelations to come out is that even the criminals aren't using secure methods of communications. Thus the whole reason for the current intelligence infrastructure is completely missing. Apparently even the terrorists aren't using sophisticated methods that actually accomplish anything, if they don't make data collection actually easier. As has been proven so many times before, even the professionals can make one-year mistakes in this field.
@Neil_Barnes you've put your finger on it. I know that the powers that be could enquire deeply into my life if they had reasonable cause to. We accept that as the price of being kept safe from bad people. What I really object to is the powers that be snooping into my life when all I'm doing is getting on with things.
Governments are instituted among men (and women), deriving their just powers from the consent of the governed. Whenever any form of government becomes destructive of these ends, it is the right of the people to alter or to abolish it, and to institute new government, laying its foundation on such principles and organizing its powers in such form, as to them shall seem most likely to effect their Safety and Happiness
ISTM that there's a straightforward way to manage public keys: have the mail server provide it on demand.
Alice sets up mail address.
On first connection by Alice's client server asks client for the public key.
Client generates key pair & uploads public key.
Bob writes mail to Alice.
Bob's client asks Alice's server for her public key.
Alice's server sends key.
Bob's client encrypts mail, sends it & caches key for subsequent use.
Alice's client gets mail from server & decrypts in.
Alice's private key never leaves her client and Bob is now your uncle.
Won't work for webmail* but if you were using webmail you didn't expect privacy, did you?
*Well, it would work if the client work is done with a browser plug-in but the article mentions the inherent snags with that.
Doctor Syntax - you may want to read up on the importance of authentication in asymmetric key crypto. i.e. How do you know you're sending the message to Alice and not Charlie? If you can't validate the authenticity of the public key (i.e. that it definitely *is* Alice's), then you're wide open to man-in-the-middle attacks.
The other thing is that quantum computing threatens to undermine the whole P=NP robustness of many asymmetric key crypto. And you can bet the NSA are somewhere in the frontline of getting this stuff working (if they haven't already).
The other thing is that quantum computing threatens to undermine the whole P=NP robustness of many asymmetric key crypto.
No.
Quantum computations do not threaten anything even in the general vicinity of NP.
Factorization is a "hard problem" for classical computers but is not NP hard nor NP complete.
There a more threats than the NSA. We currently have a situation where not even commercial confidentiality can be maintained. Right now, I'd like to think that if I, as an individual, have to correspond with a business, doctor, solicitor etc by email I could do so without any casual wire-sniffer getting access to whatever I might be writing in confidence. With today's email I can't and frankly that concerns me more than whatever NSA or GCHQ might get up to.
As things stand most mail flows unencrypted and can be examined in passing with no particular effort. Having most mail encrypted would raise the barrier somewhat and require MITM or evil server attacks. For most email users that would be a good start. What I've suggested could be phased in with new versions of clients & servers. It's also a structure which would enable signing - charlie@phishersrus.ru would find it a bit harder to pass himself off as eve@mybank.com.
Isn't that just the old secure RPC AUTH_DES/AUTH_DH model?
It works well, but your approach still presumes you can trust Alice's server not to send Bob *it's* key (claiming it's from Alice) whereupon it can then decrypt Bob's mail, stuff a copy out the GCHQ pipe, re-encrypt it using Alice's real public key, and pass it to Alice. Unless Bob knows for certain the the public key he has is really from Alice, it can't be trusted.
He have to dump current certs.
Have 3-4 of them, on an independent country (swiss ppl maybe?), and if they leak the certs, dump them.
Otherwise, this "https" shit is that, shit.
Many big cos spy on their employees because they have systems that use bogus certs for MiM attacks. Law enforcement? They also have that. Some crooks also have it, as it really is in the wild.
So, me can't rely on todays CERTs. Fix that, and use certs for everything, and it is a done thing.
Let's say I want secure email for all my employees. But then Alice gets run over by a bus and is in hospital for six weeks, and Walter needs access to her mailbox. Can I get a secure email system for my employees which nevertheless still allows the IT department to grant access to Walter's mailbox?
You'd need to get Alice to place her secure key in escrow somewhere, where it could be released by some agreed-on procedure. That can be done electronically.
It's just a modern version of the problem with a locked desk. You lock your desk when you go on vacation, and leave a key in a sealed envelope with someone you can trust. If you don't return, your boss can rip open the envelope and get at your papers. If you do return, if the envelope is still sealed you're OK, if it's not still sealed you raise hell.
Why does everything need to be delivered as a webmail-service? I would not feel secure using anything that resting on that assumption.
Let's ditch the www-assumption and build something decentralized from scratch. However, I'd still insist that PGP-like encryption STILL is a good and useful tool.
As far as designing something that's inherently secure for "the masses", I'm sceptical. You can have ease of use, or security, but once you want both, there are hard compromises that have to be made.
There is no possible way to build a secure webmail client. If the government tells the webmail providet to replace their application with one that captures the user's keys and send them out then there is little you can do about it.
We need secure email applications that we can run on our own hardware. Even better we need a decent secure messaging (both email and IM) protocol that anyone can implement like SMTP but not overcomplicated like a lot of newer standards seem to be
What we actually need is a completely decentralised e-mail service, the same way Gnutella was for downloading "stuff", if you remember it? No e-mail stays on the server and server is only here to connect the clients. All e-mail gets encrypted by default, of course. I'm actually going to try to push this idea further, assemble a team of smart people, and see where it gets us. Open source, multi-platform project, of course... if you're a developer and interested in the idea - contact me.
Today most mail servers already use TLS for all their connections, so only the involved servers see the headers. Of course those are self-signed certificates... but for governmental attackers that's no less of a problem than actual ones. In both cases you need to do an active attack which is potentially visible.
Same goes for any sort of "encrypted webmail service". Even if the browser was a secure environment, once you can break TLS you can send any Javascript you want over that connection.
So what shall we do? I believe we should make GPG more user friendly while keeping it compatible with what he have. For example the default configuration of Enigmail could always attach the current active key for the sending address, plus it could automatically store public keys it got from e-mails that were signed. In the default setting it would then try to make smart decisions on which keys to use when. So if it recently got a signed e-mail from someone you'd send back an encrypted one to that address.
Of course you should still be able to do everything manually, if you choose to do so. Also for mobile devices you could do key exchange via QR-codes.
The point is, we already have good infrastructure, which was not designed by idiots. Redoing it now again risks that it'll be done by the current flood of idiots who think that earning their money in writing shitty apps for mobile devices and reading a the Wikipedia page on Cryptography makes them suitable for designing systems that should protect peoples lives.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
