7 ms·
miniLock [1] seems like a good alternative to PGP for both file encryption and email. It's just so new and it should have more audits. [1] - http://minilock.io
by higherpurpose 12y ago
miniLock [1] seems like a good alternative to PGP for both file encryption and email. It's just so new and it should have more audits.
[1] - http://minilock.io/ http://minilock.io/
They've recently launched Peerio as well which is kind of a closed email-like system with easy to use end-to-end encryption based on miniLock.
https://peerio.com/ https://peerio.com/
- tptacek 12y agoFrom the team that brought you Cryptocat.
- proveanegative 12y agoWould you recommend against using the current version of Cryptocat?
- tptacek 12y agoDon't use Cryptocat.
- LeoPanthera 12y agoAnd yet the EFF gives Cryptocat top marks: https://www.eff.org/secure-messaging-scorecard https://www.eff.org/secure-messaging-scorecard
- tptacek 12y agoYes, that EFF scorecard is terrible.
- stinkytaco 12y agoCare to elaborate on that? I'm in the habit of more or less trusting the EFF, but I don't use cryptocat (no need for it) and I have heard that it is insecure. My understanding (possibly flawed), is that it was mostly tied to the JS Crypto implementation. What about the rest of the scorecard?
- tptacek 12y agoYou can look around for what other crypto and security people thought of the EFF scorecard. It was not well-regarded. They factored the JS into a Chrome application awhile back, and while Chrome-extension JS crypto isn't particular safe either (there are realistic side-channel attacks on it), it's not the cluster•••• that content-controlled JS crypto is. There are much, much bigger problems with Cryptocat than Javascript. I would also recommend avoiding the mobile apps, which are native.
- woah 12y agoPray tell
- Strom 12y agoThis is a good post pointing out some of the problems with CryptoCat http://tobtu.com/decryptocat.php http://tobtu.com/decryptocat.php
- DanBC 12y agoThat scorecard carefully says that it's not an endorsement of any product yet here in this thread we have someone using it as an endorsement of a product. The scorecard lists "good features" and gives you a tick if you claim to offer that feature. The score card does not currently test any of those and certainly hasn't tested the auditing or done their own audit.
- jMyles 12y agoI'm ready to show my ignorance. Cryptocat bad? I had been using it to help people get their feet wet for OTR. What must I read?
- tptacek 12y agoJust use OTR. ChatSecure on iOS is fine. Cryptocat is not safe.
- redthrow 12y agoIs there anything bad about telling people to ignore PGP/GnuPG altogether and use OTR/TextSecure?
- e12e 12y agoYou can't use OTR for email. Well not in a meaningful way, anyway. I think the article[ed:1] misses the point, btw. Yes, managing keys might be tricky - but it's not really rocket science. The thing that's hard is managing trust -- which key one trusts etc. The CA system for web is completely broken. I had some hope for cacert.org -- I think that model (perhaps expanded to include recommending signing gpg-keys as well as x509 certs) has a lot of merit. I think web of trust is the only thing that can work for managing trust. But it needs to be accessible. Have post offices and banks sign gpg keys on when people come in with valid id. Cacert is a different take -- I like to look on it as a "strucutred eternal keysigning party". I trust that model a lot more than the classic CA model. But as it is based on the CA model, it suffers the same problems with centralized trust. Centralized trust is great for organizations, it's not so great for individuals. I think the best model would be a world-wide web of trust for gpg, helped by formal and informal signing organizations (ie: like cacert, signinparties -- and with the help of banks, governments, DMV and similar institutions that traditionally help with issuing IDs). Then there should be support for anchoring DNS/CAs (and CAs for openssh) with gpg. So that if you trust someone is a representative of an organization linked to a domain name, you can trust them to autorize a CA for that name (there's technical details here, but I think the idea should be clear enough). CAs go away, everyone can sign their own certs -- and there's an easy way to link x509 and gpg trust. People will still lose their keys, and get invalid keys signed etc -- key management is hard. But the really confounding thing is trust -- and knowing how to determine which keys are "proper" keys for a given entity. That's really trust management, not (just) key management. [ed:1 whops, that was the other article on making key management easy ;-) But I suppose this comment is relevant wrt how to make encryption more readily available...]