(untitled)

hello security... people. i don't know jack soykaf about any of this. i got a protonmail email because i figured it would be good, but now that i'm looking into this more, i don't really trust them. what's a good alternative? i went on thatoneprivacysite.com and those big charts led me to believe that msgsafe.io would be a good bet. you guys know more about this than i do, what are your recommendations? what do i need to consider the most?

don't trust your email. PGP encrypt anything important.

First, yes, use PGP/GPG with your friends like >>6381 says. Second: https://podricing.pw/posts/1104897 https://posteo.de/en - Those one is even recommended by the FSF! Very cheap. Works with Libre.js https://tutanota.com/ - Sever is free software, phone client apps do not appear to be. https://mailbox.org/en/ - I know nothing about this one. https://cock.li/ - Addresses are intentionally offensive, good service. https://teknik.io/ - Also has other free stuff like Mumble and Git. https://disroot.org/ - Seems to be for activists, also has other free stuff. https://www.fastmail.com/ - Paid, but many people in the threads recommend it. https://mailfence.com/ - Says it has good legal protection. https://www.inventati.org/ - This one is weird, it seems you have to have the same morales as them to get through the account screening. https://riseup.net/ - Same as above. Also has Jabber and Pastebin.

>>6382 posteo is in germany, which means it's in one of the eyes countries. isn't that a bad thing?

>>6381 PGP is useless 99%of the time because the person you want to email doesn't use PGP. That less than 1% of the population who do use PGP are in a bubble that has more efficient ways of communication. No email provider can be trusted because they are far away people and you can't look in their minds. The rest is lottery. This post may seem pessimistic and void of advice, but it's actually pretty helpful. It helps OP avoid being lulled into the false security of any brand, and gives a clear understanding of how things are.

>>6387 PGP is useful for its use case. Anybody who wants to set up an encrypted channel have a PGP keypair they can give you.

>>6380 >but now that i'm looking into this more, i don't really trust them. care to elaborate on this? i'm a user since 2016 and have no complaints. >inb4 israeli contractor no.

>>6392 Not OP but there was a hoax that they (protonmail) got hacked recently and the hackers had access to user data. Never confirmed as real and the hacker's threats seemed baseless. The hoax probably tipped over some folks that were already on the fence about protonmail.

>>6392 He's right not to. https://eprint.iacr.org/2018/1121.pdf

>>6400 Thanks for posting a useful evaluation.

What is the best / secure / free email service you like to use?

1. Tutanota - Cheap 2. Protonmail - Free, but probably not secure. 3. Riseup - Free but you need an invite 4. Autistici/Imventani - Free but you must be approved. 5. Cock.li - Free (and offensive) 6. Disroot - Free but you must be approved 7. And ofc host your own

Also see >>6380

>>6438 I've been using tutanota for about 2 1/2 years now. normal people are at least familiar with proton, but I have not come across one other person irl that has even heard of tutanota. That's what I use for my personal, *personal* email, which I do not give out except where absolutely necessary. I use proton accounts for amazon purchases, reddit, etc. and gmx burner accounts for /osint/ profiles.

