Yes, you can make an encrypted partition and mount it in the usual way. But folks know to look for those. Any partition that looks encrypted is likely to be subjected to a decryption attack.

But if you have a file named “coredump_from_virus_attack” or “Failed_stats_analysis” or even just “What_Is_This”; folks then tend to think that spending days in a crypto attack is a waste of their time as it is just junk. Which is also why naming it “junk_file” or “garbage_collection” also work…

In this example, I’m going to use names that just scream “hack me and attack me with crypto tools”, but this is not what you would do in real life.

I don’t know if these first steps are really needed. Some pages said to do it, but it might be irrelevant if the modules are already in use. Having done it, I can’t really undo it to test until the next boot (or maybe next install?) In any case, these modules need to be available to do the process, so if it fails, check to see if you skipped the load modules part.

Then you make the blob file and the mount point. These can be anywhere in the name space you like. As I had free space in the /Temps file system, I did it there, but you can choose anywhere you like. This can even be on a USB drive or stick that is only plugged in when needed.

Now we’re going to fill the future file system space with junk. Anyone digging around in it will find your encrypted stuff along with a lot of trash. Figuring out which is trash and which is encryption is, er, “hard”. I’ve bolded the “dd” command as it is the working bit. It says to take in random stuff from /dev/urandom and put 102400 blocks of it into the file Crypto_Filesys. By default, these are 512 byte blocks, but you can change that if desired.

Now I have a 52 MB “bag of trash” where I’m going to slip in my filesystem.

We set up a particular loopback device for this. I chose #2 as I usually use 0 and 1 for non-encrypted stuff already. “losetup” sets up that loopback device. We’re using the AES encryption method, but there are others. There are endless arguments about which is best. AES is well vetted, but folks know to look for it. Others are less well known, but also less vetted. Blowfish is supposed to be good too. I used the “./” method of saying “From my working directory right here”, but could just as easily have typed out /Temps/Testing/Crypto_filesys. It asks you for a password. Long and simple is better than short and hard to remember. “4 score and twenty years ago I ate a clam that made me sick!” is better than “%55$RfRTG(&*” and much easier to remember.

Gee… that was easy. Now we make the file system. I’m using an EXT4 type as it is journaled and very safe. You want safe in something that is already complicated and pot-stirred. But any file system type can be used.

At that point, you are basically done. Time to mount it and take it for a test drive. I’ve removed the long prompt from in front of the command so you can see it better. Basically, it is of the form:
mount -o loop,encryption=aes /filesysfile /mountpoint
It asks for your password and you type in your phrase. (Don’t forget it!)

Now the sharp eyed will notice that it is mounted as /dev/loop1 but I used /dev/loop2 in the setup. You can specify a particular loop device to the mount, but I wanted to see what happened if I didn’t, and it worked fine… so that might need a bit more exploring to see what the limits are.

So it looks like a real file system including the “lost+found” directory where a disk check will puts bits of broken files if it has to try repairing the file system and fails.

Let’s edit a file. I’m going to use the “vi” visual editor since my fingers known how to use it without my brain being bothered… I just opened the editor, typed in some text, and exited. Then I used the “cat” command to print out the contents. “This file is full of my secrets.”

root@RaPiM2:/Temps/Testing/MountCrypto# vi MySecrets
root@RaPiM2:/Temps/Testing/MountCrypto# cat MySecrets
This file is full of my secrets.

The “file” command looks at the “magic number” of a file to tell you what is in it. For random stuff, it assumes just data and not any particular format. Here it is saying “just random data”. Named with “_filesys”, we have given a clue to an attacker to “apply decryption here”, but if named “core_dump_VAX_1984”, well… But for now, named with _filesys will remind us not to delete that “junk”… and that we need to mount it as a file system.

