Google
  Web www.spinics.net

Re: tripl - command line wrapper for single or multiple encryption with loop-aes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


* phil <wdef200@xxxxxxxxxxxxxxxxxxxxx> wrote:

> > point out that key scrubbing is only available for AES, not the
> > other ciphers.
> 
> I was under the impression (perhaps I'm wrong) from a post of
> Jari's, where he said that loop-aes always tries to remove
> passphrases from memory by default on a clean unmount anyway.

IIRC, that's true for mount operations via fstab entries only.
Setting up the device first via losetup -F /dev/loopXXX and then mounting 
/dev/loopXXX to some mountpoint doesn't achieve this. Noteworthy to
keep in mind if you run checks on a device and mount afterwards if 
there's no error.


> Enabling "keyscrub" does something else I believe viz. results in

Yes, I meant exactly that.


> moving key bits around in such as way that "burn in" to RAM is not
> likely.  However, "burn in" to RAM has never been proven to be a
> threat afaik, since no one knows if the technology exists to
> recover plaintext keys that have been thus burned in. Unlike the
> proven threat of the cold boot attack, which relies on simple
> remanence, not burn in.

On some cryptography mailing lists rumour has it that such an attack
succeeded, at least under lab conditions. No hard evidence came to my
attention though, so I assume it can be done by a sufficiently
sophisticated attacker.



> > Regarding journaling filesystems, disabling of harddrive
> > cache is recommended (I do so via hdparm -W0 /dev/hdX) if no UPS is
> > used.
> >
> Do you have a link (perhaps to the list archive) with more info on
> this?  I only vaguely recall what it was all about.

Not really, but a context of sorts:

Bad stuff happens with enabled HDD cache, power outages and no UPS to
guarantee a clean filesystem shutdown. It all depends on the
filesystem used, really, some are more resilient than others. YMMV.
ReiserFS has good net references, ext3, too. XFS has a bad
reputation, there's reports of file truncation / garbled files not in
use at time of disaster; think of a garbled /etc/passwd, while
xfs_check and even xfs_repair deem the filesystem to be OK.

I tested XFS (in various setups) and switched back to ext3. I've run
into my fair share of XFS troubles, and I cannot recommend its usage
in combo with loop-AES and external HDDs.

-- 
left blank, right bald

Attachment: pgpoirYvTp6Ih.pgp
Description: PGP signature


[Home]     [Kernel]     [Linux Crypto]     [Gnu Crypto]     [Gnu Classpath]     [Netfilter]     [Bugtraq]     [Network Security Reading]

Add to Google