That second one's really interesting. I've tried the SSH route and while it works (and works well) it really knocks up the time to send an image over the wire.
We've used this for forensic imaging in the past and have relied upon digital signatures as integrity checks. It's not great I know, but it's the best way to get disk images from a big server onto a NAS (when you can't plug the NAS into the server).
The second one is way more fun, using the real device as the plaintext and the loopback as the cyphered version.
Have you tried using the -C (compression) option to ssh instead of the bzip2 pipe? I don't often have occasion to do this sort of thing, so if you've tried that already, it would be interesting to know relative timing. pbzip2 ( compression.ca/pbzip2/ ) might be helpful sometimes, but I don't suspect that it's carried on most live CDs (unless you guys are rolling your own) and the CPU probably isn't the bottleneck anyway.
9P2000 has recently made it into the Linux kernel and it gets way better throughput than NFS, but (and I'm not too familiar with NAS hardware or software, so I may be saying something foolish) I don't suspect it's a supported protocol on those things. Either way, I also don't suspect that adding the overhead of an FS protocol could be helpful in cases where netcat would do, but it's a nice tool to have in the box.
I haven't tried -C on SSH, but I'll make a note to try it next time I get the chance. We use QNAP NAS so we're more or less stuck to specific kernel versions, but the userland is fairly complete (as you have basically got a ton of disk space for userland apps!)
We've used this for forensic imaging in the past and have relied upon digital signatures as integrity checks. It's not great I know, but it's the best way to get disk images from a big server onto a NAS (when you can't plug the NAS into the server).