Re: Questions about loop-aes and the implementation of encryptedfilesystems

[Lars Bungum <lars@xxxxxxxxx>]

On Thu, 2004-02-26 at 19:37, Jari Ruusu wrote:
> > Journalling file systems.  Will it be safe to run journalling file
> > systems, or does one risk loss of data if the power is switched off,
> > etc, on an encrypted file system?  Is there a recommended filesystem at
> > all, or is the question itself irrelevant for such encryption?  Can
> > write cache be used?
> Device backed (partition backed) loops are ok with journaling file systems
> at least when used with loop-AES. Mainline (current -bk version)
> loop+cryptoloop combo is no longer journaling file system safe.

I'm glad to hear it's safe as such file systems is a desire here.  But I
would like to know also why this is the case.  I suppose what I really
fail to understand is why this isn't safe in the cryptoloop system. 
Maybe there is somewhere I can read up on this?

> > Changing of passwords.  If one has a system of gpg keys and with
> At least current version of loop-AES' mount does not support that. You have
> to write your own scripts to do that. Depending how gpg encrypted key file
> was set up, changing password is either re-encrypting key-file contents with
> new password or changing gpg secret key password.

Yes, I was prepared to do some scripting here, but my problem is that I
don't really see how I should best do this.  If the requirement is that
passwords expire after one year, how do I know if the password is a year
old?  Since the hardware clock can't be trusted, I'm looking into
hardware solution with own authorization or trusted clocks.  A counter
on the USB dongle could also just be reset, booting the encrypted system
with the old password.  Is there a good way to do this with gpg?

> Here compatible means that unencrypted loop devices do not livelock during
> suspend to disk. If there are encrypted loops active when suspending to
> disk, encryption keys will get written to disk when kernel RAM is saved to
> suspend partition, therefore completely voiding security of those keys.

Thanks for the clarification!

-- 
Cheers,
Lars Bungum                         <lars@xxxxxxxxx> <OpenPGP:E2C5C0A2>


-
Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/