This is perfectly understandable and logical - it means 100th the price. ironically there are lots of examples of misuse of maths about, e.g.:

"divided by half" - a bastard of "divided by two" and "multiplied by half", which actually means the exact opposite: multiplied by two.

"a half less" - a chimera of "half as much" and "half of", which again means the opposite.

"0.01 cents" - a mongrel of "one cent" or "$0.01", instead giving a price 100 times cheaper.

So let's save our outrage for the next time someone tells us it's good news the number of deaths has "divided by half", or crimes are "a half less".

doesn't mean worse. Basically this is saying that while SEDs are not vulnerable to a “cold boot attack” like software encryption, it is vulnerable to equivalent attacks.

The answer to all these attacks is to always completely shut down, never sleep, your laptop.

You're thinking of 'WinZip' style encryption, there are apps nowadays that do 'virtual drive' encryption and encrypt/decrypt on the fly, like a SED.

Have you got any evidence of this? It would be a major news if *every* HDD manufacturer was back-dooring their drives in this way. Although it certainly sometimes happens.

Hardware RNGs are preferred to software CSPRNGs

it's

True, but you should be aware that by a surprising coincidence a very similar bug has been found in LibreCrypt at the same time as this TrueCrypt bug.

It's hard to see how else to interpret your post:

Or did you mean a single bit of ciphertext changed would somehow corrupt the rest of the ciphertext?
I've no wish to get involved in a discussion on other aspects of encryption, just wanted to simply correct a false statement, and get something off my chest about the design of LUKS.

The context of the original post was discussing recovering plaintext when a bit of the ciphertext was corrupted - assuming you have the key and no backups.
In this case 'plain' dm-crypt results in typically 128-256 bits of plaintext not being recovered. This guy has done some experiments and says in practice it's similar between corrupted encrypted and unencrypted data.
With LUKS, if the corruption is in the data, then the result should be the same as for dm-crypt.
But with LUKS, if the corruption is in the header, then there is a possibility *all* the data will be lost (again, we are talking of with the key, but no backups). LUKS is actually designed to maximise this possibility.
The logic is that an attacker is more likely to have a corrupted file. With a password based encryption sheme, the best proxy you have to an 'authorised' person is one who knows the password - in fact that's the only proxy you have.
So making it more difficult for people with the password to read the data, without making it more difficult for people without it to read the data, is a misfeature IMO.
An attacker maliciously changing the ciphertext to change the plaintext in a predictable way is another issue, but LUKS and dm-crypt are equally bad in this respect as neither support authenticated encryption modes.

No, this isn't true. Depending on the encryption mode, a corrupted bit should mean one or two blocks being lost (typically 256 bits). LUKS OTOH has a feature called "anti-forensic stripes" that is deliberately designed to *maximise* the data loss if bits are corrupted on disc. One of the worst/best examples of a mis-feature ever.

This is the politician's syllogism at work: "Something must be done. This is something. Therefore this must be done".
The horror of the Hebdo attacks is that they are attacks on the freedom of speech. Allowing the gov't to spy on all our internet traffic is a far greater attack, because anonymity is the best defence of free speech. It's like someone responding to seeing you have a nosebleed by cutting off your head with a chainsaw "to make sure it doesn't happen again" .

It's called Deniable encryption and it's difficult to do correctly

Thanks for posting this. I am the maintainer of DoxBox. If you have any questions or want to flame me about the name, go ahead.

Thanks for posting this. I am the maintainer of DoxBox. It's not entirely accurate to say it's a 'new' program, because it is a re-launch of FreeOTFE. The github project is here.