When people tell me to stop using the only cryptosystem in existence that has ever - per the Snowden leaks - successfully resisted the attentions of the NSA, I get suspicious, even hostile. It’s triply frustrating when, at the end of the linked rant, they actually recognize that PGP isn’t the problem:
It also bears noting that many of the issues above could, in principle at least, be addressed within the confines of the OpenPGP format. Indeed, if you view ‘PGP’ to mean nothing more than the OpenPGP transport, a lot of the above seems easy to fix — with the exception of forward secrecy, which really does seem hard to add without some serious hacks. But in practice, this is rarely all that people mean when they implement ‘PGP’.
There is a lot wrong with the GPG implementation and a lot more wrong with how mail clients integrate it. Why would someone who recognises that PGP is a matter of identity for many of its users go out of their way to express their very genuine criticisms as an attack on PGP? If half the effort that went into pushing Signal was put into a good implementation of OpenPGP following cryptographic best practices (which GPG is painfully unwilling to be), we’d have something that would make everyone better off. Instead these people make it weirdly specific about Signal, forcing me to choose between “PGP” and a partially-closed-source centralised system, a choice that’s only ever going to go one way.
I am deeply concerned about the push towards Signal. I am not a cryptographer, so all I can do is trust other people that the crypto is sound, but as we all know, the problems with crypto systems are rarely in the crypto layers.
On one hand we know that PGP works, on the other hand we have had two game over vulnerabilities in Signal THIS WEEK. And the last Signal problem was very similar to the one in “not-really-PGP” in that the Signal app passed untrusted HTML to the browser engine.
If I were a government trying to subvert secure communications, investing in Signal and tarnishing PGP is what I would try to do. What better strategy than to push everyone towards closed systems where you can’t even see the binaries, and that are not under the user’s control. The exact same devices with GPS and under constant surveilance.
My mobile phone might have much better security mechanisms in theory, but I will never know for sure because neither I, nor anyone else can really check. In the meantime we know for sure what a privacy disaster these mobile phones are. We also know for sure the the various leaks that government implant malware on mobile devices, and we know that both manufacturers and carriers can install software, or updates, on devices without user consent.
Whatever the PGP replacement might be, moving to the closed systems that are completely unauditable and not under the user’s control is not the solution. I am not surprised that some people advocate for this option. What I find totally insane is that a good majority of the tech world finds this position sensible. Just find any Hacker News thread and you will see that any criticism towards Signal is downvoted to oblivion, while the voices of “experts” preach PGP hysteria.
PGP will never be used by ordinary people. It’s too clunky for that. But it’s used by some people very successfully, and if you try to dissuade this small, but very important group of people to move towards your “solution”, I can only suspect foul play. Signal does not compete with PGP. It’s a phone chat app. As Signal does not compete with PGP, why do you have to spend all this insane ammount of effort to convince an insignificant amount of people to drop PGP for Signal?
I can’t for the life of me imagine why a CIA-covert-psyops-agency funded walled garden service would want to push people away from open standards to their walled garden service.
Don’t get me wrong, Signal does a lot of the right things but a lot of claims are made about it implying it’s as open as PGP, which it isn’t.
Not Signal, iOS and Android, and all the secret operating systems that run underneath.
As for Signal itself, moxie forced F-Droid to take down Signal, because he didn’t want other people to compile Signal. He said he wanted people only to use his binaries, which even if you are ok with in principle, on Android it mandates the use of the Google Play Store. If this is not a dick move, I don’t know what is.
I’m with you on Android and especially iOS being problematic. That being said, Signal has been available without Google Play Services for a while now. See also the download page; I couldn’t find it linked anywhere on the site but it is there.
However, we investigated this for PRISM Break, and it turns out that there’s a single Google binary embedded in the APK I just linked to. Which is unfortunate. See this GitHub comment.
As I understand it, the case against PGP is not with PGP in and of itself (the cryptography is good), but the ecosystem. That is, the toolchain in which one uses it. Because it is advocated for use in email and securing email, it is argued, is nigh on impossible, then it is irresponsible to recommend using PGP encrypted email for general consumption, especially for journalists.
That is, while it is possible to use PGP via email effectively, it is incredibly difficult and error-prone. These are not qualities one wants in a secure system and thus, it should be avoided.
But the cryptographyisn’t good. His case in the blog post is intentionally besides all of the crypto badness.example: the standard doesn’t allow any other hash function than sha1, which has been proven broken. The protocol itself disallows flexibility here to avoid ambiguity and that means there is no way to change it significantly without breaking compatibility.
And so far, it seems, people wanted compatibility (or switched to something else, like Signal)
When people tell me to stop using the only cryptosystem in existence that has ever - per the Snowden leaks - successfully resisted the attentions of the NSA, I get suspicious, even hostile.
Without wanting to sound rude, this is discussed in the article:
The fact of the matter is that OpenPGP is not really a cryptography project. That is, it’s not held together by cryptography. It’s held together by backwards-compatibility and (increasingly) a kind of an obsession with the idea of PGP as an end in and of itself, rather than as a means to actually make end-users more secure.
OpenPGP might have resisted the NSA, but that’s not a unique property. Every modern encryption tool or standard has to do that or it is considered broken.
I think most people unless they are heavily involved in security research don’t know how encrytion/auth/integrity protection are layered. There are a lot of layers in what people just want to call “encryption”. OpenPGP uses the same standard crypto building blocks as everything else and unfortunately putting those lower level primitives together is fiendishly difficult. Life also went on since OpenPGP was created meaning that those building blocks and how to put them together changed in the last few decades, cryptographers learned a lot.
One of the most important things that cryptographers learned is that the entire ecosystem / the system as a whole counts. Even Snowden was talking about this when he said that the NSA just attacks the endpoints, where most of the attack surface is. So while the cryptography bits in the core of the OpenPGP standard are safe, if dated, that’s not the point. Reasonable people can’t really use PGP safely because we would have to have a library that implements the dated OpenPGP standard in a modern way, clients that interface with that modern library in a safe and thought-through way and users that know enough about the system to satisfy it’s safety requirements (which are large for OpenPGP)
Part of that is attitude, most of the existing projects for implementing the standard just don’t seem to take a security-first stance. Who is really looking towards providing a secure overall experience to users under OpenPGP? Certainly not the projects bickering where to attribute blame.
I think people kept contrasting this with Signal because Signal gets a lot of things right in contrast. The protocol is modern and it’s not impossibly demanding on users (ratcheting key rotation, anyone?), there is no security blame game between Signal the desktop app vs signal the mobile app vs the protocol when a security vulnerability happens, OWS just fixes it with little drama. Of course Signal-the-app has downsides too, like the centralization, however that seems like a reasonable choice. I’d rather have a clean protocol operating through a central server that most people can use than an unuseable (from the pov of most users) standard/protocol. We’re not there yet where we can have all of decentralization, security and ease of use.
OpenPGP might have resisted the NSA, but that’s not a unique property. Every modern encryption tool or standard has to do that or it is considered broken.
One assumes the NSA has backdoors in iOS, Google Play Services, and the binary builds of Signal (and any other major closed-source crypto tool, at least those distributed from the US) - there’s no countermeasure and virtually no downside, so why wouldn’t they?
there is no security blame game between Signal the desktop app vs signal the mobile app vs the protocol when a security vulnerability happens, OWS just fixes it with little drama.
Not really the response I’ve seen to their recent desktop-only vulnerability, though I do agree with you in principle.
Signal Android has been reproducible for over two years now. What I don’t know is whether anyone has independently verified that it can be reproduced. I also don’t know whether the “remaining work” in that post was ever addressed.
The process of verifying a build can be done through a Docker image containing an Android build environment that we’ve published.
Doesn’t such process assume trust on who created the image (and on who created each of layers it was based on)?
A genuine question, as I see the convenience of Docker and how it could lead to more verifications, but on the other hand it create a single point of failure easier to attack.
That question of trust is the reason why, if you’re forced to use Docker, build every layer for yourself from the most trustworthy sources. It isn’t even hard.
the only cryptosystem in existence that has ever - per the Snowden leaks - successfully resisted the attentions of the NSA
I’m pretty ignorant on this matter, but do you have any link to share?
There is a lot wrong with the GPG implementation
Actually, I’d like to read the opinion of GPG developers here, too.
Everyone makes mistakes, but I’m pretty curious about the technical allegations: it seems like they did not considered the issue to be fixed in their own code.
To start with, you can’t trust the closed-source providers since the NSA and GHCQ are throwing $200+ million at both finding 0-days and paying them to put backdoors in. Covered here. From there, you have to assess open-source solutions. There’s a lot of ways to do that. However, the NSA sort of did it for us in slides where GPG and Truecrypt were worst things for them to run into. Snowden said GPG works, too. He’d know given he had access to everything they had that worked and didn’t. He used GPG and Truecrypt. NSA had to either ignore those people or forward them to TAO for targeted attack on browser, OS, hardware, etc. The targeted attack group only has so much personnel and time. So, this is a huge increase in security.
I always say that what stops NSA should be good enough to stop the majority of black hats. So, keep using and improving what is a known-good approach. I further limit risk by just GPG-encrypting text or zip files that I send/receive over untrusted transports using strong algorithms. I exchange the keys manually. That means I’m down to trusting the implementation of just a few commands. Securing GPG in my use-case would mean stripping out anything I don’t need (most of GPG) followed by hardening the remaining code manually or through automated means. It’s a much smaller problem than clean-slate, GUI-using, encrypted sharing of various media. Zip can encode anything. Give the files boring names, too. Untrusted, email provider is Swiss in case that buys anything on any type of attacker.
Far as the leaks, I had a really-hard time getting you the NSA slides. Searching with specific terms in either DuckDuckGo or Google used to take me right to them. They don’t anymore. I’ve had to fight with them narrowing terms down with quotes trying to find any Snowden slides, much less the good ones. I’m getting Naked Security, FramaSoft, pharma spam, etc even on p 2 and 3 but not Snowden slides past a few, recurring ones. Even mandating the Guardian in terms often didn’t produce more than one, Guardian link. Really weird that both engines’ algorithms are suppressing all the important stuff despite really-focused searches. Although I’m not going conspiracy hat yet, the relative-inaccuracy of Google’s results compared to about any other search I’ve done over past year for both historical and current material is a bit worrying. Usually excellent accuracy.
NSA Facts is still up if you want the big picture about their spying activities. Ok, after spending an hour, I’m going to have to settle for giving you this presentation calling TAILS or Truecrypt catastrophic loss of intelligence. TAILS was probably temporary but the TrueCrypt derivatives are worth investing effort in. Anyone else have a link to the GPG slide(s)? @4ad? I’m going to try to dig it all up out of old browser or Schneier conversations in near future. Need at least those slides so people knows what was NSA-proof at the time.
It was secure at the time since either mass collection or TAO teams couldnt hack it. Hacking it requires one or more vulnerabilities in the software it runs. The TAILS software includes complex software such as Linux and a browser with history of vulnerabilities. We should assume that was temporary and/or would disappear if usage went up enough to budget more attacks its way.
Well, you have to look at the various methods of attack to assess this:
Mass surveillance attempting to read traffic through protocol weaknesses with or without a MITM. They keep finding these in Tor.
Attacks on the implementation of Tor, the browser, or other apps. These are plentiful since it’s mostly written in non-memory safe way. Also, having no covert, channel analysis on components processing secrets means there’s probably plenty of side channels. There’s also increasingly new attacks on hardware with a network-oriented one even being published.
Attacks on the repo or otherwise MITMing the binaries. I don’t think most people are checking for that. The few that do would make attackers cautious about being discovered. A deniable way to see who is who might be a bitflip or two that would cause the security check to fail. Put it in random, non-critical spots to make it look like an accident during transport. Whoever re-downloads doesn’t get hit with the actual attack.
So, the OS and apps have to be secure with some containment mechanisms for any failures. The protocol has to work. These must be checked against any subversions in the repo or during transport. All this together in a LiveCD. I think it’s doable minus the anonymity protocol working which I don’t trust. So, I’ve usually recommended dedicated computers bought with cash (esp netbooks), WiFi’s, cantennas, getting used to human patterns in those areas, and spots with minimal camera coverage. You can add Tor on top of it but NSA focuses on that traffic. They probably don’t pay attention to average person on WiFi using generic sites over HTTPS.
Sure. My question was more: does a live CD project with that kind of aim exist? @josuah mentioned heads which at least avoids the regression of bringing in systemd, but doesn’t really improve over classic tails in terms of not relying on linux or a browser.
An old one named Anonym.OS was an OpenBSD-based, Live CD. That would’ve been better on code injection front at least. I don’t know of any current offerings. I just assume they’ll be compromised.
I think it is the reason why https://heads.dyne.org/ have been made: Replacing the complex software stack with a simpler one with aim to avoid security risks.
Really weird that both engines’ algorithms are suppressing all the important stuff despite really-focused searches.
If you can share a few of your search terms I guess that a few friends would find them pretty interesting, with their research.
For sure this teach us a valuable lesson. The web is not a reliable medium for free speech.
From now on, I will download from the internet interesting documents about such topics and donate them (with other more neutral dvds) to small public libraries around the Europe.
I guess that slowly, people will go back to librarians if search engines don’t search carefully enough anymore.
It was variations, with and without quotes, on terms I saw in the early reports. They included GPG, PGP, Truecrypt, Guard, Documents, Leaked, Snowden, and catastrophic. I at least found that one report that mentions it in combination with other things. I also found, but didn’t post, a PGP intercept that was highly-classified but said they couldn’t decrypt it. Finally, Snowden kept maintaining good encryption worked with GPG being one he used personally.
So, we have what we need to know. From there, just need to make the programs we know work more usable and memory safe.
When people tell me to stop using the only cryptosystem in existence that has ever - per the Snowden leaks - successfully resisted the attentions of the NSA, I get suspicious, even hostile. It’s triply frustrating when, at the end of the linked rant, they actually recognize that PGP isn’t the problem:
There is a lot wrong with the GPG implementation and a lot more wrong with how mail clients integrate it. Why would someone who recognises that PGP is a matter of identity for many of its users go out of their way to express their very genuine criticisms as an attack on PGP? If half the effort that went into pushing Signal was put into a good implementation of OpenPGP following cryptographic best practices (which GPG is painfully unwilling to be), we’d have something that would make everyone better off. Instead these people make it weirdly specific about Signal, forcing me to choose between “PGP” and a partially-closed-source centralised system, a choice that’s only ever going to go one way.
I am deeply concerned about the push towards Signal. I am not a cryptographer, so all I can do is trust other people that the crypto is sound, but as we all know, the problems with crypto systems are rarely in the crypto layers.
On one hand we know that PGP works, on the other hand we have had two game over vulnerabilities in Signal THIS WEEK. And the last Signal problem was very similar to the one in “not-really-PGP” in that the Signal app passed untrusted HTML to the browser engine.
If I were a government trying to subvert secure communications, investing in Signal and tarnishing PGP is what I would try to do. What better strategy than to push everyone towards closed systems where you can’t even see the binaries, and that are not under the user’s control. The exact same devices with GPS and under constant surveilance.
My mobile phone might have much better security mechanisms in theory, but I will never know for sure because neither I, nor anyone else can really check. In the meantime we know for sure what a privacy disaster these mobile phones are. We also know for sure the the various leaks that government implant malware on mobile devices, and we know that both manufacturers and carriers can install software, or updates, on devices without user consent.
Whatever the PGP replacement might be, moving to the closed systems that are completely unauditable and not under the user’s control is not the solution. I am not surprised that some people advocate for this option. What I find totally insane is that a good majority of the tech world finds this position sensible. Just find any Hacker News thread and you will see that any criticism towards Signal is downvoted to oblivion, while the voices of “experts” preach PGP hysteria.
PGP will never be used by ordinary people. It’s too clunky for that. But it’s used by some people very successfully, and if you try to dissuade this small, but very important group of people to move towards your “solution”, I can only suspect foul play. Signal does not compete with PGP. It’s a phone chat app. As Signal does not compete with PGP, why do you have to spend all this insane ammount of effort to convince an insignificant amount of people to drop PGP for Signal?
I can’t for the life of me imagine why a CIA-covert-psyops-agency funded walled garden service would want to push people away from open standards to their walled garden service.
Don’t get me wrong, Signal does a lot of the right things but a lot of claims are made about it implying it’s as open as PGP, which it isn’t.
What makes Signal a closed system?
https://github.com/signalapp
Not Signal, iOS and Android, and all the secret operating systems that run underneath.
As for Signal itself, moxie forced F-Droid to take down Signal, because he didn’t want other people to compile Signal. He said he wanted people only to use his binaries, which even if you are ok with in principle, on Android it mandates the use of the Google Play Store. If this is not a dick move, I don’t know what is.
I’m with you on Android and especially iOS being problematic. That being said, Signal has been available without Google Play Services for a while now. See also the download page; I couldn’t find it linked anywhere on the site but it is there.
However, we investigated this for PRISM Break, and it turns out that there’s a single Google binary embedded in the APK I just linked to. Which is unfortunate. See this GitHub comment.
Ehm… he chose the wrong license in this case.
As I understand it, the case against PGP is not with PGP in and of itself (the cryptography is good), but the ecosystem. That is, the toolchain in which one uses it. Because it is advocated for use in email and securing email, it is argued, is nigh on impossible, then it is irresponsible to recommend using PGP encrypted email for general consumption, especially for journalists.
That is, while it is possible to use PGP via email effectively, it is incredibly difficult and error-prone. These are not qualities one wants in a secure system and thus, it should be avoided.
But the cryptographyisn’t good. His case in the blog post is intentionally besides all of the crypto badness.example: the standard doesn’t allow any other hash function than sha1, which has been proven broken. The protocol itself disallows flexibility here to avoid ambiguity and that means there is no way to change it significantly without breaking compatibility.
And so far, it seems, people wanted compatibility (or switched to something else, like Signal)
Until this better implementation appears, an abstract recommendation for PGP is a concrete recommendation for GPG.
Imagine if half the effort spent saying PGP is just fine went into making PGP just fine.
I guess that’s an invitation to push https://autocrypt.org/
Without wanting to sound rude, this is discussed in the article:
OpenPGP might have resisted the NSA, but that’s not a unique property. Every modern encryption tool or standard has to do that or it is considered broken.
I think most people unless they are heavily involved in security research don’t know how encrytion/auth/integrity protection are layered. There are a lot of layers in what people just want to call “encryption”. OpenPGP uses the same standard crypto building blocks as everything else and unfortunately putting those lower level primitives together is fiendishly difficult. Life also went on since OpenPGP was created meaning that those building blocks and how to put them together changed in the last few decades, cryptographers learned a lot.
One of the most important things that cryptographers learned is that the entire ecosystem / the system as a whole counts. Even Snowden was talking about this when he said that the NSA just attacks the endpoints, where most of the attack surface is. So while the cryptography bits in the core of the OpenPGP standard are safe, if dated, that’s not the point. Reasonable people can’t really use PGP safely because we would have to have a library that implements the dated OpenPGP standard in a modern way, clients that interface with that modern library in a safe and thought-through way and users that know enough about the system to satisfy it’s safety requirements (which are large for OpenPGP)
Part of that is attitude, most of the existing projects for implementing the standard just don’t seem to take a security-first stance. Who is really looking towards providing a secure overall experience to users under OpenPGP? Certainly not the projects bickering where to attribute blame.
I think people kept contrasting this with Signal because Signal gets a lot of things right in contrast. The protocol is modern and it’s not impossibly demanding on users (ratcheting key rotation, anyone?), there is no security blame game between Signal the desktop app vs signal the mobile app vs the protocol when a security vulnerability happens, OWS just fixes it with little drama. Of course Signal-the-app has downsides too, like the centralization, however that seems like a reasonable choice. I’d rather have a clean protocol operating through a central server that most people can use than an unuseable (from the pov of most users) standard/protocol. We’re not there yet where we can have all of decentralization, security and ease of use.
One assumes the NSA has backdoors in iOS, Google Play Services, and the binary builds of Signal (and any other major closed-source crypto tool, at least those distributed from the US) - there’s no countermeasure and virtually no downside, so why wouldn’t they?
Not really the response I’ve seen to their recent desktop-only vulnerability, though I do agree with you in principle.
Signal Android has been reproducible for over two years now. What I don’t know is whether anyone has independently verified that it can be reproduced. I also don’t know whether the “remaining work” in that post was ever addressed.
Doesn’t such process assume trust on who created the image (and on who created each of layers it was based on)?
A genuine question, as I see the convenience of Docker and how it could lead to more verifications, but on the other hand it create a single point of failure easier to attack.
That question of trust is the reason why, if you’re forced to use Docker, build every layer for yourself from the most trustworthy sources. It isn’t even hard.
I’m pretty ignorant on this matter, but do you have any link to share?
Actually, I’d like to read the opinion of GPG developers here, too.
Everyone makes mistakes, but I’m pretty curious about the technical allegations: it seems like they did not considered the issue to be fixed in their own code.
This might have pretty good security reasons.
To start with, you can’t trust the closed-source providers since the NSA and GHCQ are throwing $200+ million at both finding 0-days and paying them to put backdoors in. Covered here. From there, you have to assess open-source solutions. There’s a lot of ways to do that. However, the NSA sort of did it for us in slides where GPG and Truecrypt were worst things for them to run into. Snowden said GPG works, too. He’d know given he had access to everything they had that worked and didn’t. He used GPG and Truecrypt. NSA had to either ignore those people or forward them to TAO for targeted attack on browser, OS, hardware, etc. The targeted attack group only has so much personnel and time. So, this is a huge increase in security.
I always say that what stops NSA should be good enough to stop the majority of black hats. So, keep using and improving what is a known-good approach. I further limit risk by just GPG-encrypting text or zip files that I send/receive over untrusted transports using strong algorithms. I exchange the keys manually. That means I’m down to trusting the implementation of just a few commands. Securing GPG in my use-case would mean stripping out anything I don’t need (most of GPG) followed by hardening the remaining code manually or through automated means. It’s a much smaller problem than clean-slate, GUI-using, encrypted sharing of various media. Zip can encode anything. Give the files boring names, too. Untrusted, email provider is Swiss in case that buys anything on any type of attacker.
Far as the leaks, I had a really-hard time getting you the NSA slides. Searching with specific terms in either DuckDuckGo or Google used to take me right to them. They don’t anymore. I’ve had to fight with them narrowing terms down with quotes trying to find any Snowden slides, much less the good ones. I’m getting Naked Security, FramaSoft, pharma spam, etc even on p 2 and 3 but not Snowden slides past a few, recurring ones. Even mandating the Guardian in terms often didn’t produce more than one, Guardian link. Really weird that both engines’ algorithms are suppressing all the important stuff despite really-focused searches. Although I’m not going conspiracy hat yet, the relative-inaccuracy of Google’s results compared to about any other search I’ve done over past year for both historical and current material is a bit worrying. Usually excellent accuracy.
NSA Facts is still up if you want the big picture about their spying activities. Ok, after spending an hour, I’m going to have to settle for giving you this presentation calling TAILS or Truecrypt catastrophic loss of intelligence. TAILS was probably temporary but the TrueCrypt derivatives are worth investing effort in. Anyone else have a link to the GPG slide(s)? @4ad? I’m going to try to dig it all up out of old browser or Schneier conversations in near future. Need at least those slides so people knows what was NSA-proof at the time.
Why would TAILS be temporary? If anything this era of cheap devices makes it more practical than ever.
It was secure at the time since either mass collection or TAO teams couldnt hack it. Hacking it requires one or more vulnerabilities in the software it runs. The TAILS software includes complex software such as Linux and a browser with history of vulnerabilities. We should assume that was temporary and/or would disappear if usage went up enough to budget more attacks its way.
I’d still trust it more than TrueCrypt just due to being open-source.
What would it take to make an adequate replacement for TAILS? I’m guessing some kind of unikernel? Are there any efforts in that direction?
Well, you have to look at the various methods of attack to assess this:
Mass surveillance attempting to read traffic through protocol weaknesses with or without a MITM. They keep finding these in Tor.
Attacks on the implementation of Tor, the browser, or other apps. These are plentiful since it’s mostly written in non-memory safe way. Also, having no covert, channel analysis on components processing secrets means there’s probably plenty of side channels. There’s also increasingly new attacks on hardware with a network-oriented one even being published.
Attacks on the repo or otherwise MITMing the binaries. I don’t think most people are checking for that. The few that do would make attackers cautious about being discovered. A deniable way to see who is who might be a bitflip or two that would cause the security check to fail. Put it in random, non-critical spots to make it look like an accident during transport. Whoever re-downloads doesn’t get hit with the actual attack.
So, the OS and apps have to be secure with some containment mechanisms for any failures. The protocol has to work. These must be checked against any subversions in the repo or during transport. All this together in a LiveCD. I think it’s doable minus the anonymity protocol working which I don’t trust. So, I’ve usually recommended dedicated computers bought with cash (esp netbooks), WiFi’s, cantennas, getting used to human patterns in those areas, and spots with minimal camera coverage. You can add Tor on top of it but NSA focuses on that traffic. They probably don’t pay attention to average person on WiFi using generic sites over HTTPS.
Sure. My question was more: does a live CD project with that kind of aim exist? @josuah mentioned heads which at least avoids the regression of bringing in systemd, but doesn’t really improve over classic tails in terms of not relying on linux or a browser.
An old one named Anonym.OS was an OpenBSD-based, Live CD. That would’ve been better on code injection front at least. I don’t know of any current offerings. I just assume they’ll be compromised.
I think it is the reason why https://heads.dyne.org/ have been made: Replacing the complex software stack with a simpler one with aim to avoid security risks.
Hmm. That’s a small start, but still running Linux (and with a non-mainstream patchset even), I don’t think it answers the core criticism.
Thanks for this great answer.
If you can share a few of your search terms I guess that a few friends would find them pretty interesting, with their research.
For sure this teach us a valuable lesson. The web is not a reliable medium for free speech.
From now on, I will download from the internet interesting documents about such topics and donate them (with other more neutral dvds) to small public libraries around the Europe.
I guess that slowly, people will go back to librarians if search engines don’t search carefully enough anymore.
It was variations, with and without quotes, on terms I saw in the early reports. They included GPG, PGP, Truecrypt, Guard, Documents, Leaked, Snowden, and catastrophic. I at least found that one report that mentions it in combination with other things. I also found, but didn’t post, a PGP intercept that was highly-classified but said they couldn’t decrypt it. Finally, Snowden kept maintaining good encryption worked with GPG being one he used personally.
So, we have what we need to know. From there, just need to make the programs we know work more usable and memory safe.
This is the best article I’ve read on this topic and it pretty clearly demonstrates why the community and attitude around a standard matters.