I switched from gmail to protonmail because I don't want Google reading my emails, or connecting the dots via metadata to build a profile of me as an internet user. I don't email people (well, rarely), and I just use it for banking, buying stuff, mailing lists, etc. Given the above threat model, would you still not recommend protonmail? If I needed 100% secure communication, I could always encrypt the message, or use Signal or something. I've already made the change to protonmail so I'd rather not go through all my logins again and change them, but if a compelling case can be made (sorry, I can't be fuarrrked to read that cryptographic analysis pdf), I'd consider switching to something else.

>>6400 This is actually huge. Why haven't i read this before? For everyone using Protonmail this is must read.

>>6467 >Why haven't i read this before? It literally just came out.

>>6451 "personal" email means self-hosted?

>>6465 I'm pretty much in the same boat as you. I skimmed through the PDF and it really isn't that much of a concern to me. I don't even use encrypted communications (like PGP) because no one I know uses it, I just wanted an email provider that wasn't an analytics company, or if they are they're certainly not one of the big ones. I've used tutanota before as well but I found the interface (web + android app) really clunkly and not difficult to use, but unintuitive. Maybe that's changed I'm not sure. Recently I have been having doubts about Protonmail but I don't see how Tutanota isn't affected my similar issues (maybe someone can call me out on being wrong here).

>>6387 Precisely this. There really is no benefit to using these "secure" emails unless the person you're emailing is using them as well or is willing to at least go through the hassle of using the key. By its nature email is insecure and while I am by no means advising you use Gmail, I think it is wise to at least be aware that there is virtually no security in place for emailing.

>>6438 What about dismail?

>>6438 Cock.li looks pretty cool. I like how they publish subpoenas they are sent. I am however sad that people can sick the DoD on other people because someone said mean words to them. The picture is a snippet from one such request.

>>6382 >https://www.fastmail.com/ - Paid, but many people in the threads recommend it. Im a very long time FM user - since near day 1. They are a good email service - but in NO WAY are they privet - they are Australia now (think they stared as Canadian) and all data basically goes to the gov.

>>6382 >https://www.fastmail.com/ - Paid, but many people in the threads recommend it. I use it, and it is indeed a very good service. They rigorously stick to open standards for connectivity. Not just imap/smtp, but also carddav, caldav, and webdav, all with rugged TLS. They also enforce a policy where all logins (aside from on the website itself) must be made with single-purpose passwords generated within the security settings on the website, and they're revocable on the website. This makes it easy to not only kill access to a stolen device, but prevent the thief from ever finding out your website password because it's never even stored on the device. Those disposable passwords can even be set on a per-protocol basis. But it should be noted that they're *secure*, not *private*. In all other respects they're a normal email service. They scan messages for spam and malware, and their admins have full access to all the email, files, contacts, and calendars stored with them. And even though their servers are in New York, they're an Australia-based business, with all the legal implications that entails. Fastmail might be fine for one person's threat model. It might not be fine for another person's threat model. It's up to the individual to decide.

>>6382 >mailbox.org In the process of switching from Fastmail to Mailbox.org right now. Mailbox takes security seriously and they actually promote PGP encryption and make it easier for less experienced people to use, because of course you can't use PGP if your recipient doesn't either. https://mailbox.org/en/security#encryption

>>6381 But then wouldn't using any email as long as they don't ask for personally verifiable information fine then?

>>6380 >>6400 It's important to understand what this means because this report has been taken hysterically. The paper is broadly correct in its analysis and interpretation, but that doesn't mean Protonmail is untrustworthy or broken now, and it doesn't mean Protonmail does not have end to end encryption. Protonmail is PGP under the hood. It is exactly as good as any mail service with PGP, with some important caveats. First, almost everyone uses the webmail service. It would be easy to implement the webapp as a signed browser extension, but for some reason, they don't. Unsigned webapps can have their code swapped out by a malicious server, or someone can pose as the Protonmail server with a fraudulent cert. Don't use the webapp. Do not use webmail, period. All webmail PGP has this problem. This scenario is not a breaking of end to end encryption, but more like a compromised endpoint. It's just particularly easy for a malicious server to compromise the endpoint, due to a bad software distribution system: webapps. The article raises the important point that, because the ProtonMail server stores private keys, they can be stolen. Furthermore, a compromised web client can steal your password, use that to get your key, and decrypt all past, present, and future messages. Anyone who has control of the Protonmail server can steal passwords from web clients and steal encrypted private keys. This is a problem with Protonmail, and I agree with the article that PGP keys should always only be stored on the clientside. You can mitigate the risk by never touching the web client. The article says that their outbound encrypted mail system also has the problem that it is a webapp. This is true. Protonmail has outbound PGP now, so use that instead. It also raises the point that they don't use enough bcrypt rounds. This is fair. So Protonmail isn't broken, but it's not ideal. Risk can be mitigated on Protonmail in the same way you mitigate it with everything else. Don't use the webapp, layer PGP on the clientside. If you really care about privacy, don't use email, use Signal. Other end to end encrypted webmail providers aren't worse than Protonmail either. Tutanota is very good. The various anarchist email services (Riseup, Autistici, Disroot) have a long history of defending their users (although Autistici had a database breach a little while ago). But don't use their webmail clients. Everyone in this thread promoting different webmail clients with end to end encryption failed to understand the implications of the paper. Protonmail isn't broken, webmail is broken.

>>7817 Nice post, thank you for the detailed response. Inherently, aren't we taking risks by trusting the provider to handle encryption for us? Granted, that's why you said to layer, which I 100% agree with. IMHO, if you didn't make the keys, you can't assure confidentiality.

>>7819 >Inherently, aren't we taking risks by trusting the provider to handle encryption for us? It depends what you mean by that. If I interpret it literally, as in the email provider is doing the encryption of messages on the serverside, then yes. You would be putting full trust in the provider, and the point of PGP would be mostly defeated. However, it wouldn't be correct to say Protonmail works this way. Not exactly. The webmail client works a lot like this, because you are basically taking whatever code they give you and running it without validation every time you load the page. Encryption isn't happening on the serverside, but it might as well be, because you have about as much certainty that it's doing what you think it's doing with your passwords, messages, and keys. The desktop and mobile clients do not work like this. Keys are only stored by the server, encrypted. They are not known to the server. As above, this is still a problem, but not quite as severe of one as you might be led to believe. When you log in, you receive your key and decrypt it on the clientside. You are handling your own encryption. The server does not receive your password, only the proof that it is correct, so you can be confident that the server cannot decrypt your private key. How much you trust the software that handles your encryption is another matter. You have different assurances based on how you get it. If you download the binary from their website and install it, that's barely better than the webapp, because you have no assurance (other than their signature, which you probably didn't even bother to check) that the app is valid. If Protonmail is a potential adversary in your threat model, or a potential adversary has stolen their signing key (I assume they're well-guarded but you never know), or you don't check the signature against a public key you've acquired from somewhere you trust, you have very little confidence that nobody slipped in malicious code. Don't install untrusted binaries. If you download an app from the Play store or F-Droid, you get a signed version, and the signature will be checked against the store's record. This is pretty decent. You can be reasonably confident that you have the app they gave the store, or the store and an adversary are conspiring against you specifically. This is unlikely, so long as you're not considered a threat to national security. Google would be undermining the trust of all of its users by doing this, for instance, so it would have to be a really big deal. Either every user is equally compromised, or every user is equally safe. If you download a binary from your distribution's package manager, depending on the distribution, it's been signed by a maintainer who compiled it themself. This is a really good assurance, particularly if your distribution is Debian (which is enforcing reproducible builds, so offers some guarantee that the binary is valid without having to trust the maintainter) or Guix (which offers even stronger assurances of validity). If you compile either the app or desktop program yourself, you can be pretty confident it's exactly the source code you got. Since all of Protonmail's clientside software is FOSS, you can do this. If you are certain that your software is exactly what was described by the source, then all you have to trust is the source, which, according to security audits, has a correct implementation of PGP and their ZKPP. If you are referring to a threat model where, because the service that hosts your mail is also the service that developed the clientside software, you might be fuarrrked even if they disclose the source and it's been audited, that's a really extreme threat model, and if you think that's the kind of risk you've taken on, you shouldn't be putting your trust in email. >IMHO, if you didn't make the keys, you can't assure confidentiality. This is 100% correct, however, with Protonmail, you do make the keys. Keys are generated on the clientside at the moment of account creation, and are only sent to the server encrypted. If you're using the webapp to set up your account that's still a problem (because, as above, the code is untrusted), but if you use the app or desktop program, that's not a problem. I will add that all the similar email services recommended in this thread are good, so long as they have FOSS desktop and mobile applications that handle account creation and offer similar assurances. I haven't tried them so I don't know. However, PGP alone is a profoundly imperfect method. Sometimes you need email, but when you don't, it's best avoided. Use a FOSS application with forward secrecy instead. This can be either Signal or good old fashioned XMPP+OTR (with logging to /tmp and /tmp on a RAMdisk). Nothing else compares at this point. Short digression on logging: Chelsea Manning and Julian Assange communicated using XMPP+OTR. This was a good call. OTR doesn't preserve chatlogs past the duration of the session, and that's good, but some implementations only delete the logs once the session is over (or use a tmpfs system to store them). Anyone who knows how ordinary deletion works should recognize a problem. The logs were likely written to disk, but then were only dereferenced by the filesystem, not overwritten. This is likely how they were "forensically recovered" so investigators could find out that they briefly discussed cracking password hashes. If you are using XMPP+OTR, and not a packaged solution like Signal, you are responsible for making sure the logs are handled correctly. Ideally, they should never leave RAM. If they do leave RAM, shred, don't delete. If you have any worry that your device might be stolen or confiscated, make sure you are handling your data properly.

>>7820 Damn, lainon, thank you again for the detailed response! > Anyone who knows how ordinary deletion works should recognize a problem. The logs were likely written to disk, but then were only dereferenced by the filesystem, not overwritten. I'm right there with you, it can be easily overlooked but completely screw you. Shift+Del has saved no one. Excellent point with: >Use a FOSS application with forward secrecy instead. This can be either Signal or good old fashioned XMPP+OTR (with logging to /tmp and /tmp on a RAMdisk). Nothing else compares at this point.

I personally use autistici.org. You just gotta send them an application where you "aree" with their requirements. Your mail also works as a jabber account.

>>7830 agree*

>>7829 No problem. I like being informative. Actually I have one correction: >if you use the app or desktop program, that's not a problem It's still not good that Protonmail has custody of your private keys, even encrypted. Just not as bad as them being able to see your private keys. >>7831 And this is why Riseup uses invite codes. Just please treat the service with respect while you're using it. They don't have a lot of resources and they're providing an important service.