As many of You already know, to get highest security level possible (i.e. when You want to protect your data against serious cracking attempts, not only ensuring that random thief wouldn't have access to your photos and contacts), one should encrypt swap. While it's rather trivial, it decreases swap performance - not by high amount, but always.

For people, that -like me - are concerned about max performance, yet would also like to have safe way to carry ''top-secret'' files on Your device (and work on them), I'm currently preparing a experimental solution. Concept look like this:

Legend (don't get used to names, they're only plain templates for easier understanding ):

/dev/truecrypt - our example encrypted partition.
/dev/cryptoswap - swap partition, that would get encrypted with masterpassword from '/dev/urandom' every time it's enabled (of course, every time using different password from, urandom, it isn't cached anywhere)
/dev/plainswap - regular swap partition
/.top-secret/area-51-plans.odf - a file stored in /dev/truecrypt, that is highly confidential and we wan't to be sure that it wouldn't leak in any case.

(optional):
/dev/lowcrypt - encrypted swap partition, that contain private files, which aren't of such priority (or interest to possible adversaries), which would require top-secret level of safety. Also, user would like to have it mounted "all the time" (from device bootup, to shutdown, for example, via automount script)

---

Normally, device uses a /dev/plainswap as enabled swap, and /dev/lowcrypt mounted ''all the time''. When user want to take a look on/modify area-51-plans.pdf, she/he enables /dev/cryptoswap as swap, disables swap on /dev/plainswap, mount /dev/truecrypt, and start having fun with area-51-plans.odf. After work/fun is finished, user unmount /dev/truecrypt, enables [b/]/dev/plainswap[/b] (which, on moment of enabling, have lower priority that still working /dev/cryptoswap), and disables /dev/cryptoswap.

Rationale (+ EUE, aka Easily Understandable Explanation):

For normal operation, we're using regular swap without any cryptographic slowdowns. Things that we have on /dev/lowcrypt are generally safe in case of thievery (if we use short timeout for lock code), as thief doesn't have password needed to mount it after reboot/reflash/whatever. Yet, things from /dev/lowcrypt can get into memory and swapped in swap partition. If someone would leave swap in "frozen" state (i.e. would not use it after thievery), and analyze swap partition using software designed to pull data from swaps, he would be able to get our private data/parts of it from swap. Trying to overwrite it in any way is utterly useless, due to wear-leveling on both eMMC and SD cards, and overwriting whole swap partition with zeros isn't too wear&tear-precautions friendly, anyway (let alone fact, that hardware wear-leveling on SD card ignore partitions layout, and throw chunks of data written into one logical partition, into whole hardware surface of card).

Generally, it's acceptable, as we don't expect someone to steal our device, just to suck swap for photos of our wife in bikini - still, we would (well, most of us) not like to see photos of our wife sold to porn site by some plain, lame thief (neither our wifes would like to), so TrueCrypt encryption of /dev/lowcrypt suits our needs, without requiring encrypting swap.

Yet, we have been recently contacted by UFO, which gave us plans of area-51, of course written as Open Document Format (area51-plans.odf). We are sympathetic towards Little Green Folks, and we're smart enough to know, that Mens in Black may be on our back soon. So, we use our top-secret /dev/truecrypt partition (that we *never* automount, always mounting it manually when needed, and unmount just after finishing messing on it) to store area51-plans.odf there. We don't want tracker to look there ever, so we've put it like /.top-secret/area51-plans.odf (tracker ignores folders with names starting as '.' - dot).

Then, every time we need to check something on our area51-plans.odf - whie preparing World Wide Conspiracy - we enable /dev/cryptoswap (encrypting it with password from /dev/urandom at the moment of enabling, it shouldn't take more than few seconds), disable /dev/plainswap, and mount or /dev/truecrypt, providing password. Then, we can safely look at our area51-plans.odf, without risk that it gets swapped out to unencrypted swap - it just land on encrypted swap, so adversaries gain nothing. Then, after finishing work, we unmount /dev/truecrypt, mount /dev/plainswap (no risk of swap transferring something there from /dev/cryptoswap, as plainswap gots lower priority initially), and disable /dev/plainswap (which, after this, is only one swap active, thus gaining highest priority).

That's the concept.
---

Of course, if someone want - let's say - open area51-plain.odf in LibreOffice, she/he need to ensure, that all LibreOffice caching etc also lands on encrypted partition (no matter on which one, as during work, we're using only encrypted swap, so no risk of swapping to plainswap - but, for paranoia security level, we can use /dev/truecrypt for this purpose, as our /dev/lowcrypt is mounted all the time, thus posing more risk of falling into adversary's hands mounted = decrypted), etc.

Also, to make it more convenient, I'm planning to prepare two scripts - lets name them for now [i]top-secret-start.sh and top-secret-stop.sh. First one would automatically do all work needed *before* we can access our /dev/truecrypt partition - enabling encrypted swap, disabling plain one, and at last, mounting /dev/truecrypt, thus opening TrueCrypt dialog, asking us for password. The latter would be executed after we finished our job on top secret encrypted partition - it would unmount /dev/truecrypt, enable plain swap, and disable encrypted swap.

Of course, those two script would require customization from user side - entering actual encrypted partition's and swap's location (instead of our funny /dev/truecrypt, /dev/cryptoswap and so goes on). Maybe in future, I would prepare a single, separate GUI for assisting in such one-time configuration, and release it as separate package.
---

This concept was created entirely in my head - it isn't based on any existing solution, that I'm aware of. So, people knowledgeable about encryption, TrueCrypt etc - if You see any rationale, why such approach would be insecure, please write here. I said - it is experimental, and if you find yourself in mood of trying it - before or after I release something related (because everyone can prepare something like that even now, based on my description) - don't blame me, if it turns out posing security threat. Yet, as for my current knowledge, it shouldn't.

/Estel