Proton Mail discloses user data leading to arrest in Spain(restoreprivacy.com) |
Proton Mail discloses user data leading to arrest in Spain(restoreprivacy.com) |
It is not up to corporations to decide which laws should be enforced, and this again shows how futile this specific kind of corporate resistence is.
Just change the law.
> In the police cooperation form requesting the information, the Spanish officers indicate to the Swiss authorities that the investigation is for the crime of terrorism.
What if my recovery email is to another proton mail account? What if my VPN used is Proton VPN?
Both ProtonMail and Apple will challenge subpoenas when they believe they are not valid, however neither company has the final say in the matter and can be compelled to provide access to data that they reasonably have access to. It is up to the user to plan what information they provide to service provides in order to not leave a trail of crumbs, and also evaluate what kind of man-in-the-middle weaknesses a service might have for the possibility of wiretapping. It should go without saying that linking a phone number or back-up email address can be a pretty large crumb.
The learning here is to recognise that these services can be compelled to provide whatever small information that they have reasonable access to, and that this information may be useful in unmasking an identity.
I suppose the second learning is to elect governments which respect democratic freedoms, even if that puts them on the back foot.
The whole controversy surrounding Proton started when they marketed themselves as "secure and private email", promising they would NEVER give away their users' data, until they did. I had a similar discussion with my friends today about this topic and the issue I have with it is that Proton tries to market itself as an email which will never snitch your data to the authorities. And we've seen countless times (they have provided data to almost 6k requests last year) that this isn't the case.
The problem as I see it is that Proton is not even trying to challenge the requests anymore. It's not like Tuta, who you can read on the news that they keep challenging almost every order they get from the authorities, even if they lose the battle in court: https://techcrunch.com/2020/12/08/german-secure-email-provid...
As I read on a website comparing "private email services", the question here is not whether a service provider will or will not abide by the court requests. It's whether it will do anything to challenge it or just giveaway the data without questions asked.
https://proton.me/legal/privacy
https://proton.me/legal/transparency
I standby the assertion that people will believe what they want to, despite there being easily accessible information that contradicts those ideas.
The only option for getting your email _out_ of their systems is to select small batches of them one-by-one in their app and export them.
There have been many requests for something similar to Proton’s bridge functionality that haven’t gone anywhere. A more useful export function has been near the top of their public roadmap[0] for half a decade now it looks like.[1]
Guess I’ll go find out what their refund process is like.
Don’t mind me. Just yelling into the void.
[0] https://tuta.com/roadmap/ [1] https://github.com/tutao/tutanota/issues/1292
You store my access times and IP addresses? I should see that.
I think this would align well with GDPR, too.
And therein lies the problem. We on HN may have a few ideas about how to do this, but the typical user of a secure email/VPN/tor unfortunately doesn’t and realistically can’t understand the corner cases and tricks.
Realistically, even HN users would make enough mistakes.
This is why I’m dubious of these types of products marketing to average consumers
Democratic freedoms, in the United States at least, protect people from UNREASONABLE search and seizure.
Compelling a third party to reveal information about a customer via a court order is not now, has never been, and will never be until the end of time and space, unreasonable.
The order itself might be unreasonable and should be challenged if so, but the procedure and ability to do so is not and will never be.
Its unreasonable if the standards for issuing the court order (as applied, even if not in theory) are unreasonable.
And that is often now, and has often been, and will often be (likely until the end of human history), unreasonable.
They should not be able to push a button and learn everything about a person. If they want to learn about an individual's private life, they should have to get a warrant then put people to work on the guy's case. They should have to literally follow their targets, photograph them, put hardware keyloggers into their keyboards. That sort of hardship imposes natural limits on the scale of their operations: there are only so many police officers you can assign. With computerized dragnet surveillance, the scale of their operations is essentially limitless.
These encrypted communications services aren't generally in the business of going to jail in their customer's place. They gotta comply with the government laws. When a court orders them to do something, they either obey or they are held in contempt of court if not worse. It can't be helped. It's still helping reduce global surveillance by forcing them to target their attacks.
You're conflating what's written in the law and the sad reality of how a lot of that is simply ignored by law enforcement, while they are standing on your neck, searching your car.
This will _never_ happen. It's the human condition....
Admittedly this is not really an easy solution with something as open as emails, it's possible within corporations but I don't know of a solution between "random" people.
But outside of email and things that have to be unencrypted for interoperability, everything should be encrypted and inaccessible to the company so this situation is impossible.
I think the ship has sailed on the idea of electing people who will actually care about privacy of their citizens.
In this case the email address was the lead, but I wonder what other info would be enough to get the phone provider to spill the beans. For instance would an IP address used at a specific time be uniquely identifying if it was VPNed by Apple at that moment ?
Or a Google Ad cookie that could get correlated to other devices showing similar behavior (the same way Google tracks households or related accounts) ?
If you are doing battle with or an enemy of the state, much less an agent of the state acting in bad faith simple privacy will do nothing for you. Worse your misunderstanding of it is actually a vector, like in this case. The measures for anonymity you require will not incorporate fancy UIs, nice features, or even reasonable reliability at times because they will be sacrificed in the name of leaving no trace.
> Once he got it, he asked Apple for information about this second email address, and got its name, home address, and phone number. Afterwards, the Civil Guard also asked the telephone company responsible for the telephone number who was the owner of the line, which matches the name provided by Apple. Also, they say they have found that this person is registered at the same address provided by Apple.
If your VPN is tied to a payment method then all you've done is give police one extra hop to follow to get at you, which wouldn't have saved this activist. Their list of VPNs only includes Mullvad in position 9 of 10, but as far as I'm aware it's the only one that offers payment methods that preserve your anonymity.
> Under Swiss law, Proton Mail was compelled to collect and provide information on the individual’s IP address to Swiss authorities, who then shared it with French police.
They can claim all the privacy guarantees they want, but unless the privacy is guaranteed by cryptography, it's an empty gesture. Nobody is willing to do prison time to protect your privacy.
There’s a reasonable chance that they already had this info (possibly even cleartext email via an ISP lawful intercept), and the proton/apple jig whilst bad, wasn’t as bad as the real source
That's the strictest privacy policy any company can hope.
Proton Mail can't give email content, only things like email address, ip adressese etc.
Anything that is stored by anyone can be handed over. That information may be useful, may be useless or may be useless now and useful tomorrow when they have the key.
True, but they can trivially obtain them given they control everything in the browser.
The question then becomes, does the law allow compelling to that degree? Apple fought back in the San Bruno case, but they’re very well lawyered up
https://www.forbes.com/sites/thomasbrewster/2023/08/08/proto...
Archive: https://web.archive.org/web/20230814144638/https://www.forbe...
This case is particularly noteworthy because it involves a series of
requests across different jurisdictions and companies, highlighting the
complex interplay between technology firms, user privacy, and law
enforcement. The requests were made under the guise of anti-terrorism
laws, despite the primary activities of the Democratic Tsunami involving
protests and roadblocks, which raises questions about the proportionality
and justification of such measures.I'll continue to use it despite some hyperbole on the site, but as long as my mail isn't being fed to an advertising engine it's a step up.
If you live in a country where homosexuality is illegal, and your local government is chasing you because of this, a Swiss company won't comply with data requests, and a Swiss judge has no reason to honour any data request.
If your local government is chasing you because of something that is recognised as a crime in Switzerland, then they will disclose data to foreign authorities.
Yup, until they receive a court order asking them to mitm an inbox, if they haven't already...
This entire system of "receive email in clear text but store it encrypted at rest" is smokes and shadows, really.
The former has distinctly less legal requirements than the latter, and authorities might be OK with keeping it that way, as metadata is already good enough in most cases.
It wouldn't technically be a MITM attack, they would just capture the incoming email. Tuta was famously forced to do that once by the German authorities.
While I agree this makes Proton unreliable for many things, there's no indication they were reading any emails.
If I wanted to conduct illegal activities I would not use my main account on it, at minimum.
Protonmail is a step up from Gmail/Outlook, but no more than that. You need more layers on top of it.
However.
What if say, russia/nk/china wants to catch somebody some journalist for speaking truth about their regimes? Or, like say, Jason Bourne exposing some IronHand in “democratic” country like USA? How can we protect good actors without enabling adversaries to do “bad stuff”? Is it even possible? I still don’t know the answer…
I have zero delusions however that they can protect me from state agents, let alone state agents with malicious intent. And I don't think it's realistic to expect that for the amount of money they cost. But that's fine with me - it's Joe from Marketing I'm scared about, and so far they seem to do a good job keeping Joe at bay :)
Par for the course at HN to have a "vaguely dislike-ish" relationship with Protonmail. Fastmail is the poster child of HN on the other hand.
I would guess the gist of it is that if you promise _any_ amount of security (or whatever feature), HN will nitpick you to death on not going 100% (despite the general improvement to your security). If you don't promise security at all, it doesn't matter that you're less secure than Proton. Something like that.
Gmail in that regard I've always perceived as worse - every few months or so they update their policy, linking to some gargantuan document that I can't be bothered to read, each time wondering how much of my soul I've sold this time around...
...and...
> The requests were made under the guise of anti-terrorism laws, despite the primary activities of the Democratic Tsunami involving protests and roadblocks, which raises questions about the proportionality and justification of such measures.
As I understand it, Catalonia has long desired for independence[1]. Is the Democratic Tsunami movement something different, entirely? If not, can someone fill-in the blanks of how vying for independence (in this case) gets umbrella'ed under terrorism?
[1] - https://en.wikipedia.org/wiki/Catalan_independence_movement
Edit: Accidental caps-lock on a word. My bad.
OK, I think I grokked this. You might think that a Greco-Nipponese name for this organization poorly conveys Catalan nationalist pride. But in fact it quite effectively says "anything but Spanish". That's almost certainly the gag.
They do. It's often required by law.
I assume it could be easily challenged in court (network was compromised, “i give out my WiFi to anyone who visits my home”) without other supporting evidence.
> 2.5 IP logging: By default, we do not keep permanent IP logs in relation with your Account. However, IP logs may be kept temporarily to combat abuse and fraud, and your IP address may be retained permanently if you are engaged in activities that breach our terms and conditions (e.g. spamming, DDoS attacks against our infrastructure, brute force attacks). The legal basis of this processing is our legitimate interest to protect our service against nefarious activities. If you enable authentication logging for your Account or voluntarily participate in Proton's advanced security program, the record of your login IP addresses is kept for as long as the feature is enabled. This feature is off by default, and all the records are deleted upon deactivation of the feature. The legal basis of this processing is consent, and you are free to opt in or opt out of that processing at any time in the security panel of your Account. The authentication logs feature records login attempts to your Account and does not track product-specific activity, such as VPN activity.
Irrelevant to the point. Proton Mail provided authorities with user data.
Like privacy is also meant to e.g. not disclose topics you have communicated about so that it can't be abused against you. For example there is a long history of states persecuting people for idk. being gay, believing in a certain religion or being a journalist which was involved in a unpleasant disclosure.
Still privacy and anonymity are two tightly related but different things. Mainly privacy of communication doesn't always imply anonymity, through sometimes does (and has too!).
Anyway it is foolish and somewhat strange to believe that a legally operating email service will protect you against judge backed lawful orders (no matter if it should be lawful or not).
Handing out metadata isn't even the worst which can happen, e.g. a judge might order them to make copies of unencrypted mails you receive or make copies of unencrypted mails you write or even undermine your encryption the next time you login.
They can try to dispute it and that alone does reduce abuse potential (if they operate in a place which still can be called a state of law) in the end especially for mail there is just no true privacy and even less anonymity.
Which doesn't mean their service is useless.
Just if you worry about political prosecution by EU countries, or do crime it's not protecting you.
I've emailed them to ask that they fix this. I also created a post on their user voice thing about it.
https://protonmail.uservoice.com/forums/284483-proton-mail/s...
TLDR; Proton Mail tells users to do this:
gpg --armor --export-secret-keys "${USER_ID}" | import-into-proton-mail
gpg --armor --export-secret-subkeys "${PROTON_ENCR_SUBKEY_ID}!" | import-into-proton-mail
gpg --armor --export-secret-subkeys "${PROTON_SIGN_SUBKEY_ID}!" | import-into-proton-mail
Anonymity is simply people not knowing who you are, not necessarily what you say. It's not privacy of communication, but privacy of identity.
I can post on the internet as Anonymous Coward, and those posts are public even though my identity is private.
I can encrypt an email and send it, and it will be picked up by all the relays. They can look up the source and identify me, but hopefully not read the email contents.
>The right not to be subjected to unsanctioned invasions of privacy by the government, corporations, or individuals is part of many countries' privacy laws, and in some cases, constitutions.
So according to Wikipedia, at least in some cases, privacy is protection against the state. Where does your definition come from?
GPs definition might as well come from wikipedia.
But the concept certainly doesn't mean that a business is going to help you cover your tracks in regards to data you've already shared. (in this case, the recovery email address)
If you give out your personal information, commit a crime, and ask that person to help you hide, you're not asking for anonymity, you're asking for an accomplice.
In the case of governments, private data is only hidden until the government decides that it needs to look for it (or ask for it). Anonymity means the data isn't there, regardless of whether the government decides it needs to, and has legal justification to, demand access to the data.
Anyone providing anonymity is only an accomplice if they know your intent. Simply not collecting data doesn't make you an accomplice, not collecting data with the intent of hiding someone else's illegal behavior does.
What matters here is what Proton promises and advertises to users/potential users vs. what it can actually deliver. I don’t know if Proton is more open about this, but hopefully this isn’t just buried in some long Terms of Service that almost nobody reads.
This is the main statement from Proton about their privacy protection. They say they obey Swiss privacy laws. So if one has a problem with Protonmail complying with Swiss law, maybe one should complain to Switzerland.
Well that's clearly not true.
Public doesn't care mostly. Governments on the other hand...
You got a few days of Tor on each device; then they need to burn.
I really don't know what more you can do beyond making your own chat client. Internet is not a place for revolution.
Welcome do dystopia and hope that governments in developed world will not become too nasty (CCP-level nasty) too soon due to inertia.
While I get what you are saying, that is a little too black and white for the entire field. Privacy can be used to shield whistle blowers from the state.
But you have to absolutely "air-gap" that from the rest of your identity, such as not making a proton e-mail address over TOR and then using your usual email address as the recovery one.
Most claim they don't, PIA even was subpoenad at least once and responded they don't have logs.
How are police going to find me behind that hop?
https://restoreprivacy.com/mullvad-vpn-says-customer-data-is...
Paying for a VPN account does not mean the VPN is going to start logging user activity. Keeping payment records does not equal logging user activity through VPN servers. And most of the big name VPNs allow for crypto payments.
No, that was last year's issue.
This time it's:
> The core of the controversy stems from Proton Mail providing the Spanish police with the recovery email address associated with the Proton Mail account of an individual using the pseudonym ‘Xuxo Rondinaire.’ This individual is suspected of being a member of the Mossos d’Esquadra (Catalonia’s police force) and of using their internal knowledge to assist the Democratic Tsunami movement.
and
> Upon receiving the recovery email from Proton Mail, Spanish authorities further requested Apple to provide additional details linked to that email, leading to the identification of the individual.
Just don't try to make encrypted email happen. It can't, and we don't need it to be. We have better solutions for encrypted communications, for those that need it.
or at least their favorite youtuber with the paid ads and zero domain knowledge of network topology
serious question I have is whether “internet reseller” is a compelling service. because that's all that VPNs are, and I dont mind paying to use them for that purpose.
Email content is encrypted and Proton Mail has no access
While we did use phone verification in the past, this is not the case any longer. Phone numbers were stored in the same way as the email addresses, so, again, we have no way to derive them back from the hash.
I've no reason to doubt this but brute-force cracking a hash known to be from a phone number would likely be pretty trivial.
Fwiw, I use protonmail and trust it more than most other services. But my threat model doesn't involve technically capable adversaries directly targeting me, certainly not ones that could compel protonmail to divulge phone number hashes.
This isn't true in practice. It's not hard to build a big list of ~every email address (give or take), and have a GPU churn through them all until you get a match.
If you've ever received a spam email, your email address is on such a list.
Unfortunately, it can and has been abused.
About the only way to even vaguely keep your email private is to use a self hosted server with GPG keys. And any lapse on security updates for that thing and you could be compromised almost immediately.
Beyond that I cannot think of anything more one could do.
I have always treated email as something to travels in the clear. My current provider (Fastmail) is compromised by authority. The Australian Privacy Act 1988 by being based in Australia and it gets caught up by PRISM as the servers are run out of New York.
If you continued using the account only through Tor, there wouldn't be any traceable info.
It did then prompt me to add an email and/or phone number as recovery methods, but that step was skippable.
Get one from your neighborhood coffee shop Wi-Fi, and pay cash for your coffee.
Also make sure to avoid CCTV...
Its biggest action was probably at the Barcelona Airport in October 2019, a protest a couple of years after the Catalan independence election in October 2017. The election itself was deemed unconstitutional by the Spanish government. The registered voters/turnout of this election was 43.03%; where 92.01% voted for separation from Spain and 7.99% voted to stay within Spain –– see: https://en.wikipedia.org/wiki/2017_Catalan_independence_refe... –– but this was not a normal election by any means (read the link for more).
Typically the ANC –– see: https://en.wikipedia.org/wiki/Assemblea_Nacional_Catalana –– has been the leading organization in the independence movement. They have been organizing big independence rallies etc. and the actions has been peaceful (from what I've read and seen). The Democratic Tsunami based protests were different in this regard, where more direct confrontation was more the norm. From what I have read Democratic Tsunami is not particularly active at the moment, but of course this might change.
Also some members were arrested apparently planning even more extreme things.
The IRA and ETA were vying for independence too...
That said, I think it's crazy how much time the government wastes on this when the cities are full of petty criminals acting with impunity. Someone was stabbed to death outside my apartment just in a robbery and yet nothing changes.
It's more than a glorified FTP. FTP does some heinous things with a separate control channel and stuff (let me tell you about adding encryption support to the Perl FTP server some other day), but this is next level!
https://developers.dropbox.com/dbx-team-files-guide
It's not even as simple as just sending a fixed string in the "Dropbox-API-Path-Root" header for every API request (and they're all path based, so you have to make sure you always send that header or the paths won't parse right) - you have to get an ID for the real root, with a separate request, with a scope that we weren't requesting on refresh tokens.
So I hacked together something that worked on my testbed on the train ride home, but making it good is going to include adding a caching layer to the token refresh code, and suddenly it's not just a casual project. I'm still going to do it though, because dammit I have a file to attach to an email on Friday and I'm happy to spend hours on this to save myself 30 seconds.
Open source clients that you can self-host are available. I mean of course you still have to trust the code if you can't audit it. But hijacking your keys won't be as easy as visiting their webmail.
Do you have any source to back that up? Last I heard a random person or company won't have a way to find out the real identity given just an IP in general.
I am not sure how the CCPA treats IP address, but unless you're at Google or Facebook, it doesn't matter. Few can afford to build separately for the EU and the rest of the world, and hence err on adapting the strictest interpretation.
--
[0] https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CEL...
I would say anonymity is an aspect of privacy, one you sometimes but not always need.
e.g. I would say leaking who was present at a anonymous self help group isn't just breaking anonymity but also infringing on privacy
I said that the post I responded to was conflating two different types of privacy.
Who said things is different to what was said.
Bob and Alice spoke about something, is not the same as Anon to Anon "The government is listening".
One is the message and one is metadata. They are protected in different ways and leaked in different ways. Mixing the two means that you will probably not get the protection that you desire.
Which comes directly into the problem of security vs convenience.
> The core of the controversy stems from Proton Mail providing the Spanish police with the recovery email address associated with the Proton Mail account of an individual using the pseudonym ‘Xuxo Rondinaire.’
We're saying that Proton Mail provided the authorities with user data, which it did.
As long as your secure world is not fully isolated but has any interactions with the physical world at all (e.g a human being somewhere receiving and reading your message with his eyes), then it's only a matter of resources allocated to trace you. You can pile up layers of "hops" through uncooperative jurisdictions -- this certainly helps to raise the bar but doesn't give you a mathematical proof of security.
Consider a building or a server. You can absolutely make them secure. Sure, eventually, everything can be broken/bypassed/hacked/cracked whatever, but if there is no chance of that happening for the duration that the security has to persist, then it is secure.
I'm not sure it's a good example. A server that you build from off-the-shelf components will likely come with the IME, providing direct tcp-to-ram access. Motherboard manufacturers probably add their own backdoors on top. We know about Gigabyte because they were caught red-handed, but how many we don't know about? How many rootkits in the SSD firmware? In hundreds of other firmware blobs installed on your Linux server right now?
I'm not even talking about Open Source backdoors which are hard as they have to be done in the open. Hardware/firmware backdoors are not in the open, they have been around for decades, they have been found and confirmed numerous times and god only know how many were NOT found.
Building a secure server nowadays is an extremely complex task, only solvable at the government level perhaps and only an a few select countries, if solvable at all. You need full control over the whole supply chain that includes tens or hundreds of thousands of corruptible employees.
It is certainly a very hard and complex problem but I wouldn’t necessarily go as far as “impossible”. Maybe you know something I don’t know, though.
Protonmail can still be the best choice for a pseudonymous mail service so long as it's combined with diligent, consistent IP address obfuscation. Protonmail will continue to allow logins and new account creations over Tor. All the major free email providers have long since disallowed new signups over Tor, and most have some form of degraded user experience when logging in over Tor, if they allow it at all. Small, niche email providers appear and disappear so often that relying on them still to exist even a few months into the future is a big gamble. Hosting one's own email requires payment of some type to the hosting provider, so it is not anonymous. Other privacy-oriented free email providers, such as riseup, will do exactly what protonmail did, because if they refuse, their only option is to go the way of lavabit.
If equality-check is required to prevent e-mail reuse by spammers then argon2id with static salt rotated every few months will be reasonably strong too.
Of course I have no idea if any of this is implemented or it's just sha256(email). Just replying to the question of general feasibility.
Anyway, it puts the persons living in that location on the radar of the police, and other evidence can be collected (For example by getting a warrant and taking all electronics out of the "location").
To keep the discussion interesting, please do not assume or guess, thanks!
However in this case (an operating police officer who gave information to a group who wants to split away from the country) i make a bold assumption that even Iceland would order the company to give the data out (since it has nothing to do with protecting journalists/whistleblowers, but espionage)
Are you claiming that businesses in Iceland are not required to comply with court orders? On what basis do you believe that to be true?
I thought "Huh? Why would an Icelandic company operate from Norway?" Well, I thought, I suppose there must be quite a few. But why's he mentioning it here?
Thanks for inadvertently clarifying.
We don't see much of the latter since most web services require an email to sign up, at minimum, which still leaves discoverable bread crumbs. The web services that require you to give up nothing to use them are far less popular, so I guess I can see why people might conflate the two.
The common description when contrasting anonymity vs privacy is that anonymity allows one to do things publicly without being ID'd while privacy allows one to do things without the public having knowledge. There is no implication or requirement that the private party has been ID'd by another other entity.
If I'm the only one in possession with data I don't really consider it data collection at all, at least in the context of privacy and anonymity. Other than that I agree with your clarifications here though.
The bottom line is that if you told someone who you are, you're not anonymous.
https://dwheeler.com/trusting-trust/
There are also a number of people making minimal OSes, interpreters, and compilers that you can, for example, assemble by hand and type in "from scratch".
There was a nice list of those that I can't find right now, but you could look at
https://bootstrappable.org/projects/mes.html
as one example in this direction.
To make a perfectly secure system, the first step is to obtain high purity sand.
On the bright side, it's hard to imagine that many of these attacks will be self-propagating, which is the particularly insidious thing about the Trusting Trust attack. Yes, hardware is used to design hardware, but typically in a more indirect and heterogeneous way than the "compiler compiling itself" scenario. To be concrete, I'd say Microsoft or Canonical has much more to fear from a Trusting Trust sort of attack than Intel does, but the software developers also have better options to contain or detect such an attack.
If I own the hardware, I can decide how the software is executed, including containerizing your certification processes to make them feel warm and fuzzy and happy but in reality they are running inside a simulation.
If push comes to shove I could theoretically manufacture my own RAM sticks that copy everything and your OS wouldn't even know, but there's a 99% chance I could successfully pull it off at the kernel virtualization level.
If you’re trying to evade LE because it’s illegal to be gay in your country, and you get caught because you’d listed an Apple address in your ProtonMail account - can’t we design better products to make this less likely?
Should we consult your personal moral preferences for that, as applied to each of the 200+ countries on the planet? Why do your preferences overrule those jurisdictions' decisions?
Folks who design products that are trying to protect privacy should do their absolute best to sand down the sharp edges and make them secure-by-default wherever possible.
You make a good point, as when I made my comments I was considering an 'average' usecase, typically wanting to guard against malicious attacks from unknown actors on the internet.
You're talking here though about absolute security against basically a state level actor. No one else is going to be dealing with exploiting backdoors in firmware for specific targets.
But I still maintain my points is correct, it just requires substantially more money. If guarding against state actors is the requirement, that can be met by having custom or at least verified (at every stage of manufacturer) hardware. Expensive, but far from impossible. As for software issues, that's why we have stuff like SELinux and SEL4.
So yeah, I maintain you can absolutely secure a server. You just have to be clear about what the threats you are wanting to protect against are, and for most people that isn't state actors.
Of course when Proton say they don't log, we just have to take their word for it. People who don't want that element of trust can use Tor. Personally I believe their story in this case.
Opsec is hard and most activists in western countries don't take it seriously. It's not like we live in PRC or DPRK right?
Ironically, it is likely far harder for PRC or DPRK to get data from Proton than it is for Spanish police.
Right. Western governments are much, much better at mass covert surveillance.
> it is likely far harder for PRC or DPRK to get data from Proton than it is for Spanish police
You balk at the idea of a western government being oppressive while pointing out that our “secure” email services can be easily compromised by government action.
https://www.wired.com/story/europe-break-encryption-leaked-d...
“Ideally, in our view, it would be desirable to legislatively prevent EU-based service providers from implementing end-to-end encryption,” Spanish representatives said in the document.
Then mail them your money
I think most people are considering less serious threat models
I would say most people are concerned with dragnets, not targeted attacks. There's quite a lot you can hide from the government in terms of dragnets, in the same way you'd hide from big tech.
"Hide" isn't the right word. "Defend from" I think is probably better. Defending our constitutional rights from government and defending our privacy from big tech.
I'm actually perfectly okay with governments in targeted attacks (where a warrant is reasonably given). I'm just not okay with police being lazy.
Really Norway? Are you guys stupid?
In answer to your question: firstly I am not "guys", I'm one person; and secondly, yes, I feel pretty stupid.
1. We don't generate OpenPGP keys on the server, we generate them in the client, and then encrypt them with a key derived from your password (which we never send to the server), and store the encrypted key on the server. Then, when you login again, we fetch and decrypt the private key, and use it in the client. The server never has access to your private keys.
2. We do support "GNU Dummy" keys now (which is what `gpg --export-secret-subkeys` creates). The required private key material needs to be in a single OpenPGP key though (with a dummy primary key), but that's what `gpg --export-secret-subkeys` does by default. Though, as mentioned above, we don't have access to the primary key on our servers either way.
2a. Note that "GNU Dummy" keys are a gpg-specific extension to OpenPGP [1]. The upcoming new version of the OpenPGP standard [2] allows a more standardized way of doing this by combining public key packets and private key packets in a single transferable private key, but it's not widely implemented yet.
3. I would argue that the private key material of the subkeys (used to encrypt and sign your emails) is actually much more important in this case (but of course we don't have access to that either). That's the reason we don't explicitly recommend this: it doesn't meaningfully improve security. But we don't stop you from doing it (now that we support it, even though it's a nonstandard feature), either.
[1]: https://github.com/gpg/gnupg/blob/master/doc/DETAILS#gnu-ext...
[2]: https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-cry...
I see, I stand corrected then. Thanks for clarifying. The Proton Mail interface contains buttons labeled "generate" so I got the impression it was being generated in the server. Is this password-derived key the "account key" which I see in the Proton Mail settings interface?
Please clarify what key derivation function is being used. The OpenPGP S2K which gpg uses is outdated and probably not secure enough. I know that Proton Mail is involved in the OpenPGP standards body in an effort to modernize it and that the new RFC contains support for the memory hard argon2 algorithm. Is that what's being used? If so then I would believe that it's even more secure than the encryption that gpg applies to the exported key output.
Are there instructions for verifying that all this is happening? I think a lot of folks on HN won't be convinced otherwise.
> We do support "GNU Dummy" keys now (which is what `gpg --export-secret-subkeys` creates).
Wow that is GREAT and the exact information I wanted! I only believed otherwise because of the documented instructions, which contain the command I posted above. I double checked with Proton Mail support as well but everything led to believe that this was not supported when in fact it was.
Please add this fact to your documentation and instruct your support staff about this!!
> I would argue that the private key material of the subkeys (used to encrypt and sign your emails) is actually much more important in this case (but of course we don't have access to that either).
I agree. Those are the keys which sign and encrypt the data after all.
It's just that I'm going to create an OpenPGP identity for things like signing code commits on git, signing packages I publish. I'm putting quite a bit of effort into getting it right. I printed out the master key to paper in paperkey and QR code format. I even contributed code to ZBar to add binary decoding support so that the key backup is easy to restore. I'll also be making an effort to join the decentralized web of trust.
So I was really hoping to be able to use Proton Mail with this identity instead of the key pair that's generated for the account. This way the emails I send can be signed by the same identity that I'll publish on the OpenPGP key servers. Looks like it's going to be possible after all.
Thanks for reaching out here on HN. I've been a really happy Proton Mail customer and now I'm even happier.
No, the account key is an OpenPGP key which is encrypted with a key derived from your password. The "key encryption key" is not separately visible. The address keys are in turn encrypted using the account key. (The account keys are also used to encrypt your contacts, for example, which are shared between all your addresses - while the address keys are specific to an email address and are used to encrypt emails etc.)
> Please clarify what key derivation function is being used.
We use bcrypt, in addition to the OpenPGP S2K (i.e. the bcrypt output is fed as the "password" to OpenPGP's key encryption).
We are in the process of rolling out updates to OpenPGP.js and GopenPGP which support Argon2 for the OpenPGP S2K step, after which we'll start using that - but we aren't quite yet.
> Are there instructions for verifying that all this is happening? I think a lot of folks on HN won't be convinced otherwise.
Take a look at https://github.com/ProtonMail/WebClients/blob/main/packages/..., for example. Though to be honest, if you want to verify that we aren't sending the password to the server anywhere, in principle you'd have to check the code of the entire web app (or whichever app you're using). It's all open source, but it's a lot of work, of course. But you can also check the latest audit report: https://proton.me/blog/security-audit. They also verified all of this stuff.
> It's just that I'm going to create an OpenPGP identity for things like signing code commits on git, signing packages I publish. (...) So I was really hoping to be able to use Proton Mail with this identity instead of the key pair that's generated for the account.
Yeah, I understand. Though the typical advice from a cryptographer's perspective would be, it's better to use separate keys for separate purposes; and the simplest way to do that is to generate separate OpenPGP certificates, so that's what we'd generally recommend. But, if you want to generate separate subkeys and sign them all using a common primary key, that's also reasonable enough. And, we can improve the documentation on that, although it's a bit of a niche use case (not for HN of course, but for the general audience it is).
> Thanks for reaching out here on HN. I've been a really happy Proton Mail customer and now I'm even happier.
Thanks, glad to hear! :)
that they demanded the private key tells you _everything_ you need to know about protonmail.
The only way to retain full control over all the keys is to do it the hard way: manually encrypt the emails and send that payload via SMTP. If we refuse to give them the keys, we can't enjoy the convenience of Proton Mail doing that automatically for us. Proton Mail offers a middle ground and it's a very attractive one if you accept the inherent risks associated with giving them the keys.
I'm not willing to give them the master key though. I want the ability to generate a bunch of subkeys just for them. Then I can just revoke those keys if they're ever compromised, and the emails will be encrypted and signed by my actual OpenPGP identity that I'm investing time into, not a separate master key generated for my Proton Mail account.
The support guys confirmed to me in writing via email that Proton Mail only ever uses the signing and encryption subkeys. They don't need the master key.
> We use the signing subkey for signing and the encryption subkey for encryption, and you will have to import the whole OpenPGP at once.
So I asked them directly to add support for importing just the subkeys.
I made a post on their user voice thing about this too. It's garnered a bit of support already.
https://protonmail.uservoice.com/forums/284483-proton-mail/s...
Let's see what happens.
Here's my last message to Proton Mail support, request ID 822331. I was directly told no resources would be spent on fixing it:
> Well, it has been multiple years now so can you guys maybe prioritize this? How long do you want me to continue waiting on this issue? I can't count on PM users to send my mailserver E2EE mail when the mobile app doesn't support it.
I would assume that any technically sophisticated users who just want an SMTP/IMAP server would never let their keys leave their control, but there might be other users for whom a "middle layer" service which has their keys is good enough. (I guess this is especially evident in cryptoassets where people seem to cheerfully let third parties manage their tokens, so it's not really surprising to me that there are a bunch of people willing to do it with their PGP keys for email purposes.)
I guess there's an argument about whether or not they're being responsible in providing such an option at all, which is fair enough.
Does that create trust issues? Absolutely. Still, OpenPGP sucks and I just can't fault them for trying to fix it. They're even participating in the standards bodies alongside other OpenPGP projects trying to modernize the whole thing. Somehow it resulted in gpg forking the standard and making everything even worse. It was hard to use before, now it's hard and fragmented.
https://lwn.net/Articles/953797/
https://news.ycombinator.com/item?id=38554393
I suppose they could have gpg or OpenPGP smartcard integration in the bridge, then it could use those keys to sign and encrypt. That's more secure but creates quite a bit of hassle. Suddenly the web and mobile apps become incapable of sending OpenPGP email unless you have the smartcard connected. I've got two NFC enabled YubiKeys and I can't even begin to imagine how to connect this stuff to a smartphone. Looks like there isn't enough support for it.
The most secure solution is to generate keys on an OpenPGP smartcard like an NFC enabled YubiKey and use that key everywhere. Even that's incompatible with maximum reliability: YubiKeys can and will eventually fail and when they do your keys are gone. So you can't generate the encryption subkey on the smartcard, you need to generate it on a secure device, back it up to paper just like the master key, and then copy it to the smartcard. Otherwise you risk being unable to decrypt data later.
It's an incredibly hard problem and it's full of tradeoffs. I can at least respect their attempt to solve the problem.
> although it's a bit of a niche use case (not for HN of course, but for the general audience it is)
No doubt about that. Safe to assume that 99% of your users will not know or care about this. That's why I want to thank you for supporting this advanced key management feature for those of us who want it. To me that's evidence that Proton Mail takes OpenPGP seriously.
The --export-secret-subkeys command does just that: it replaces the master key with some GNU specific stub packet thing. It's conceivable that they could detect this and reject the uploaded key. In order to avoid that, one might edit the secret key packet manually instead. Just zero fill or randomize all the secret key bits or something. I assume it wouldn't match up with the public key though. Aren't the public and private keys mathematically related? Maybe you can detect that the key is bogus if you try to do cryptographic operations with it. Maybe the operation somehow fails or produces nonsense results. I don't really know enough cryptography to say.
You want to optimize your 99.9% case for convenience (say, use Fastmail), and optimize your 00.1% case for security (manually managed PGP with a secondary anonymous e-mail). It makes no sense to trade away swathes of convenience and security just so you can be lazy with your 00.1% case.
The maximum security manual OpenPGP 0.1% case is still absolutely necessary though. No doubt about that. Anyone claiming that Proton Mail solved this doesn't actually understand how OpenPGP works. Not that I would fault them for failing to understand this ludicrously complicated stuff.
I read the OpenPGP standard and it seems to have some kind of "notation" packets. Seems to be somewhat related to metadata but I can't figure out how it works or even what its purpose is and it looks like nothing ever uses that anyway.