debian@xxxxxxx wrote: > Interactively, 127 bytes - OK (don't want to use that one, I want to use the > "-p 0" option). How do I find out the limit of mlock()able RAM sizes? Kernel puts some limit of how much of RAM can be locked. I don't remember correct limit, but it may be something like half of RAM or something like that. There is a potential security hole or Deny-of-service here. non-root users can can send megs of data to "mount -p 0" and setuid-root mount will mlock() that RAM. Next version of loop-AES' util-linux patch will put brakes at 4KB of passphrase data received through "mount -p 0". Compatible or not, this is a security issue. It does not make sense to use passphrase longer than few hundred bytes. > Does performance go down when I use a > long password compared to a short password? Normally no. > I have not used gpg before, maybe I will use it later on. However, I think > it's bad to let loop-AES depend on gpg to make the security level higher > that the security level you could get with a password (a *very* long > password, as described above). I prefer not to reinvent the wheel here. gpg implements good symmetric cipher crypto as well as good public key crypto. If gpg was not used, a tool had to be written to duplicate that functionality. > I have been using mcrypt to encrypt a key file (which is my *very* long > password). Then, I decrypt the key file before it is piped to the losetup > command. Like this: > > # cat keyfile | mcrypt -d | losetup -p 0 -e aes256 /dev/loop1 /dev/sda1 > # mount /dev/loop1 /mnt/vault I hope the "losetup -p 0" passphrase is 4094 or less bytes. Otherwise it will be incompatible with next version loop-AES' losetup and mount. -- Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
