On Fri, Aug 28, 2009 at 12:51 AM, Andreas Jellinghaus <[email protected]> wrote: > Alon mentioned: > > Look also into [1]. > > [1] http://wiki.tuxonice.net/EncryptedSwapAndRoot > > hmm. looks interesting, here is my quick review: > * normal suspend worked fine for me, so unless tuxonice has a degression or a > different interface, the suspend mechanism in your kernel shouldn't matter. > (but I must admit, I haven't looked into the suspend evolution too close in > the last few years, but I saw the flame-war on linux-kernel about different > camps with different ideas, so I guess my knowledge is out-dated.)
No... You got all wrong. This all about on who strong you want to protect the data. > * loop-aes? sorry, but loop devices have inherent problems, even if nearly > noone triggers them, and I see no reason to not use the modern dm-crypt > in general. given the "discussion" I read about loop-aes once, I rather > not use it, it gave me some bad feeling. Separate between "modern" filesystem methods and encryption scheme. loop-aes uses 65 symmetric keys for encryption which is much stronger than any other available method in Linux/Windows and much like the commercial alternatives. So unless dm-crypt will be able to support a decent encryption scheme it is unusable. > * aespipe? ok,for "on the fly" decryption, but I never had that as a goal. This is required only for conversion to/out none encrypted disk. > * compile static apps? oh, ok, I know many people like their initramfs static, > but I think it is a waste of ram, doubles complexity, wastes cpu cycles, > and like to point out, that even 200MB+ initramfs files work great for me > (build with glibc, sometimes containing even all the /usr/share/doc files > if I was too lazy to strip them down - any initramfs file works great for > me, if the machine has twice as much ram as least. and I find building > huge initramfs with debootstrap soo much easier...) > (but this is personal taste as you can see) You can do whatever you like, the suggestion of static is irrelevant to encryption. You can do whatever you like. > * initrd_util? not sure what it exactly does, but I prefer using the > distributions initramfs tools, only adding a few lines of shell code and > extra files, and not replace the whole initramfs (which I fear this does) > (ah, later the whole content is shown, so this indead seams to have the > goal of "creating a new initramfs" / not modifying the one your distribution > creates/ships. OK. While your distribution probably do not support whatever you like. > * one key per partition looks fine. but 2925 files and then uuencoded and > than encrypted with gpg? strange, and I distrust what I don't understand. > on the other hand I hope the plain openssl rsa key encryption I implemented > in my scripts is secure, only a real crypto expert can tell. As I said: RSA2048(Key256) is weaker than Key256. So it better to store Key256 on smartcard/pgp file. Or... better store 65*Key256 (loop-aes) and have a decent encryption. Again... If you encrypt your disk you do this for a reason. If you just want to show off to other people that you have encrypted disk you can use simple encryption. If you want to *REALLY* be secured, you cannot be satisfied with the simple encryptions even on the price of some complexity. > * how does it support usb smart card readers/token plugged in after boot up? > I don't see udev, hal or hotplug. maybe I miss something? busybox does this? Yes. Alon. _______________________________________________ opensc-devel mailing list [email protected] http://www.opensc-project.org/mailman/listinfo/opensc-devel
