Slashdot Mirror

← Back to Stories (view on slashdot.org)

Silent Circle, Lavabit Unite For 'Dark Mail' Encrypted Email Project

Posted by timothy on from the it's-so-spooky dept.

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."

42 of 195 comments (clear)

  1. Did the NSA just kill SMTP? by Defenestrar · · Score: 5, Interesting

    It's been around for what, 40 years? Working, (relatively) anonymous, and totally insecure mail transfer with tons of inertia. Never thought I'd see the day where there might be a small sliver of opportunity for another protocol to actually happen. Ars has a nice article about it too.

    1. Re:Did the NSA just kill SMTP? by Vanderhoth · · Score: 5, Insightful

      There is the added advantage that if everything is encrypted, and snoopers had to decrypt everything to find something of value, it would be a serious drain on their resources. On the flip side, if everything, except that which absolutely required encryption, was sent in and easily accessible format then encrypted messages are a big red flag that says "Look at me I'm important!!", which allows snoopers to be selective about where they spend their resources. But that's just my take on it.

    2. Re:Did the NSA just kill SMTP? by jones_supa · · Score: 4, 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.

    3. Re:Did the NSA just kill SMTP? by mlts · · Score: 3, 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.

    4. Re:Did the NSA just kill SMTP? by V+for+Vendetta · · Score: 3, Informative

      They want to build it upon XMPP, according to the Ars article I read earlier this day.

    5. Re:Did the NSA just kill SMTP? by UnderCoverPenguin · · Score: 4, 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))

      --
      Don't try to out wierd me, three-eyes. I get stranger things than you, free with my breakfast cereal. --Zaphod Beeblebr
    6. Re:Did the NSA just kill SMTP? by dpilot · · Score: 3, 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.

      --
      The living have better things to do than to continue hating the dead.
  2. Another mail protocol by gmuslera · · Score: 4, Interesting

    This one with security/encryption built in from the ground up this time. Would be more interesting that instead of the comments of Microsoft (with deep ties with the NSA), yahoo and google (both may not be very happy with the NSA, but still must give them their users accounts info by law) the article focused on comments from people from i.e. the IETF for implementing it as an standard in a more worldwide (even personal) way.

  3. Dump SSL / Certificate-based Security by Anonymous Coward · · 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.

    1. Re:Dump SSL / Certificate-based Security by CimmerianX · · Score: 4, Insightful

      Problem with PGP/GPG is that the tech concept is beyond many end users. If a solution is not easily adopted by the noobish masses, it will never gain a foothold.

    2. Re:Dump SSL / Certificate-based Security by grub · · Score: 3, Informative

      PGP/GPG is boneheaded easy to use these days. Generate a keypair, uploaded to the keyservers automatically, install mail plug in.
      From there it's virtually automatic.

      --
      Trolling is a art,
    3. Re:Dump SSL / Certificate-based Security by landoltjp · · Score: 3, 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).

    4. Re:Dump SSL / Certificate-based Security by silas_moeckel · · Score: 2, 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.

      --
      No sir I dont like it.
    5. Re:Dump SSL / Certificate-based Security by SirGarlon · · Score: 2

      Generate a keypair, uploaded to the keyservers automatically, install mail plug in.

      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.

      --
      [Sir Garlon] is the marvellest knight that is now living, for he destroyeth many good knights, for he goeth invisible.
    6. Re:Dump SSL / Certificate-based Security by davecb · · Score: 3, Informative

      PGP's author is somewhat aware of that (;-)) He's a principal at Silent Circle

      --
      davecb@spamcop.net
    7. Re:Dump SSL / Certificate-based Security by DrXym · · Score: 2
      It's too bad http doesn't dump CAs as well, or rather the rigid model that is adopted now. It's basically a tax on security and clearly many sites choose to have no encryption at all rather than pay this tax. So any site should be able to present an unsigned key to a browser and and instantly benefit from encryption. The browser shouldn't object to this either (unless the site used to present a signed cert) since it is still better than plain text even if it permits man in the middle attacks.

      And if a site wants something more then they should be able to have their key signed by their buddies, business partners, trade associations, governments, and yes even CAs to build a web of trust. So a bank might well pay a CA for a signature, but it might also get a signature from its banking federation, it's rival / partner banks, the government, and a business bureau. If the cert suddenly changes, or if any of the signatures mysteriously change then the browser has the knowledge necessary to warn a user. That makes it far harder to compromise the security. It also means that no site has to pay a CA for the privilege of security. It might be advantageous to do it for a bank or suchlike, but smaller operations would build out a more organic trust model.

      How a browser presents this information falls outside of this. I don't see it being especially different from how browsers present this information now except it would be more important to users to know when the information changes, rather than when it doesn't.

    8. Re:Dump SSL / Certificate-based Security by mlts · · Score: 3, 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.

    9. Re:Dump SSL / Certificate-based Security by mlts · · Score: 2

      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 fingerprint. If someone deletes keys on one keyserver, it only will affect that keyserver. To remove a key requires hacking all the keyservers that replicate with each other, and then, if just one has the key, it will re-replicate.

      Endpoint weakness is also important, and a good point. There are cryptographic tokens, but GPG realistically doesn't support them (I've tried), so one would have to use the commercial version of Symantec's product to generate/store/use tokens. However, tokens do provide a security increase since the key never leaves the device, and the device does the signing/decryption.

      What I'd like to see is an "open source" cryptographic token that can work with gpg. This way, the worst an attacker can do is intercept the token's PIN and generate a bogus signature, but the key material is kept secure regardless.

    10. Re:Dump SSL / Certificate-based Security by mlts · · Score: 2

      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.

    11. Re:Dump SSL / Certificate-based Security by CreatureComfort · · Score: 4, Insightful

      Bonehead easier would be better.

      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.

      --
      "Unheard of means only it's undreamed of yet,
      Impossible means not yet done." ~~ Julia Ecklar
    12. Re:Dump SSL / Certificate-based Security by heypete · · Score: 3, Informative

      StartSSL 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.

    13. Re:Dump SSL / Certificate-based Security by Bob9113 · · Score: 2

      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 private key to the NSA. But that would be detectable by programs like The Eff's Observatory, which monitors for key changes. If they tried a MITM attack with a monitored site on any significant scale, it would be detected (and you can run your own plugin if you want).

      The problem with both Silent Circle and Lavabit is not SSL itself, but that they are a central organization that held the private key to many people's comm -- people who wanted strong security on their comm. That is a huge bank of high-value cleartext; an irresistable resource node to a group like the NSA. The root problem is not Root CAs, but centralized "secure" storage (and a government that has betrayed its nation -- though even without the NSA, those irresistable resource nodes would still be a threat, attracting abuse from the likes of China and Facebook).

      But I digress. My point is that SSL can actually allow true end-to-end security, as long as we use a "trust but verify" model, like the Observatory allows, not just blind trust. If we want to eliminate the high risk behavior that enabled the NSA's attack, we have to eliminate centralized "secure" stores -- no more unencrypted cloud storage, and no more password recovery from cloud services. Everyone has to manage their own private key (whether SSL, GPG, or other), and losing it means it's gone forever. To me, that's the big hurdle.

      Alternately, we could restore the 4th amendment, which does a pretty damned good job of protecting your house, even though locksmiths may have copies of many private keys and anyone with a little training could break into most houses in a matter of seconds. Since keys and locks existed when the intent of the 4th was still well known and agreed, they have the level of government protection that encryption should have. Well, that and it would be hard for the NSA to break into every house; it's easy to break into everyone's email. Even if we all had our own private keys, it would still be easier to break into all our systems than doing houses. Now I'm really off on a tangent, though, so I'm just going to stop here.

      --
      Stop-Prism.org: Opt Out of Surveillance
    14. Re:Dump SSL / Certificate-based Security by jbolden · · Score: 3, 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.

    15. Re:Dump SSL / Certificate-based Security by jbolden · · Score: 2

      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.

    16. Re:Dump SSL / Certificate-based Security by hodet · · Score: 2

      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 know not to use email for this without even realizing there are ways to do it securely. It's the implementation of it that leaves them cold. Small business are another segment that could benefit from it but just can't wrap their heads around it. An easy to use implementation that provided secure communication would see some uptake among people you wouldn't consider actually needing it today.

    17. Re:Dump SSL / Certificate-based Security by Cajun+Hell · · Score: 2

      It trusts that they are giving accurate responses

      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 you look at a fingerprint and sign, essentially saying "Yes, I know for sure that fingerprint came from that person."

      PGP does not trust keyservers to be accurate, to be working right, to be working in good faith, to not be owned by your adversary, or anything else. Keyservers are a convenience, and nothing more. All this kind of stuff was figured out and dealt with, decades ago.

      --
      "Believe me!" -- Donald Trump
  4. Re:LOL by lxs · · Score: 2

    It's a good thing that they already have a theme song.

  5. Thanks Snowden by Jakosa · · Score: 5, Interesting

    When I first saw the Snowden-film from Hong Kong I thought: "damn! he has forfeited his life and nobody will care. And now this! Not only has he shaken the political world-society, he has also aroused the tech-world and made it possible to make some major changes. Hope I will be running this new protocol by next year and be able to send super-secret Christmas-cards to the select few who is also using it!

    1. Re:Thanks Snowden by cffrost · · Score: 2

      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 mentioning that in a GCHQ slide provided by Snowden, they admitted "Tor stinks" because they "can't identify all users all the time, but can identify some users some of the time." — GCHQ/NSA really appreciates docile/ignorant users who stick with plain ol' HTTP so they can be identified all of the time.

      I transfer several GB/day via Tor, and an order-of-magnitude more of encrypted BT traffic daily; I like to think that as an individual, I'm providing a substantial level of cover for people whose lives/freedom depend on the integrity of their encrypted connections: Journalists, dissidents, whistle-blowers, people in fear of being attacked by the corrupt DEA/BATFE/FBI/etc., gangs of thugs-in-uniform with their "parallel construction," planted evidence, personal vendettas, etc., a danger to which everyone within their reach is vulnerable to, provided they're not among (or sufficiently connected to) the "ruling class:" political elites, the very rich, etc., plus LEOs themselves. No one in this vast under-class is immune to false accusations, wrongful conviction, and having their lives destroyed by the violently aggressive US injustice system.

      I'm also hoping to help protect other people who, like myself, simply don't enjoy having our human right to privacy, or our Fourth Amendment rights against unwarranted collection/examination of our private data being violated by criminal voyeurs in government, nor commercial entities that I paid to deliver data, not to examine/profile/monetize it (then turn around and sell it to the government).

      --
      Thank you, Edward Snowden.

      "Arguments from authority are worthless." —Carl Sagan
  6. right from the white paper by imatter · · 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:

    • Elliptic Curve Diffie–Hellman (ECDH), NIST 800-56A
    • Counter with CBC-MAC (CCM), NIST 800-38C
    • Key Derivation, NIST 800-108
    • Secure Hash Standard, FIPS 180-4
    • Advanced Encryption Standard (AES), FIPS 197

    Does anyone else see a problem with with the wording "NIST-approved methods and protocols?" NIST/NSA

    1. Re:right from the white paper by inject_hotmail.com · · Score: 2
      I do. 99% of all people have a seriously misguided concept of trust. Companies and citizens alike cannot maintain an allegiance to any person because they must bend to the will of law enforcement (notice I did not say 'law') and judicial commands (yes, it actually says "commands" in a subpoena).

      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 anyone. If they have been subverted, you will not know until it is too late...Ladar Levison wanted nothing but to maintain Lavabit -- his own business predicated on security/secrecy (when it came out that he handed over SSL keys to authorities, no matter the reason, his business would crumble). The (federal) state compelled its demise under threat of -perpetual- imprisonment and fine, and so it fell.

      Having said all that, even a non-NIST entity cannot be trusted. If a non-NIST crypto protocol contains any weaknesses, whether intentional or not, assuredly the NSA will obtain or discover it.

  7. Maybe they should change the name by Jakosa · · Score: 2

    Why call it Dark-Mail? Grandma should be able to use... Dark Mail? Like she was a Sith-lord. What about PBP Pretty Better Privacy?

    1. Re:Maybe they should change the name by c0d3g33k · · Score: 3, 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

  8. Re:Called it by Alain+Williams · · 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. 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.

  9. Lovely - now, if they'd only tackle spam ... by eer · · Score: 2

    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.

  10. Re:Called it by slashmydots · · Score: 5, Funny

    I knew you were going to post that.

  11. Why DarkMail? by jotaeleemeese · · Score: 4, 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.

    --
    IANAL but write like a drunk one.
    1. Re:Why DarkMail? by G00F · · Score: 2

      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.

      --
      The spirit of resistance to government is so valuable on certain occasions that I wish it to be always kept alive
  12. I read the documents. by jotaeleemeese · · Score: 2

    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 around Ladar..

    --
    IANAL but write like a drunk one.
  13. Re:Called it by BitZtream · · Score: 2

    IPSec was an international effort ...

    --
    Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
  14. It already exits and is free by shellster_dude · · Score: 3, Interesting

    Bitmessage: P2P, encrypted, anonymous. The project is pretty new, but other than a couple scalability issues, I think this project has major potential. http://bitmessage.org/

  15. Crimonelly! by ThatsNotPudding · · Score: 2

    Would be more interesting that instead of the comments of Microsoft (with deep ties with the NSA), yahoo and google (both may not be very happy with the NSA, but still must give them their users accounts info by law) the article focused on comments from people from i.e. the IETF for implementing it as an standard in a more worldwide (even personal) way.

    Congrats: your sentence is thoroughly encrypted!