Re: Encrypted containers



On 31.05.2006, Ertugrul Soeylemez <never@xxxxxxxxxxxxxx> wrote:
"Stachu 'Dozzie' K." <dozzie@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> (06-05-29 14:23:14):

Now to the interesting part. Actually, that guy is reinventing the
wheel. Using PAM (pluggable authentication modules) is the better
approach. Every user should need a secure password to log in (which
I'm assuming here). Why not use that password for filesystem
encryption, too, on a per-user basis? That way, the data is not
only protected from foreign attackers, but even from internal
attackers (no two users should use the same password anyway), and
their security does not depend on where you place your USB devices
at home.

I was thinking about something similar, Loop-AES based. I think that
using password from /etc/passwd to encrypt _whole filesystem_ is a bad
idea. Consider user who wants to change his password. But it's quite
easy to fix this problem: encrypt with password just an encryption
key. It's easy to decrypt that key and encrypt it back using new
password, when changing passwords.

Yes, and that idea has already been made code of, but not on a per-user
basis. See LUKS.

I don't like LUKS. It's written by the same people as device mapper. I'd
rather use Loop-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.

They are used to authenticate users, but they can do more when told
to. You'll want to create one encrypted filesystem for each user
and mount it, as the user logs in, and unmount it, as they log out.

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.

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?

Maybe as a filesystem prefix, like in
LUKS. You may even want to use LUKS (which is only a specification) as
a base to start with. That would save you some development work.

--
Feel free to correct my English
Stanislaw Klekot
.



Relevant Pages

  • Re: Encrypted containers
    ... I'd rather use Loop-AES. ... filesystem) and Blowfish ... counter for each logged user, ... You want to store keys for encryption ...
    (comp.os.linux.security)
  • RE: Email Encryption Between Servers
    ... Secure E-mail, PGP, secure web server, ... Are the doctors going to have separate keys for each provider, doctor, ... desktop e-mail encryption, enterprise e-mail encryption. ... manage key exchange, staff training, ...
    (Security-Basics)
  • My response to a message by Dorothy Denning in 1995 - Australia and Encryption Policy
    ... Subject: Australia and Encryption Policy ... interception, which includes the issue of the use of cryptography as: ... keys but may be required to provide them in response to a court order. ...
    (sci.crypt)
  • Re: OTP and message integrity.
    ... Without the keys, ... You provide some level of integrity, ... The encryption is provided by an OTP. ...
    (sci.crypt)
  • [UK] Government wants your view on encryption keys
    ... GOVERNMENT WANTS YOUR VIEW ON ENCRYPTION KEYS ... The Home Office is getting ready to enforce Part III of the RIP Act, ... Regulation of Investigatory Powers Act 2000] will, ...
    (alt.privacy)