“Grep” is “Global Regular Expression Print” and lets you apply all sorts of search test ‘regular expressions’ to searching files. The simplest is just “look for this quoted text” which we used here. It did not find the word “secrets” anywhere in the Crypto_filesys file. Because it is encrypted and looks a lot like the surrounding trash and the encrypted binary inodes, and file structure blocks.

I would advise against just dumping some of the file to look at it. I used “head” that gives you the top 10 lines of the file ( “tail” gives you the last 10. And stop snickering… ) and the binary trash it dumps caused my terminal window to “do very strange things”. Typical for a raw data dump to a screen. This bit stayed on my screen so is likely safe. We’ll see:

All in all, a fairly easy process. Still a few loose ends to polish, like specifying a particular loop device and trying other encryption methods. I’d also like to try some performance and speed tests, but those can wait.

For now, this is “good enough” for daily use. Oh, and do realize that for Mil Spec or NSA proof, you need the entire OS hardened and locked down. They have some fairly exotic tools like things that can read your screen from across the street (don’t know if they still work on LCDs…) and replacement keyboard wires that capture keystrokes. So control of the hardware 100% of the time and a tinfoil lined room are needed… (or at least bronze window screen lined and grounded.) But if you need that level of security, you are in the wrong line of work to be taking advice from a blog. Ask your section chief for a security set up and site sweep…

Enjoy playing with encrypted file systems in a file, and DO remember that if the pass phrase is lost, you are toast. Get konked on the head in a car wreck and forget it? Just do something else for 6 months and forget it? All Gone. So make it easy to remember, or have a ‘keyring’ that can not be found or broken to hold it. “!and” typed 40 times in a row is harder to crack than “@#$faa” so when in doubt, go for a long simple sentence and with one each of number and special char. Things like “I always hated the song 2 for tea!”

11 Responses to A Portable Encrypted Blob Filesystem for Pi

Oh, and while it is sort of obvious, it is worth making explicit that the encrypted blob can be stored on things like “the cloud” without the holder of the blob being able to mine it for information about you and without much usable being ‘shared’ with other agencies.

You can also have a remote NFS or FTP server that holds the blob and ships it to you (perhaps even over a VPN encrypted pipe – so once someone breaks the VPN encryption they get a further encryption challenge in the data stream…) so that it is encrypted ‘end to end’ and only decrypts at the point of filesystem mount on your local machine. In that way you can have all your data stored “somewhere else”. This is a very important part of the “take all my stuff you get nothing” as it is all encrypted, but also an important part of “the next day I am back up” as the data blobs were stored offsite somewhere else… There are a variety of ‘distributed file systems’ that can be used by a cooperating pool of folks, so it doesn’t have to be the Google Cloud… (but distributed file systems are for another day).

There is even a filesystem that lets you mount an ftp:// address as a file system, so you don’t need to ship the whole blob back and forth to do the “mount and decrypt” and use it.

It lets you have a ‘quorum’ of users share an encrypted file set over a network. No one person can decrypt it, so capture one guy, you get his password, you get nothing. Must have a quorum after all… Comes from Italy (which makes me wonder who would need this in Italy …. ;-)

In playijng with this, the ‘losetup’ step does not permanently match that loopback device to that file system, it is just used for the configuring (thus the mount on /dev/loop1). BUT, it does hang around, so you need to do a “losetup -d /dev/loop2” to ‘detach’ it from that file for reuse in other contexts… (like to ‘set up’ the next file / file system).

I’ve made a convenient little script to set one of these up on my “Pink Monster” USB drive. It is normally mounted as /Pink for the FAT32 file system and /Pinkntfs for the NTFS file system (and yes, there is a /Pinkext and a swap partition on it. I’m playing with the different file systems for timing and ‘wear’ on the device). Here’s what it looks like:

It did a nice job of making a 2 GB blob file on each of the USB drive partitions, doing the encryption set up, making the file system inside of them, and releasing the loop device.

