Re: Linux distro w/loop-aes

* Max Vozeler <[email protected]> wrote:

> > I'm a slackware user (as indirectly mentioned before) so I work
> > on the slackware installer.
> 
> Hey, cool that you're working on this for slackware. :-)

slackware won't include loop-aes and therefore the project will be
just an add-on for slackware.

Because of that I will only include a non-SMP kernel (I don't have
the hardware for SMP testing) and only the i686 build. i486 with
loop-aes doesn't make sense.

One has to fiddle with loop-aes & kernel anyway.


> > Well, I've got it working (proof-of-concept), but the setup is
> > somewhat messy... Long story short, One has to know what one is
> > doing, most likely there won't be the infamous
> > Point'n'Click-interface due to the nature of a typical slackware
> > install. But I have some ideas of making life more comfortable in
> > this regard.... will put up a draft / roadmap when I'm confident
> > about beta testers.
> 
> Just a thought: Reading your mail I went through the issues I 
> came across doing similar for debian-installer -- and came to think
> that some of those issues probably affect all installers independent 
> of the distribution to be installed. For example, the small amount
> of entropy gathered up to the point of key generation. 

I agree.


> I think it could be interesting to share some ideas and maybe code 
> in this area. Like, to overcome the small amount of entropy, in Debian
> the user is presented with a text entry box and asked to type random
> characters into it - A progress bar shows how much mindless typing
> remains ;-) This is not exactly great, and I would be interested in
> discussing other approaches to the problem.

most likely it's going to be a simplistic setup only, nothing fancy.
Just that it works and people can adapt it to their needs easily.


> E.g. we could try to take advantage of hardware RNGs - but how to 
> detect them? hw_random used to autoload and provide a /dev/hwrandom
> (IIRC) on this system here but blocked reads forever as the chipset
> doesn't really have an RNG. Another idea was to just trigger any disk
> IO and hope that the IDE/SCSI driver contributes entropy this way.
> Or perhaps using audio/video-entropyd  - but are they reliable enough
> on their own or should their output be fed through something like 
> rngd to be safe? Or should we just use /dev/urandom? 

There are some approaches to this (found some sites about the topic),
but I tend to stick to gpg --gen-random for now. gpg is already
needed so why not make use of it ;-)

It's using an implementation of "Software Generation of Practically Strong
Random Numbers" by Peter Gutman, which is ok for me
http://www.cs.auckland.ac.nz/~pgut001/pubs/random.pdf

He published a followup-paper on the subject, but I doubt gnupg is
going to tinker with that.


> Regarding the implementation, large parts of our code are specific
> to the Debian partitioning tool (partman) and the debconf interface 
> used in the installer, but maybe some bits are also applicable or 
> interesting for your slackware implementation, maybe blockdev-wipe
> which is like dd if=/dev/zero with progress output. You can find most
> of this code at [1] and there is some discussion at [2] and also
> spread in the debian-boot list archives.

the slackware installer is spartanic, if the disk is not partitioned
one will get a nice message about fdisk ;-) 

However, I've stopped work on the latest official release installer
because that was made for 2.4 kernels (which gave me troubles here
and there.... had to use chroot et al. --- messy) and it looks like
(finally!) the next release will feature a 2.6 kernel, and maybe a
recent busybox for the installer.

I have some ideas concerning the boot setup (create boot CD/USB stick
 on-the-fly, adapt initrd, patch linuxrc instead of compiling
freshly) and try to get that framework running in the meantime.

-- 
left blank, right bald

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFGPvUfLMyTO8Kj/uQRAgW9AKCMbI1ZsqvvUALpq7Xad9X4FBsxVQCfbD3O
vQR2EijQY5JNddYNYMwMq0k=
=HLbV
-----END PGP SIGNATURE-----