People keep on saying Schneier says it's good, did he actually check each and every line of the source code? Not to mention that I read somewhere that they ban you on their forums if you ask them these questions.
Let's see the ChangeLog:
"Improvements and bug fixes:
Minor improvements and bug fixes (Windows, Mac OS X, and Linux"
Minor improvements and bug fixes :) This is how you write your ChangeLog friends!
I was arrested sometime in early 2011 (let out after 7 hours without charges, which was a fun story in itself). In my pocket, they found two USB sticks. one was a Linux Mint LiveUSB. The other USB stick was encrypted via LUKS. The police could have booted of the LiveUSB, and then inserted the second USB to decrypt it. if they had decided to force me to divulge my password, they would have found all sorts of incriminating things to keep me for longer.
However, this did not happen; when inserted in the police's Windows PC's, they merely popped up a "This drive is not formatted. would you like to format it now?" message. Naturally, they clicked "no" and gave me back the stick. I owe a part of my freedom to Microsoft's and my local Police's devotion to the Windows OS.
TL;DR - LUKS not working in Windows OS is a feature, not a bug.
Just look at WW2. There were times that the Allies knew things would happen, but couldn't act on them because it would tip their hat to the Germans that there was a leak somewhere (possibly leading them to the knowledge that the Allies had cracked Enigma), and the pay-off wasn't worth the risk.
Nitpick; "shred" is a better alternative to "srm", since "shred" is always installed.
There's more to this long running debate, but that's the gist of Appelbaum's position.
My take: Plausible deniability gives you the option to defend the fifth, lie, or give up your data, but your confession may never be plausible. Which is better depends on the sensitivity of your data and the willingness of your adversary.
How will giving up the password ensure there isn't 'another' hidden volume?
First, Part 1 is only 1 hour and 17 minutes long (though perhaps it felt much longer to you).
Second, while the subject of TrueCrypt comes up a couple of times in the Q&A period, it's not the main subject of the talk. The talk is about privacy, anonymity, surveillance, and what can be done about them.
I highly recommend watching this video, especially for people who might not be up to date on all the latest privacy-enhancing technology or who might not be very aware of how much digital surveillance there is these days. Even if you do know about these things, it's still interesting to hear an intelligent, articulate presentation about them.
There is no such thing IMO as only 1:17 when referring to a presentation/talk. I tune out after about 10 minutes, 15 or so tops (e.g. for the git imerge discussion).
Anything that is so complicated that it requires that much exposition is something that I will read about or probably not find out at all.
It's insanely useful especially on "shared" web servers; much more so than chkrootkit or rkhunter.
 - http://www.rfxn.com/projects/linux-malware-detect/
- It can verify hashes using the package manager.
- It can report use of deleted files. After clearing the false-positives this can help to detect some malware that is only in memory and already deleted on disk
- Support for unhide¹ - This should help against rootkits - but I'm not sure how reliable it is nowadays
Add 100% competent to that too. I expect a bug is much more likely that a dishonest sysadmin or dev.
Qubes OS is a new xen based OS that takes security by isolation to a new level. Still young but I'm keeping my eye on it.
The article just convinces me of the need for highly tested/developed security focused distros. There are so many ways to screw up.
I would use a VM on a "live" system, booted from removable media, to which no data is ever written. (DVD)
But it wouldn't be any Linux distro.
BSD is what I prefer. Take your pick of the available options, NetBSD, OpenBSD, FreeBSD, *BSD.
If you want an excuse to try switching to Dvoraks, how about not having the semicolon on the home row?
This post linked from TFA is pretty good justification for SecureBoot, even if the protection provided by SB as it's implemented now can be bit questionable.
I'm not sure why this would be a problem, maybe an attacker can see that you haven't rebooted to install a kernel update?
Uptime can be used as a source of "randomness" in PRNGs, so knowing that bit of information could clearly be beneficial to an attacker.
http:// ompldr.org / vaG5mcQ / sudoaptgetinstallmthrfckr-610x250.png
click at your own risk..