Silent Circle, Lavabit Unite For 'Dark Mail' Encrypted Email Project 195
angry tapir writes "Two privacy-focused email providers have launched the Dark Mail Alliance, a project to engineer an email system with robust defenses against spying. Silent Circle and Lavabit abruptly halted their encrypted email services in August, saying they could no longer guarantee email would remain private after court actions against Lavabit, reportedly an email provider for NSA leaker Edward Snowden."
Did the NSA just kill SMTP? (Score:5, Interesting)
Thanks Snowden (Score:5, Interesting)
Re: (Score:3)
It's problematic if becomes some niche thing like Tor, which the NSA knows to zoom in to, as the people with something crucial to hide might be found there.
That's why one of the goals of the anti-surveillance movement is to increase Tor participation — the bigger it is, the better the protection (probabilistically-speaking) afforded to each participant. I use Tor (plus DNSCrypt) for everything I can, except for BitTorrent payload data... (For that, I use forced-RC4-160; unlike "plain" BT encryption, encrypts the payload in addition to the header. Yes, RC4 is very weak (even "broken"), but it's still a hassle for Eve compared to plaintext). It's worth men
Re: (Score:2)
I wish they would also do something fundamental about spam problem. But that would possibly means unique id for senders which would ruin anonymity.
Re: (Score:2)
What I fear is that we trade in a protocol at sort of works for one that is patent encumbered or has some unknown issues in it.
Re:Did the NSA just kill SMTP? (Score:4, Informative)
They want to build it upon XMPP, according to the Ars article [arstechnica.com] I read earlier this day.
Re: (Score:2)
That's what Apple did with iMessage. Extending XMPP doesn't mean it needs to be open.
Re:Did the NSA just kill SMTP? (Score:4, Interesting)
RTFA - their intent is to make an Open Source solution. Given that these people shut down their businesses rather than compromise their principles, I'd find it hard to believe they were about to release patent-encumbered source code on the world.
Re: (Score:2)
And it won't go anywhere at least as they are selling it now. Darkmail? Protect against the NSA? To get widespread adoption you have to sell this as security and as an upgrade not as armor or defense. You have to make Grandma an Grandpa want to have it to help stop what to there minds are hackers and spammers.
Re:Did the NSA just kill SMTP? (Score:5, Insightful)
Re: (Score:2)
So when this has all played out, what will the NSA have achieved? Nothing, except a parasitic drain on everyone's resources and a layer of molasses over the whole system.
Re: (Score:2)
Wrong.
They will have made us all less safe. While villanizing the NSA may be fun, and while they clearly have gone way beyond their mission, and while they are acting like real-life versions of Colonel Sam Flagg from MASH, one little fact remains.
There really are people out there who want to hurt us and cause widespread mayhem and destruction. I get the general impression that those same people want a return to the Caliphate, and would just as soon see technology worldwide return to that of the old Caliph
Re:Did the NSA just kill SMTP? (Score:5, Informative)
No. SMTP was never meant to be secure and was never advertised to be secure. It's "secure enough" for casual and most business emails. I'd venture a guess that 99.999% (and that may even be low) of email sent would have zero benefit of being encrypted because no one cares what the content is.
It'd be like encrypting every conversation at a football game. Yeah all the conversations would be private, but aside from the two parties talking, no one cares.
Many protocols used over Internet were not designed with encryption because it didn't seem that important at the time. Internet was built with the intention that everyone plays nice and the networks are trusted. With NSA, times have changed, as they can set up a MiTM attack anywhere and the wire cannot be trusted anymore. It's not that they would only get a criminal warrant for the ISP to reveal your mailbox contents, but instead they are actively snooping in random places where they shouldn't be.
Re: (Score:2)
When the internet was built everyone used their real names tied to a work address and they were military or academic associated with the military. There was no privacy so no particular reason to spy.
Re:Did the NSA just kill SMTP? (Score:5, Informative)
Many protocols used over Internet were not designed with encryption because it didn't seem that important at the time.
Contrary to popular belief, "designing in security" does not mean every protocol has encryption built-in. It does mean that when designing an implementation of a protocol, security is properly factored in. And, in a system, that encryption is used in the appropriate places.
Most protocols on the Internet are application level protocols. Some applications would benefit from application level encryption because this reduces (not eliminates) risk of exposing unencrypted data. For most applications it's more efficient to implement a common encryption service then have the applications use that. That also has the advantage of enabling including encrypting the (final) endpoint identification (and other application identification) by implementing the encryption between the Transport and Network layers. Applications with their own encryption would also benefit from this.
Even with application level encryption, many (maybe most) of the existing protocols are useful. Example: A subset of SMTP could be used in delivering email. The email client application would establish a secure connection to the destination email server then send the actual message(s) using SMTP. Both the client-server connection and the messages would be encrypted. The server needs some meta data to deliver the messages to the mailboxes, but the meta data would otherwise be encrypted on-the-net. The messages would be decrypted by the email client to display to the user. (Even if you used direct IM, the Transport layer meta data would still exist, so you only get a little extra protection from direct IM - but IM is only possible when both parties are online.)
There is also value in implementing encryption just below the Network layer as this will encrypt the routing information as well. Still end-to-end at either the Transport layer or in the application (or, both) is vitally important.
(For those not familiar, the Network layer is responsible for moving data packets around the network, ultimately delivering data to the destination host. The Transport layer is responsible for end-to-end communications and represents the host. The host is the collection of applications running in a machine (physical or virtual) that use the Transport layer to communicate with applications running in other hosts. The "final" endpoint is what TCP, UDP and several other transport protocols call the "port" (example: port 80 for HTTP/HTTPS servers))
Re:Did the NSA just kill SMTP? (Score:4, Interesting)
What might be a decent replacement for SMTP, but for small messages only (under 1-5 megs) would be a NNTP-like structure.
User "A" at site foo.com wants to send a message to user "B" at bar.com. The message is encrypted with OpenPGP to b@bar.com. Then, the server at foo.com drops it into a store and forward pool similar to a newsgroup. bar.com eventually receives the latest messages, notices a message addressed to one of its users, copies it out of the "newsgroup", and into the user's mailbox.
Of course, a blinding factor can be attached so no other machines with the NNTP-like pool can tell that the message is addressed to someone at bar.com, they can tell it is injected from foo.com and expires in a few hours, but that is that.
Of course, the disadvantage is that a whole lot of irrelevant info goes between company servers. The advantage is that communications are protected, as one might see a server drop a message into the stream, but there is no way to detect a server fishing one out.
Called it (Score:2, Informative)
Re:Called it (Score:5, Insightful)
Registrant Country:US
I'd just feel a bit happier if the new effort was based somewhere other than the USA; somewhere a bit harder for the NSA to get its sticky paws into. I have in mind how the NSA screwed with IPSec [wordpress.com]. Mind you: discussion would have to be international, I am not sure how much harder it would make things for them if this was based in, say, Bolivia.
Re: (Score:2)
Before I get flamed: the above was not intended as a slur against the guys at Lavabit and Silent Circle.
Re: (Score:2)
IPSec was an international effort ...
Re: (Score:2)
I know the feeling. But let's explore this just a bit. Do you have any siggestions? I'm serious.
If the place is too small, it is open to bullying, all the way up to invasion.
If the place is so powerful the US cannot bully them, do you have any confidence at all that this other place will not itself constitute a serious potential threat to liberty and anonymity?
Re: (Score:2)
Re:Called it (Score:5, Funny)
Another mail protocol (Score:5, Interesting)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
But S/MIME suffers from the hopeless reliance on Certificate Authorities. The NSA preys on the Certificate Authorities and any pretense that your privacy exists is shattered.
Crimonelly! (Score:3)
Congrats: your sentence is thoroughly encrypted!
Dump SSL / Certificate-based Security (Score:5, Insightful)
The whole paradigm of certificate trust, and the fact that you just have to trust Root CAs, is a farcical model of security.
We should all be aware by now that the Root CAs we all know and trust are compromised by NSA and that they can MITM any SSL connection they want at any time.
Until we can move beyond this whole third party certificate trust issue, there will never, EVER be truly secure email.
Re: (Score:3)
And if a site
Re:Dump SSL / Certificate-based Security (Score:4, Informative)
StartSSL [startssl.com] offers free-of-charge domain-validated certificates that are widely trusted. Other CAs like GoDaddy and Comodo offer (often through resellers) domain-validated certs that cost less than $20/year. Thawte DV certs from resellers cost about $30/year. The cost (or lack thereof) for such certs is probably the least important reason why people aren't using HTTPS more.
EV certs are well within the budget for even small businesses, and usually cost around $150/year. Again, hardly unreasonable.
It'd be nice to see more hosting companies implement Server Name Indication (SNI) so that clients can implement SSL/TLS without needing to waste a dedicated IP address. This really should be the default.
Re: (Score:2)
It's a tax on security. I should be able to roll my own cert and at least benefit from crypto. If the nature of my business demands I sign the key I should be able to decide if I want to pay a notary / CA for a signature, or just get all my business contacts to sign it for me.
What I shouldn't have to do is what the current model requires. It's on
Re: (Score:2)
I can roll a PGP key myself and it works of whether I have zero signatures, or multiple signatures. It's up to the recipient to determine if they trust me based on my signatures. The more signatures I have, the harder it is to fake or do a man in the middle, but even zero signatures means protection from casual eavesdropping.
That's how it should be for web certs. Roll your own. At a bare minimum you get encrypted communication. If someone wants mo
Re: (Score:3)
We should all be aware by now that the Root CAs we all know and trust are compromised by NSA and that they can MITM any SSL connection they want at any time.
Bear in mind that the CAs do not have copies of the private keys. When you have a CA sign your cert, you do not send them the private key that you generate. So the CAs cannot give your private key to the NSA to facilitate an MITM attack.
It is possible for them to generate a phoney cert to which they do have the private key, and they could give that priv
Re: (Score:2)
Re:Dump SSL / Certificate-based Security (Score:5, Insightful)
Re: (Score:3, Informative)
From there it's virtually automatic.
Re: (Score:3, Insightful)
As soon as you trust key servers you have the same issue as the root CA's they can be manipulated.
PGP/GPG potentially works rather well, it's weakness is having to move around and validate public keys. The secondary issue is halving to store them on a PC. An opensource smartcard device would seem to deal with the second part. But centralized key stores just beg to be abused.
Re:Dump SSL / Certificate-based Security (Score:4, Informative)
PGP/gpg's weakness is noticeable, but in this case, the perfect is the enemy of the good, and a WoT is the security solution that sucks the least.
Yes, it takes some time to get keys signed, but the advantage of a WoT over SSL is that you can take a couple people whom you never met, but whom your friends trusted, add up their semi-trust, and be pretty sure that an unknown key is genuine.
Re: (Score:2)
PGP/gpg's weakness is noticeable, but in this case, the perfect is the enemy of the good, and a WoT is the security solution that sucks the least.
Yes, it takes some time to get keys signed, but the advantage of a WoT over SSL is that you can take a couple people whom you never met, but whom your friends trusted, add up their semi-trust, and be pretty sure that an unknown key is genuine.
And how long before the NSA just gets court+gag orders that force the members of a target's web of trust to sign their bogus cert? Obviously the more people they do that to, the more likely it is the target will be notified, but I wouldn't put it past them any more.
Re: (Score:2)
Yes, but that is the rub. It is a lot harder for $ADVERSARY [1] to compromise/coerce every endpoint in a transaction than it is to compromise core servers and CAs.
Nothing is 100% secure, and the XKCD cartoon about the $5 wrench does hold true... but good encryption and key management changes things from passive spying to active compromise, which is a lot harder, more expensive, and potentially more detectable.
Moving to a WoT raises the bar, just as using CAs raised the bar to protect against MITM attacks w
Re: (Score:3)
The advantage of key servers is their replication and the fact that keys can be validated to check for tampering. If the key server is damaged and completely compromised with every key on there being swapped out with a bogus key, it will end up being evident when people check signatures and even though the keys on the server might have signing connections, none of the keys have any valid signatures.
Replication also is a good thing. An attacker can add a key with the same name and ID, but not the fingerpri
Re: (Score:2)
You can go even further with requiring the user to approve the key signing even potentially displaying info about whats its doing.
Re: (Score:2)
As soon as you trust key servers you have the same issue as the root CA's they can be manipulated.
PGP/GPG potentially works rather well, it's weakness is having to move around and validate public keys. The secondary issue is halving to store them on a PC. An opensource smartcard device would seem to deal with the second part. But centralized key stores just beg to be abused.
The key servers don't need to be trusted, at least not in the same way that certificate authorities need to be trusted. The keyservers don't do any sort of crypto at all. They simply store keys that users submit to them and retrieve those that users request.
Someone can simply say "Hey, I have a PGP key with $FINGERPRINT. You can get it on the keyserver." and one can retrieve it. It's trivial to validate that a key retrieved from the keyserver matches the fingerprint given by the expected person.
While not im
Re: (Score:2)
And your still back to if you send that fingerprint in the clear along with the message it can be manipulated, or passing them around which is impractical at scale.
Re: (Score:2)
The system works. The real problem is that what grub in the grandparent post calls "virtually automatic" and "boneheaded easy" is still past the skill, understanding, and especially
Re: (Score:2)
If they are going to mitm one way they will do the same on the opposite way, so no you will not know everybody gets messages sources from the key they expected to the key they are using. If you want to get very crafty using a key that is a collision fingerprint would not be impossible, a huge rainbow table would be needed less if you can compromise the rng source.
Re:Dump SSL / Certificate-based Security (Score:5, Insightful)
1. Generate key pairs behind the scenes. There is no value added to my (any user) choosing to manually generate a key pair and manage it. The software should be perfectly capable of generating my personal key pair(s).
2. EVERY email sent should have the sender's public key in the Header, placed there automatically by the email client. No reason any typical user should ever have to see the key block. Public key blocks at the end of your signature are just geek peen waving.
3. Email clients should be able to invisibly read the public key in the header, and add that to the local managed keyring, with no user intervention.
4. Email clients should automatically encrypt emails sent to an address for which it has a public key in the keyring, and automatically decrypt incoming messages.
5. If an email is being sent to an address with no key in the ring, then an initial email should automatically be generated sending a request for that address' public key (of course the sender's public key would be in the sent header). A specially formatted subject line or header value could be implemented so the the receiving email client would automatically respond with the public key, encrypted by the key it received in the header, and the request email need never even show up in the user's inbox. The body of the request message could simply be a request for the receiving user to implement a compliant email client, since the recipient would only see it if they were using a non-compliant client.
6. Upon receiving the response email, the original sender's client could compare the encrypted key it receives against the public key in the header, add the public key for that address to the key ring, and then send the email (encrypted) that the original user wanted to send.
The initial exchange of keys could happen very quickly and entirely automated in the background, so the users never even need to realize it is happening.
Implement these six steps in every email client, and the problem would be mostly solved. Of course, there is the rub. Anything that isn't put seamlessly into Outlook, Gmail, iOS Mail, Yahoo, etc. will never get enough widespread use to be anything but blazing sign that this person has something they want to hide, and are willing to annoy all of their email contacts enough to keep sending requests for public keys. with every message.
Re: (Score:2)
Devil's advocate:
Maybe the mail client should focus on having a layer of security for protecting data and metadata, but the actual message should be handled by PGP, or at least a separate, independent mechanism?
The reason it is good to have message encryption separate is because OpenPGP has been around longer than SSL, and has stood the test of time. A lot of people use webmail, and if all the security is "baked into" the client, all it would take is for an intruder to compromise the webserver, as opposed
Re:Dump SSL / Certificate-based Security (Score:4, Insightful)
The problem with PGP is it makes the end user responsible for key management. End users don't understand encryption. Their needs to be a key management services around PGP to make it viable for mass usage.
Re: (Score:2)
You can have a different set of servers handling the keys and the mail. For example a bank could run a server doing doing key verification and management and then Google handle the mail.
Re: (Score:3)
This is wrong. Everyday users can benefit from PGP. I would venture to say that most people are not as worried about NSA snooping as they are from keeping their personal data stolen by criminals. They may not ask for PGP specifically or understand the details of encryption, but I think your average user would understand the benefit of using email to send sensitive info to the bank, or using electronic methods to discuss sensitive personal medical information with their doctor. Most people instinctively
Re: (Score:2)
2 Trivial to mitm
3 You just inserted the NSA's public key
4 Your happily encrypting the email for the NSA: mitm box
5 Again trivial to mitm
Trust is hard and nearly impossible to automate. PGP/GPG works extremely well in small groups where they can exchange keys face to face, with it's weakness being the machines that store those private keys and the people that own them.
Re: (Score:2)
I actually opened a bug/feature request for Thunderbird to implement creating GPG keys automatically and including them with every outgoing mail by default, but that was sever or eight years ago and it hasn't been acted on. I looked at the source myself to see what was involved, but gave up just trying to compile it for some reason (I forget now...)
Re: (Score:2)
Re: (Score:2)
PGP doesn't trust keyservers; it uses keyservers.
Saying PGP trusts keyservers is like saying HTTPS trusts webservers.
Re: (Score:2)
It trusts that they are giving accurate responses, your communication could be tampered with. They can hold incorrect data. They can be altered by legal means. A whole host of issues. They are more convenient than passing out keys everywhere, but are not going to stand up against state level tampering. HKP spreads the love around a bit, mitm a few thousand key servers is one thing potentially billions is another all together.
Re: (Score:3)
No. Please learn more about PGP.
No OpenPGP implementation assumes that any public keys, no matter where they came from, are accurate. The whole point of signing and the WoT is to not trust any key's accuracy unless you have reason to.
Keyservers can lie to you all day long. You can even manually import totally fraudulent keys, with the intent of deceiving the system. And it still won't matter. None of the keys in question will be trusted one iota, until
Re: (Score:3)
You missed the part where you need to get the key signed, or no one can verify it's actually yours. That's the sticking point.
Re: (Score:2)
The whole idea of keyservers is a big hack anyway due to SMTP having no support for encryption, mixing two entirely different issues. Are you john.doe@gmail.com or are you *that* John Doe that you're looking to mail to. It's gmail.com (verified through domain keys) that should be authoritative as to what your public key is (which you've preferably generated locally and uploaded, but depends on how much you trust the server) while authenticated and that you're talking to the real gmail.com should be verified
Re: (Score:3)
This varies on platform:
On Windows, the port of gpg isn't that great. The best solution is Symantec's PGP, but for a registered version is $250 or so.
The gpg port on OS X is pretty good and constantly updated.
Linux is decent as well.
I do wish Symantec would lower their price on their "Symantec Encryption Desktop", which they renamed PGP Desktop. I'd be pretty sure they would make money hand over fist on volume because a lot of people are security-conscious now.
Re: (Score:2)
Thunderbird provides no way to search PGP emails. Until this long requested featured is added, PGP is not usable when using a Thunderbird client.
Re: (Score:2)
Replay you scenario and assume that there was a man in the middle attack.
MitM is a tolerable default (Score:2)
When I run that sim, as you suggest, the outcome I see is that you have the wrong key for someone's email address. You get MitMed.
(And in spite of the fact that you're being MitM, passive parties who are not involved in the attack, are still locked out. e.g. If the NSA MitMs your email to your wife, other observers are still seeing ciphertext, not plaintext.)
You're no worse off than if you hadn't ever encrypted; i.e. better than the status quo for 99% of users.
Furthermore, if you ever meet the person y
Re: (Score:2)
MiTM responds with his key when you request the key.
The downside is you can't do this over and over again. You want to think through carefully key management and verification so that the system doesn't have to change again once people shift they shift for decades.
Re: (Score:2)
You request the public key from the email address, the MiTM responds with his key...
Re: (Score:2)
That sort of MiTM is fairly common in web transactions. It is often how people's bank accounts get stolen for example. Person goes to the wrong website, has what looks to them like a normal session with their bank and now their account information is stolen. A few days later....
So I think it is a realistic issue.
Re:Dump SSL / Certificate-based Security (Score:4, Insightful)
Is it fair to say that another shortcoming of PGP/GPG is that it encrypts the message body only, leaving the envelope in the clear?
If this is indeed the case then we're right back to the metadata situation where the [who | when | where] I communicate it known, but not necessarily the _what_ (I'm sure the NSA will make up their own justification for _why_ I'm communicating).
Re: (Score:2)
To avoid envelope in the clear that you need to do something like Tor where you have intermediaries and those intermediaries need to be trusted. They also have to be willing to do 2x the current volume of email traffic. Who plays that role?
Re: (Score:2)
Consider that I have a message to send to my brother, and I route it through Tor nodes A, B, and C. I encrypt the message with my brother's public key and recipient address, then encrypt that with node C's public key and recipient address, then node B's public key and recipient address, then node A's public key
Re: (Score:2)
I agree with what you wrote. You'll see something similar one layer below. I don't even think you need A, B and C; A and B are fine as long as you trust A and B. You are right about spam though. The intermediaries could easily block spam at the same time.
My point is the companies with volume capable of handling huge volumes of email are likely susceptible to pressure to hand over keys.
Re: (Score:2)
Is it fair to say that another shortcoming of PGP/GPG is that it encrypts the message body only, leaving the envelope in the clear?
That is actually a short coming of the network itself. In theory, every smart phone or tablet could run its own email server to receive incoming email, so elide the need for the envelope. Still, the network will know which device connected to which other device. Even wireless mesh networks have to exchange routing information between nodes. Even if manufacturers did not include logging source/destination addresses in their devices, it would only take a few "compromised" devices to gather and forward the met
Re: (Score:2)
You could encrypt the headers when transferring mail between servers on the open internet, but ultimately the server itself needs to know the recipient email address. Most use other headers for spam detection too. In any case, the recipient email address is the minimum that must be sent, and some other headers are just implied so don't need to be intercepted to be recreated (timestamp, sending server address).
Re: (Score:2)
The solution is to send the email directly from the sender's PC to the receiver's PC without going through any mail servers.
Re: (Score:3)
I replied above. You can avoid this. Here is how.
A routes to B with an envelope that C can read.
B sends to C who reads the envelope and forwards to D.
B doesn't know where the message was going.
C doesn't know where the message came from.
Re:Dump SSL / Certificate-based Security (Score:4, Informative)
Re: (Score:2)
Unless companies who want their corporate information to remain secret adopt it first and force some progress.
Re: (Score:2)
There's a Twitter/RSS replacement coming up via a Kickstarter (already funded) called Trsst. End to end public/private encryption, and it looks like a good design.
Metadata (Score:2)
right from the white paper (Score:5, Insightful)
SCIMP provides strong encryption, perfect forward secrecy and message authentication.Further, we have incorporated many NIST-approved methods and protocols into its design including:
Does anyone else see a problem with with the wording "NIST-approved methods and protocols?" NIST/NSA [epic.org]
Re: (Score:3)
If law enforcement officers successfully beg a judge, they can order any person or company to do anything they want (like spying on you, becoming an agent of the state). It's as simple as that. Do -not- trust
Re: (Score:2)
Remember that NIST standards and protocols are typically the same one the US requires for it's own use. What your proposing is either that the US would use known bad protocols for it's own use or would be making an epic scale security through obscurity blunder. You can't have a back door that only works for you, if it's in there any given foreign agency could discover it and use it. That simply doesn't pass the sniff test or Occam's razor.
What does concern me with the proposed standard is that they want to
Maybe they should change the name (Score:2)
Re:Maybe they should change the name (Score:4, Informative)
Why call it Dark-Mail?
Because it was better than the first name the came up with. From TechDirt:
Levison joked that they went with "Dark Mail" because "Black Mail" might have negative connotations.
http://www.techdirt.com/articles/20131030/11091025070/dark-mail-alliance-lavabit-silent-circle-team-up-to-try-to-create-surveillance-proof-email.shtml [techdirt.com]
Lovely - now, if they'd only tackle spam ... (Score:3)
In other news, open source community takes another swing at Privacy Enhanced Mail, but this time with no trust anchor ...
I'm still not convinced that anonymity and accountability can coexist. At the very least, they need their servers to be accountable for the anonymity assurances given to their users.
Why DarkMail? (Score:5, Insightful)
Many outlets in the right wing media will have a field day with the name alone.
If one is going to try to occupy the moral high ground the choice of language really matters: you are framing the debate by how you word every single relevant item related to a given project, and which item will have greater visibility than the very name of your project?
By using such a name they are serving in a silver plate the opportunity to malicious, uninformed and naive commentators to badmouth whatever they come up with and that before having put forward a single detailed sentence about the proposal.
DarkMail may sound cool, but from the start is eliciting all the wrong kind of associations, I am sure many parties in the field could be interested to join such an effort, but the DarkMail name alone may put some people off.
The name really should be changed, these battles are difficult as it is, people shouldn't make it unnecessarily harder than it is going to be.
Let me put an example, lets compare these 2 headlines:
"Terrorists confess to using DarkMail"
and
"Terrorists confess to using PrivateMail"
Look, at the end I know it is the same thing, but while a headline would push many to say "yeah, tell me something new" the other may elicit comments of the kind of "What? That is what I use to email my bank"
I really think that name ought to go.
Re: (Score:2)
Re: (Score:2)
You are spot on. However, are we really surprised that folks who previously used names like Lavabit & SilentCircle understand marketing?
Re: (Score:3)
I agree, darkmail makes it sound bad at the start.
But I would go a step further, call it SMTPv2 (if changes to SMTP) or Mail 2.0, or webmail 2.0. A name that has no scariness in it. (other than playing off of web 2.0 crap) It will just sound like the logical next step and doesn't imply anything that the media can take as bad.
It already exits and is free (Score:4, Interesting)
need partners (Score:2)
It's a good concept, but it is based in the US, which means that a) it'll run into the same issues again and b) nobody outside and few inside the US will trust it.
What they need are partners in other jurisdictions. At least one in Europe and one in Asia. A carefully designed corporate structure can delay any legal attacks for long enough for at least one of the nodes to inform its users and shift them towards a node not under attack.
Why do we geeks always think the solution must be technical? Social and leg
Re: (Score:3)
It's a good thing that they already have a theme song. [youtube.com]
Re:LOL Flamebait? (Score:2)
I read the documents. (Score:3)
In p 31 he is asked to hand over the SSL and TLS keys for his service, which in practical terms it would allow the FBI to eavesdrop in the communications of *everybody* at will, this with all certainty would have meant a breach of contract with his users, lawsuits would have ensued. Would the FBI have paid for the damages?
Most importantly Lavabit was willing to comply with the original request, which was limited to a single email account.
You'll have to try harder if you want to dispel the positive aura arou
Re: (Score:2)
Re: (Score:2)
Well, the NSA has already cracked it. I can see your posts now . . . .
Re: (Score:2)
Ease of use. ....
Consistent protocol for exchange of encrypted mail (which could be based on PGP).
Key decentralization and anonymitation
Using PGP is a PITA in most stand alone systems (Windows, OSX, Linux) relies in way too much trust as well (how do you know that PGP key is legit?), and it isn't implemented at all in big emailers (Gmail, Yahoo Mail, Microsoft's whatever it is called this week, etc).
Re: (Score:2)
PGP has one advantage -- it is completely separate and standalone from whatever messaging system is in use. Yes, metadata can be compromised, but the actual messages would be protected no matter how hosed the underlying protocol is.
In the past, I've used a lot of protocols to send PGP/gpg encrypted messages, be it AIM, UNIX ntalk, mail or write.
However, you are right. It is a separate step, and likely to a different app. However, it is good in a way that PGP is separate from the message medium.
Re: (Score:2)
Even with PGP, the SMPT headers are unencrypted. This allows an attacker to build a graph of who talks to who. The central weakness of traditional email is that messages are passed around through multiple untrusted servers before they reach their destination.
This system depends on creating an encrypted link (presumably with tor-like indirection) and only passing messages direct from sender to receiver. The downside is that both parties have to be online to effect the transfer. The instant messaging aspect i
Re: (Score:2)
It's a central problem if you want two arbitrary people to talk to each other. Or if you just want to do a "blind broadcast".
Which makes those hacks to AIS and ADS-B really uninteresting because encrypting and authenticating the transfers is impossible