Re: Encrypted containers

"Stachu 'Dozzie' K." <dozzie@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> (06-05-31 17:53:10):

I don't like LUKS. It's written by the same people as device
mapper. I'd rather use Loop-AES.

I don't like it either, and I don't use it. But I do use dm-crypt,
because it's more suitable in my case. I use both AES (for my
filesystem) and Blowfish (for swap, because it's faster). As far as I
know, Loop-AES does only support AES.


The problem is strength of user's password.

Yes, but that's not the developer's responsibility. Other people
should care about that.

But it should be pointed out. Near cryptography there are some obvious
things which, if comes to end user, are not so obvious.

I didn't mean the users themselves. Other people like documentation
writers or frontend designers should do that. On the other hand, the
developer should make sure that their software cannot be used in a wrong
way.


Just to say my thoughts loud (I'm planning writing such a module):
how should multiple logins be handled? Probably some kind of
counter (GDBM database?) for each logged user, cleaned up on
reboot. And there should be additional directory with encrypted
keys to filesystem.

That can be as easy as "do not unmount, until the user is logged out
everywhere". Those counters are already there, you just need to use
them.

You mean where? wtmp? It's not updated when you execute non-login shell
via ssh ("ssh yourhost bash -i") and can display logged users when
they're not logged. Do you have better place? Indeed, it would save me
some work.

Well, I would just look if there is any process running under the
particular username. That should cover every case. You also could let
the user handle this via callback-like shell-scripts, and provide some
example scripts for basic configurations.


There is no point in writing your own, possibly buggy counters. The
keys can be stored on the filesystems themselves (encrypted with the
user's password, of course).

Do I understand you correctly? You want to store keys for encryption
on an encrypted filesystem?

Yes. Generate a hash of the user's password, XOR it with the actual key
and save the result. Or encrypt the key with the user's password, but
that would be essentially equivalent in terms of security (as long as
the output of the hash function is as large as the key).

Saving the key elsewhere would actually be security by obscurity. But
you may provide that as an option.


Regards,
E.S.
.

Relevant Pages

  • Re: Encrypted containers
    ... encrypt with password just an encryption ... You'll want to create one encrypted filesystem for each user ... for each logged user, cleaned up on reboot. ... The keys can be stored on the filesystems themselves (encrypted with the ...
    (comp.os.linux.security)
  • Re: Encrypted containers
    ... counter (GDBM database?) for each logged user, ... keys to filesystem. ... I thought about storing the key for FS encryption, ...
    (comp.os.linux.security)
  • Encrypted Filesystem
    ... - Seamless application to the root filesystem ... accordingly by the encryption layer ... all with varying degrees of modification to the kernel ... - NFS-based (CFS, TCFS) ...
    (Linux-Kernel)
  • Re: Encrypted Filesystem
    ... Bounce kernel & fs ideas off the kernel ... > - Seamless application to the root filesystem ... > accordingly by the encryption layer ... not as well accepted or tested as CFS ...
    (Linux-Kernel)
  • Re: encrypted filesystem or files, which is best?
    ... Can filesystem encryption be done on an existing linux filesystem, ... would a person set up filesystem encryption on an existing linux PC, ... If you really want to encrypt your root filesystem, ...
    (comp.os.linux.security)