Here is what the script looks like. I’ve named it ‘pinkblob’. Note that I’m set up to pass parameters (those things with a $ in them) for the particular real mount point name ($1). The {} let it use a default. So ${1-/Pink} says “use the first parameter I passed, or default to /Pink. That way I can say “pinkblob” to make one in /Pink or I can say “pinkblob /Pinkntfs” to make one in the /Pinkntfs mount point instead.

For you own version, you will want to swap “/Pink” for your mount point default.

It pauses and asks for the password after the ‘losetup -e’ command, then continues on. Execution times on FAT32 vs NTFS were inside 1 second of each other, so not much different. (No journal overhead in the set up…)

At this point I don’t know what happens if you try to boot with these active, so I un-mount and put a “#” in the first character to make it a comment prior to rebooting. “Someday” I’ll find out if it just politely asks for a password or hangs at boot ;-) I expect it to ask… If it hangs, rebooting without the USB in place ought to cause it to be skipped. We’ll see in a few days when the wgets are done and I feel like rebooting…

So at this point making an encrypted blob is one command, and mounting it is one line in the /etc/fstab file. Easy… (Hardest part is just typing the password right each time… ;-)

So it looks like I need a less busy system to get a really clean test. OTOH, on a fairly busy system ( I/O wise) writing 16 MB in under a second ‘real time’ in almost all cases, and that’s just dandy for me. “Someday” I’ll re-run this on an idle system with a GB each and see what shows up. For now, it’s tea time… and maybe look at politics or something non-tech. I’m about at my coming up for air point on encryption…

This note is totally unrelated to the subject discussed, but it may be of some interest to Mr. Smith; a high degree of caution is required.
North Atlantic SST oscillation (the AMO), the strongest natural variability component in the global temperatures, appears to be ‘synchronised’ (with some minor exceptions) by the lunar synodic month, whereby the moon takes 29.531 days to return to the same point on the celestial sphere as referenced to the Sun (solar + lunar tide ?)
‘Synchronisation’ lasted at least 125 years (two AMO cycles) up to around 1995. In the last 20 years relationship appears to break down; alternatively the N. Atlantic SST could be inflated by 0.3C (some other factors at work). However, if the post 1995 temperatures are commensurate to those seen throughout the 1940/50s, then the relationship as observed during previous 125 years would be restored.
I might eventually write a bit more, but it is unlikely that the method used would be considered satisfactory.

Yes, that is of some interest… Looking at the AMO graph, one gets the sense of 3 cycles of 6 years each culminating in an 18.x year lunar pattern, then repeated 3 times for the 54-60 ish year pattern. IIRC, the Southern Annular Mode has a similar “multiples of 3” pattern in the southern wave of about 9? years, something like that… I think I’ll look for some kind of lunar status graph (showing major lunations so things like perigee moon) and see if I can line up any particular state of the lunar cycle with the minor peaks of the AMO (then try to sync the whole thing with when that state returns to over a particular ocean…).

Hi Mr. Smith
Tanks for the reply.
Demonstration (but miles away from a proof) is relatively simple, arrived at it by calculations and found that the critical number is somewhere 29.5 to 29.6 days. Only reasonable forcing in that range that I know of, could be either the high latitude coronal holes or the lunar synodic month; I am inclined to opt for the lunar tide. However, understanding physics behind very simple math’s process borders on the irrational, regardless of what the ultimate driving force may be. I’ve been ‘wrecking’ my brain to understand it for about a year now but I am no closer to it.
Calculation shows millennial cycle (between 970 and 1000 years), while the 60 year periodicity appears only between alternative peaks occurring every 30 years; this would suggest some orbital (angle, nodal point or something else) difference between subsequent synodic months, which I am not aware of.

Postings By Date

Prior Months; postings by date

Meta

To Donate via Paypal or Credit card

Paypal Donation Site.
To make a donation, visit Paypal at the link above and put in the email address pub4all @ aol (DOT) com (leaving out the gratuitous blanks and putting in a "." for (DOT) that is in the text here to defeat spam bots). Many thanks to all!