Re: Filesystem type survives formatting in debian installer?
On Sat, Mar 03, 2007 at 04:04:05PM +0100, David Härdeman wrote:
> >>Which libklibc version does your installed system use?
> >
> >1.4.0-0ubuntu3 at first reboot
> >1.4.0-0ubuntu after apt-get upgrade
> >
> >Is this _down_graded by apt-get? Or does "dpkg -l" cut off its output?
> >
> >Do you think libklibc is causing the problem?
>
> I'm pretty certain that it could, I wrote a number of patches against
> klibc to deal with luks partitions in a proper manner, the most
> important ones appeared in 1.4.9 and some less important ones appeared
> in 1.4.31. One of the fixes was to perform the fs detection in the
> correct order (meaning that leftover signatures would not pose a
> problem).
>
> So, somehow make sure that a newer libklibc is installed to /target
> during the late_command phase, and make sure the initramfs is generated
> using that klibc.
Ah, OK. Thanks!
> >Besides, my further plan is to re-use this old partition as (encrypted)
> >swap space later on. So I will randomize it. But I don't see the need
> >to shred it or something.
>
> But if you make an installation media which is to be used by others, and
> they install a new OS to disk which uses encryption, they will
> reasonably expect that any old data from any previous installations will
> be gone?
Randomizing is OK, but shred would take too long.
> >Finally, you got me. I almost forgot about this one. Unfortunately,
> >/dev/urandom is soooo sloooow. :-(
> >
> >Maybe "dd if=/dev/zero of=/dev/mapper/xxx" (using dmcrypt to "randomize")
> >would be faster. But, OTOH, I bet this method would open some
> >vulnerabilities (known-plaintext attacks).
>
> I don't think it is. If the output from e.g. aes would be
> distinguishable from random data, that would be a strong indication that
> aes was broken. Besides, it is basically the method the installer uses
> so I really hope it is sane :)
I am not a crypto expert. But AFAIK having huge amounts of known plaintext
and its chiphertext makes attacks easier.
Reply to: