"Trust no one! Suspect EVERYTHING!", I can say today without sounding crazy.
Also, remember this? http://www.linuxfoundation.org/news-media/blogs/browse/2011/... ....hmm, I wonder if....
"Trust no one! Suspect EVERYTHING!", I can say today without sounding crazy.
Also, remember this? http://www.linuxfoundation.org/news-media/blogs/browse/2011/... ....hmm, I wonder if....
The difference between "tinfoil hatters" and reasonable people like Bruce Schneier now seems to be how concerned they are with their ability to destroy a harddrive, and TEMPEST.
Which way is that?
Also, from your Tinfoil Hat Linux link, this idea is hilariously awesome:
Keystroke monitoring — THL has gpggrid, a wrapper for GPG that lets you use a video game style character entry system instead of typing in your passphrase. Keystroke loggers get a set of grid points, not your passphrase.
I wonder if it might be possible to implement that idea into other operating systems?
https://www.schneier.com/contact.html
All default settings, except the 4096-bit key length.
See: https://www.schneier.com/blog/archives/2013/09/my_new_gpgpgp...
http://www.theguardian.com/world/2013/sep/05/nsa-how-to-rema...
Air gapping is certainly not unprecedented, but individuals using it have traditionally been considered pretty "tinfoil-y".
edit: "I wonder if it might be possible to implement that idea into other operating systems?"
gpggrid itself could probably just be built on any other Linux install. Certainly it could be recreated. One of the neat features of TFL that I really like is the idea of blinking LEDs on the users keyboard instead of displaying things on screen. Effective? Who knows... but certainly amusing.
http://www.washingtonpost.com/wp-dyn/content/article/2010/08...
Search for "Bootable SD Card Method" here: http://chdk.wikia.com/wiki/Prepare_your_SD_card (I have a Canon camera that runs CHDK. Those instructions work, and the camera can write to the SD card.)
It's a Linux live system (with permanent storage on a USB stick) geared specifically towards online banking.
I believe that quite a few people actually use it.
Of course the hardware is the same, but you get a clean single purpose software system.
>I believe that quite a few people actually use it.
That sounds like a great attack vector. How secure are factories where discs are pressed? Even without access to the factory you could buy a bunch of magazines and repackage them with compromised CDs.
Repackaging it seems to be tricky, since the paper inlay is bound in the magazine, it's not just stuck on the cover or whatever. You tear it out at a perforation, leaving part of the DVD cover inside.
There are much more exposed attack vectors on online banking users, I would think.
And you can always just download the ISO and check it against the hash (and the PGP key).
These are still not immune to phishing attacks but it's a lot better than TAN codes or some other 'dumb' authentication scheme.
Typically these systems work in conjunction with pin-and-chip card, a small piece of hardware that generates the codes and a challenge / response system built into the website you use for the authorization.
Separate challenges exist for logging in (read access) and transferring money.
Another cool thing I've seen in Banco do Brasil was the need to authorize the computer you're going to use in a ATM or in a 1-800. If I recall correctly, they do that with a Java applet.
Recently they also launched a common-malware-search-and-destroy application of MANDATORY use in Windows computers (my mom uses, she asked me. And yes, the digital certificates were all valid).
Others may use in-house solutions. Here's Bank of America's two factor solution: https://www.bankofamerica.com/privacy/faq/safepass-faq.go
We're almost to a point where the question isn't whether or not they support it, it's finding out that they have a program, clicking through tiny text links at the bottom of pages, and figuring out how yet-another-implementation works.
The general idea is to use a machine which has minimal opportunity to be compromised through other activities. There have been known to be exploits that allow a compromised VM guest to compromise the host, and obviously if you compromise the host you can compromise all the other guests.
Using a separate VM is worse than using a separate physical machine and better than doing nothing. Whether it's "good enough" depends on who you are. Who are the plausible attackers? What do you stand to lose if it goes wrong?
[1] in other words if the host OS is used as a hypervisor, or if the host OS _is_ a hypervisor.
Oh so he encrypted his files, and walked them between his stand alone and his internet machines. Yeah, okay this established the file's integrity, and that's just fantastic.
But what assurance does he have that the USB stick isn't getting infected on the internet machine, and then deploying stealth hacksaw services onto the standalone, to buffer and relay data and commands each time it jacks in?
I mean, that's exactly what Stuxnet was designed to fucking do.
Things like the Bagram PX were concentrations of high value targets with only one source of supply. The general USB stick marketplace is a lot safer. In China they're often fake and thus unreliable (smaller than advertised), but in the US, I'd be pretty comfortable driving to a Best Buy 50 miles away and picking up a random USB token.
A USB key someone hands you is much more likely to be a targeted attack. A USB key randomly lying on the ground outside a target is also much more likely to be an attack.
That doesn't mean there are no attacks.
So prudence is adviced in either case, on the off chance that the one that you have is a bad one. Ditto for anything else that you stick into a USB port.
That webcam plugged into your computer, are you sure the mike isn't on all the time and that the driver doesn't pass your speech during the day out in compressed and encrypted form to some server farm at night ;)
IMHO, the hard part would be creating the interface on the on the pc.
This should be the new market: Companies inviting the whole world to inspect their hardware (in addition to firmware, software).
KDE/Gnome do the same thing, and there are possible attacks there.
Randomizing the position of landmarks eg. go to A, B, E, C, F, then showing a map could let the user enter a different sequence of keystrokes to get the same result.
So, some evocatively named Linux distro recommends the same key size, is what I understand you to be saying, and therefore... what? Aliens really did land at Roswell?
Anyways: don't use 8192 bit keys. Whatever kills the 4096 bit keys is going to kill RSA along with them. Honestly, I think 4096 bits is also kind of a you're-kidding-yourself key length; if attacks on 2048 bit keys became tractable, RSA is probably in serious trouble.
I get truly excited when I see your replies, I'd love to banter in [inebriated] public! With that said, may I please make the humble request;
Yoou have contributed a shitload of awesome comments on the state f "who-the-fuck-are-we-kidding" with respect to encryption and privacy in light of what we actually know now related to the NSA....
Would you please create a post, in an Explain-Like-I-Am-Five-Years-Old manner on both the state of the capabilities of the NSA, the state of current encryption tech/methods we rely on, AND what the heck I, as and individual, could/can/should do about protecting myself.
---
I can speculate all day long about all sorts of things, but I am asking - given the NSA-Fatigue I suffer from - fr your help.
I WILL PAY YOU FOR THIS SERVICE; Set the price at $20 for the best recommendation. Crowd-source your network of people who have enough info to contribute to the recommendation...
Aside from smashing my machines and cancelling my power utility, I have no clue how to regain privacy at this point.
Then we will drink, and e Merry, Pippin and Sam!
EDIT: Tawny Port May be responsible for this post.
Also, if you had a short string that could be expanded into the larger key, then what you really have is a short key to a slightly different crypto system, which is less secure than the original key in the original system.
Also, if you can significantly compress a string of truly random data, you can also probably compress digital video by a significant factor as well, and should therefore found a startup selling your groundbreaking compression technology.
No, certainly not. I agree with you; the change from 2048 to 4096 isn't interesting.
The interesting part is that he 1) generated a new key (okay, not actually interesting in itself), 2) is using it in an isolated install, 3) this isolate install is on entirely separate hardware, not just a VM, 4) this separate hardware is new hardware that has never been networked.
Tinfoil Hat Linux was never really about using large PGP keys, you could use large PGP keys on a co-located RHEL box just as well as you could on an old crusty THL box covered with shoes and bluejeans in your closet. Rather, Tinfoil Hat Linux was about cautious (really, hyper-paranoid for the hell of it) treatment of private keys and plaintext. Extremely cautious treatment of plaintext and private keys is what he is currently going out of his way to do.
Is going to such an extreme (new hardware that has never been networked?) really necessary? I don't have the expertise to say. What I can say is that is nearing the sort of baseline paranoid treatment of private keys and plaintext that THL is known for. He's not blinking out leaked documents in morse code yet, he isn't worried about white vans down the street reconstructing the images on his monitor or RF leakage from his CPU giving them bits of his private key, but we are at the point where that is the next logical step.
(And no, aliens never landed at Roswell (or anywhere else), JFK was shot from the Book Depository (and only the Book Depository), and Stanley Kubrick did not film the moon landings (that was done with television cameras mounted on tripods, the LEM lander legs, and the astronauts' chests))
Since Schneier's now doing analysis of unreleased Snowden documents for the Guardian, he now has reason to believe that the NSA has a strong motive to see what documents he's working on.
Seems to me that the level of tin-foil-hattery that's reasonable to protect against an organisation likely to be targeting you specifically needs to be an order of magnitude greater than that which is reasonable to protect against a general-population surveillance dragnet.
However, Schneier was a target well before this due to the nature of his work. It is exactly the scope of the recent revelations that throws the conventional thinking on where the fuzzy line between an appropriate risk assessment based on position of interest and the general population. When the potential dragnet is widespread and permanent I no longer have to only consider how important I am now (which I'm not), but I also have to consider if I will ever be take on a role that IS important not just now, but then.
He knows too much to be a reasonable person.
Bruce isn't a nutter. I don't think many people would actually argue otherwise.
It's really not that hard to say this seriously without wearing a tinfoil hat. I've been doing that since high school.
The key is thinking in terms of operations, rather than in terms of generic trust. You need to know what you're doing, maintain opsec and have a strong, realistic threat analysis. For me, the Snowden cascade hasn't changed anything: if someone can penetrate the USGov's defenses, then they can almost certainly penetrate mine.
And that has always been true.
The revelations are a matter of ideological trust--trust in whether or not someone agrees with you--, but the USGov has never had much of this kind of trust, not even at its founding, nor has it ever acquired it.
That's sort of where I've gotten to this summer. It's really frustrating and saddening.
Although mind-control waves still aren't, TO THE BEST OF MY KNOWLEDGE, a thing.
knowing that you're under constant surveilance and your every step/action is recorded makes wonders in the way of shaping and controlling your behavior.
Also, culture is the best mind control. Raise people with a mind set the way you want it and you never have to do anything directly, because they already are siding with you even through cognative dissonance.
Yeah, we're self aware and all that, we have choices, but what we generally choose to do is identify with some group and hate opposing groups. It's what we do.
The chimpanzees are laughing at us.
People are definitely swayed by overt, liminal signals in subtle ways, but subliminal messaging specifically was created by an ad agency and the science was pretty well debunked.
Or else, you're one of them.
What's seemingly worse/more crazy is many of these materials date for 4-5 years ago (2008-09). If these data were public, it would have potenially casued huge behavioural shifts.
In that way, its reminiscent of 9-11 where the damage was done not on that day, but the years earlier when the bad guys were training in plain daylight.
In fact, trying to slip it in under the radar like that would actually just increase the chances of getting caught, because then it becomes something that isn't suppose to be there instead of merely something that does something that it isn't suppose to do.
For example (completely hypothetical), you could create a race condition in the kernel's page allocator that can be reliably be triggered by filling up physical ram and then forcing the kernel to allocate more memory for itself by filling up the proc table past a certain size. So in one patch you include an improvement to the allocator that has this obscure race condition but otherwise makes the allocator work much faster. Then in another patch you increase the maximum size of the proc table (under the pretense of supporting some big-iron system that practically no one outside of some HPC centers own) so that filling it up will force a kernel page allocation. So then you can force the exploit to occur on any system with both patches installed simply by allocating all the physical ram and then creating a ton of do-nothing processes that max out the proc table.
If you are an organization like the NSA you could even have the submissions come from what appear to be completely independent developers.
It is kind of the exploit version of "parallel construction." You know the exploit you want to put into the kernel, you just need to come up with reasonable sounding explanations for every little patch that ultimately gets you to the end goal.
Original article: http://news.slashdot.org/story/01/01/25/1343218/directvs-sec...
Fascinating background story here: http://www.wired.com/politics/security/news/2008/05/tarnovsk...
So the question is, which is harder: does it take more skill to accidently insert a bug that gets by (sometimes for years), or to do so on purpose?