CipherShed Forum

It's great in benchmarks, when it comes to TrueCrypt in real operation, you find you're already bottlenecked by I/O you can saturate the SATA bus as it is, then net effect in use is no benefit.

Do you have any data to support that, or just personal opinion / experience? I would be very interested.

It's easy to determine, just encrypt a disk and time it, then look up the disk's maximum sustained write speed, you'll find you're at or very near it when it comes to the time taken, speeding up the processing won't help.

Calculations posted on the old TC forum by GrandAdmiralThrawn demonstrate it to be the case, but by all means test it yourself to confirm. Sorry I can't do the test for you I only posess SATA 2 machines, Empirical proof requires SATA 3.

Merlin wrote:It's great in benchmarks, when it comes to TrueCrypt in real operation, you find you're already bottlenecked by I/O you can saturate the SATA bus as it is, then net effect in use is no benefit.

It really only becomes a major issue with SSD drives, and since SSD drives are discouraged anyway, it's less of an issue. However, I use TrueCrypt on this laptop, with it's 240GB FDE SSD

As SSDs become more and more common, making use of accelerated encryption becomes more attractive. We may also want to determine if there is any way to improve securing on non-encrypted SSDs, since the encrypted volume is spread all over the flash memory, making it clear what the file access patters were, eliminating any chance of being believed when claiming a volume is not in fact a TrueCrypt volume. Then there's the possibility of an NSA back door in the Intel CPUs.

Fast as SSDs are, the speed increase is purely the elimination of seek times, you can only shift data down that SATA cable at a fixed maximum rate, even if you had some storage medium from star-trek at the other end that could handle a petabyte per second. It's a "no real gain" with any current technology TrueCrypt can already supply data that fast on any modern machine.. that could easily change if we see a new SATA standard, or some other storage interface take over, for now though...

I'm not saying don't do it, offloading from the CPU main cores to hardware AES frees the CPU for other processing, I'm just pointing out, you won't see as much gain as you might be thinking you will.

Just in case no one has requested it already, have we considered stenography at all?

Like at least one other tool I read about, we could encrypt a TrueCrypt volume in the noise level of sound or image files. I have a lot of .wav files that are lossless, and those would work great. Similar things can be done with PNG and GIF image files. The way TrueCrypt volumes appear to be perfectly random data is perfect for this. I don't know how useful that would be, but it sounds fun.

WaywardGeek wrote:Just in case no one has requested it already, have we considered stenography at all?

Like at least one other tool I read about, we could encrypt a TrueCrypt volume in the noise level of sound or image files. I have a lot of .wav files that are lossless, and those would work great. Similar things can be done with PNG and GIF image files. The way TrueCrypt volumes appear to be perfectly random data is perfect for this. I don't know how useful that would be, but it sounds fun.

An adversary with repeated access might wonder why the file's checksun kept changing if such a volume were used, plus capacity would be rather limited (to say the least) a technique better suited to hiding individual static files I would think.

But feel free to shoot me down in flames.

WaywardGeek wrote:Just in case no one has requested it already, have we considered stenography at all?

Hi Wayward!
As an interested hobbiest and observer, I think this would be a mistake. For one, it would be a whole new direction, which, if not implemented perfectly, could put users into a false sense of security. There have been notable cases recently where St. has outed people who thought they had privacy. The ability of some unethical organizations to stastically analyze things is undoubtedly robust.

If you want to go into new avenues, I think a module for one time pad would be more useful than what you suggested. I know linux has one, but it's not easy to use. I mean an Entropy Module, A Cut and Paste Function, and a Record Keeping (no reuse) Function. If a huge amount of entropy were collected for use between two parties, the whole shebbang could be called OneTimePadForLife. You meet someone, sync, and you're done (at least in terms of text, not big files) for life. This should only be attempted with a really serious source of entropy. Something like r. decay, diode noise, or carefully timed accelerometer data. I don't trust Intel hRNG; better to be something real world, maybe even apart from the PC.

In all likelihood, what I mentioned would probably be better as new, seperate project, but what do I know.

I actually already built that project! I built my own random number generator based on zener noise back in the late 90's with my Dad, as well as an email app with a nice GUI that would let you email back and forth messages with attachments, all OTP encrypted. It was fun, but the truth is I never had any reason to send any secret messages to my Dad. The TRNG I built passed the Diehard tests, and was SFAIK, the first TRNG to pass. I used an 8-bit 40MHz $3 A/D converter and rotated the bits, and XORed the outputs of 80 samples in a row. The low 4-ish bits were visually quite random, and the upper bits not so much. The 80 XOR/rotate results passed Dieharder with no additional processing. The board produced 500KB/s of true random data. I sill have it.

Is there some reason why SHA512 with a generous salt and many iterations (linux basically defaults to 5000 rounds) is not a good choice? RHEL and DOD certainly seem to think it is.

fnj wrote:Is there some reason why SHA512 with a generous salt and many iterations (linux basically defaults to 5000 rounds) is not a good choice? RHEL and DOD certainly seem to think it is.

I can't speak for the devs, but it seems to me, that short term, simply increasing the iterations for what's there is the easiest thing to do.
And long term, memory hard functions are a better solution than hash functions easily parallellised using multiple GPUs or FPGAs to make fast brute forcing machines.