I haven't - Intel HSFs are a real pain to get on and off. I don't suppose my kernel could be somehow "attached" to my old CPU (it was compiled with P4 processor family)?

That's a good point -- more than the general kernel optimization (which you should indeed change), are you using optimized encryption modules? Those are dependent on 32- and 64-bit.

So right now you are using a rescue CD? These changes should be easy to implement; also, you can change the rest of your system easily using chroot (as in the installation handbook).

Good luck!

My encryption modules are the default ones (which I assumed were devoid of processor-specific optimisations), and I'm using serpent for the actual disk encryption.
I'm currently posting from another computer - I did indeed try the rescue CD, however I did not include the serpent module so I was unable to decrypt and chroot. I'm guessing perhaps the full LiveCD may be of more help here, but I am unsure as to which architecture I should download - must I use x86 as that's what my existing system is, or will amd64 work, allowing forwards compatibility?

SysRescueCD may work for you better -- it has the kitchen sink in it, including dm-crypt.

As for which CD architecture to use, your 64-bit machine should boot a 32-bit CD. Then if you want to modify your software to try to get it to boot off of hard disk, you won't have to worry about any environment incompatibilities.

(In your situation, I would just do a fresh install since I would want to move my system from 32-bit to 64-bit anyway. "emerge -e world" doesn't work in this situation. Then, copy over my personal data from my physically secured, unencrypted backups ..)_________________Personal overlay | Simple backup scheme

Unrelated, If I had a partition which was encrypted which held a keyfile, could I use that keyfile to encrypt multiple partitions (i.e. for LVM)?

I don't see any reason why not, but again this isn't really where you should use luks.

luks stores the actually key used to en/decrypt the data is store in the luks header on the partition (it's encrypted and safer than it sounds), however it makes luks unsuitable for cases where you want to use your own key data or wnat more automation or flexibility._________________"You have to invite me in"

Things were pretty rocky from the get-go, since the system I'm using doesn't actually boot off of USB, and I've been using a CD with grub on it to bootstrap the system. Also, I had to rig up something with stty to get the passphrase for my keyfile into gpg, because my initramfs doesn't have /dev/tty (any suggestions as to that would be welcome).

My real problem, however, is that LVM will simply not recognize my volume group. I can unlock the drive, but running lvm vgscan tells me I have no logical volumes. I copied over lvm.conf from the liveCD, and don't really know where else to go from here (I have an encrypted gentoo system on another box, but not using LVM). Any suggestions?

it is possible (don't know about genkernel, but you can do everything with custom initramfs), but why not just use the same password for everything? the same security (e.g. you break the password, you can decrypt everything), but no need for custom initramfs.