[Pkg-cryptsetup-devel] Bug#379771: cryptsetup: encrypted swap does not work on existing swap partition

[Raphaël Quinet]

Package: cryptsetup
Version: 2:1.0.3-3
Severity: normal

Contrary to the instructions given in /usr/share/doc/cryptsetup/CryptoSwap.HowTo
it is not possible to activate the encryption for an existing swap partition.

The init script detects a valid swap signature on the original partition (not
encrypted) and refuses to overwrite it with the encrypted swap.  So the
instructions given in CryptoSwap.HowTo are incorrect.

I have been using an encrypted swap partition on my "testing" systems since a
while.  I am glad that bugs #371135, #371160 and #377434 have been fixed so
that encrypted swap partitions with random keys are working again.  However,
some of my systems dual-boot with other Linux configurations in which the same
partition is used as a standard swap (no encryption).  Switching between these
configurations prevents the encrypted swap from working as it did before,
because the valid swap signature created by the other configurations prevents
the encrypted device from working.

Proposed solutions:
1) Allow the creation of the encrypted swap partition even if a valid swap
   signature exists on the target partition.  Destroying a valid swap
   partition is much less dangerous than destroying another filesystem.
   The only concern might be for people using suspend on swap and doing
   something stupid in their crypttab configuration, but this is a minor
   issue.
2) If the first solution is not possible or not desirable for whatever
   reasons, at least update CryptoSwap.HowTo and suggest destroying the
   swap partition by hand before using it in crypttab, or disabling the
   test (check=/bin/true) as had been suggested in another bug report.
   For example, CryptSetup.HowTo could say:
     Before starting your crypted device, erase its contents with:
     dd if=/dev/urandom of=/dev/hda9 bs=1024 count=<whatever>
   It is a bit strange to suggest to destroy things by hand just because
   an overzealous test in the init script tries hard to prevent people
   from making mistakes.  But if the other solution is rejected, then at
   least this would fix the documentation.

-Raphaël