I’ve been building infamous hacker Radical Edward’s computer from Cowboy Bebop; fittingly it runs Kali Linux. Named Tomato, it houses a Raspberry Pi 3B, complete with a touchscreen, custom desktop environment, and some decidedly retro hardware. One of the biggest challenges encountered during the build: making a floppy drive relevant in 2027.
Cowboy Bebop released late last century, and despite being set in 2071, features technology from the nineteen-nineties. That may be a bit of deft world-building, suggesting a hard-scrabble post-post-apocalypse where technophiles have to scavenge for their wares. Then again, many people throughout the solar system have consumer-grade spaceships. Whatever the case, Tomato features a floppy disk drive.
This is all well and good in 2071, but 50 years prior 1.44 MEGA bytes will get you ABSOLUTELY NOTHING. To house anything worthwhile, you’d need:
- 🎵 3 floppy disks for a single MP3 song.
- 📸 About 3 floppy disks for one ordinary smartphone photo.
- 📺 Approximately 500 floppy disks to store one 12-minute YouTube video.
- 🚀 Just about 24,000 floppy disks for the entire Cowboy Bebop DVD collection.
- 🎮 About 69,445 floppy disks for one 100 GB AAA video game.
I pride myself on making the seemingly extraneous features of my builds functional. For example, on my Ganymede Rock Lobster Tracking device, the anime’s fictitious knobs are functional nuts (https://www.youtube.com/shorts/-ZJZOp572VA?t=48&utm_source=chatgpt.com). They cinch the two halves of the 3D print together, allowing for tool-less access. Based on the device seen in the Cowboy Bebop episode, Toys in the Attic, my version also features a number pad and jogwheel. As in the anime, both are fully functional and in my build they facilitate navigation of the Raspyjack hacking app. My build also does two types of thermal imaging!
Similarly, I wanted the floppy drive to be more than just a nostalgic prop in my otherwise fully functioning replica. But engineering thermal imaging and app navigation is one thing. Bringing computer hardware back from the dead is quite another. Floppies haven’t seen much use since the 20th century; making a floppy drive relevant in 2027 seemed like actual technomancy. It would take a focused genius many moons to conjure a solution; that or a half-wit with ADD running random simulations in his brain 24/7 for about two days.
I myself came up with a solution right away, in under a day! The floppy disk could function as an encryption key, the “something you have” in a multi-factor authentication scheme. The Kali login password would supply “something you know.” Without the floppy, Tomato shouldn’t be able to complete its normal boot sequence. As it turns out, Linux is perfectly capable of doing this, although getting everything working on an existing Raspberry Pi installation proved considerably more complicated than expected.
🔐 What Is LUKS, and Why Use It?
LUKS stands for Linux Unified Key Setup, the standard disk-encryption format used by many Linux distributions. It works with Linux’s dm-crypt subsystem to provide transparent encryption and decryption of block devices. Once an encrypted filesystem is unlocked, Linux can read and write files normally, encrypting and decrypting the underlying data automatically.
Rather than encrypting the entire filesystem directly with your password, LUKS generates a random volume encryption key. Your password or keyfile is used to unlock a protected copy of that key, which is then used to access the encrypted data. This distinction allows LUKS to support multiple independent unlocking credentials without requiring the entire filesystem to be re-encrypted whenever a password changes.
These credentials are managed through keyslots. In Tomato’s case, I configured two: one containing a conventional recovery passphrase and another using a randomly generated 64-byte keyfile stored on the floppy disk. Either credential can unlock the same encrypted filesystem.
The practical advantage is physical separation. Someone who steals Tomato and its microSD card but doesn’t have the floppy or recovery passphrase shouldn’t be able to decrypt its contents. The floppy itself isn’t a sophisticated hardware security token, however. Its contents can be copied, meaning anyone who obtains the keyfile could potentially use it to unlock the system.
🖥️ The Hardware and Software
The computer is built around a Raspberry Pi 3 Model B with 1 GB of RAM, running 64-bit Kali Linux from a roughly 32 GB microSD card. It uses a USB 3.5-inch floppy drive and a conventional 1.44 MB floppy disk. I performed the encryption and boot-configuration work from a Kali Linux virtual machine running under VMware on my Windows 10 PC.
The relevant Linux tools were cryptsetup, cryptsetup-initramfs, initramfs-tools, and eventually QEMU user-mode emulation. The goal was to preserve Tomato’s existing operating system, desktop customizations, and applications rather than reinstall everything.
That requirement made the project significantly more “interesting.”
🛠️ Encrypting an Existing Raspberry Pi Installation
Ordinarily, the easiest way to encrypt a Linux installation is to configure encryption during installation. Unfortunately, Tomato was already running a customized Kali Linux environment, and I wasn’t interested in rebuilding it from scratch.
Instead, AI and I used cryptsetup reencrypt to convert the existing ext4 root partition into a LUKS2 encrypted volume. Before doing so, we checked the filesystem for errors and reduced its size slightly to accommodate the encryption conversion. This is a potentially destructive operation, and I strongly recommend making a complete image backup before attempting anything similar.
The microSD retained its original two-partition arrangement. The small FAT boot partition remained unencrypted so the Raspberry Pi firmware could load the kernel and initial RAM filesystem. The much larger root partition became a LUKS2 encrypted container holding the original ext4 filesystem.
After the conversion, AI and I unlocked the encrypted partition from Kali and successfully mounted the original filesystem. All of Tomato’s existing files and customizations were still present. The actual encryption worked! Getting the Pi to boot from it was another matter.
🔌 Problems #1: USB Cabling, VMware, and Floppy Drive Madness
The most frustrating aspect of this project had nothing to do with encryption. It was just getting the floppy drives to work. I say floppy drives, plural, because early on I was convinced I’d broken one.
I’d taken a drive apart to paint the housing the same color as the one in the anime. I reassembled it as best I could and attempted to install it. There was a problem, however: the USB cable had a large ferrite choke that I hadn’t accounted for when designing access ports in Tomato’s case. At one point I attempted to deform the PLA with a heatgun to accommodate the cable. Despite masking portions of the print with a makeshift heatsink, I wound up melting parts of the PLA!
From then on I decided to use a series of small adapters and short extension cables to fit through the case’s narrow openings. When I plugged in the daisy chain, the floppy drive’s mechanicals groaned incessantly and its existence failed to register in the OS. Apparently the repeated assemblies had taken their toll on the ancient tech and it was now broken.
I bought a new drive. Several days later and it too failed to register in the OS, right out of the box. There was never a good reason to suspect that a logic-less, short extension of wires would cause a data-transfer failure but being a pessimistic skeptic, I did. Remembering all the ridiculous problems I had with the Ganymede Rock Lobster Tracker wiring (video out soon) I decided to plug the drive directly into the Pi. Inexplicably it worked. I tested other configurations; it seems ANY adapter or cabling between the drive and Pi rendered the hardware completely useless! It took several days of troubleshooting but the good news is that now I had two floppy drives for the price of two! I retested the “broken” drive and found out it wasn’t wrecked, just eccentric.
I was still left with the problem of getting the cabling through the case opening. Turns out the drive’s USB cable had a miniature JST-style connector at its other end. So I routed that end through the opening, plugged it back in, and reassembled the enclosure on the spot.
With the floppy drive finally working when connected directly to the Pi, the next hurdle was getting VMware to cooperate with multiple USB storage devices on my Windows PC. The microSD card reader repeatedly changed Linux device names as devices were connected and disconnected. At different points, the Raspberry Pi’s card appeared as /dev/sdc and /dev/sde. This is particularly dangerous when working with disk-encryption tools, since issuing a destructive command against the wrong block device could wipe an unrelated drive. We therefore identified the correct partition using its size, filesystem type, partition layout, and LUKS UUID rather than trusting its temporary device name.
Passing the floppy drive through to the Kali VM introduced a separate headache. Although the drive worked when connected directly to Windows, it refused to cooperate reliably through VMware. Mount attempts produced filesystem errors, and at one point the device disappeared from Kali’s available block devices entirely. That was distinct from the earlier cabling problem on the Pi, even if the symptoms were frustratingly similar.
Eventually, I decided we’d spent enough time fighting USB hardware. There was a much simpler solution: generate the encryption key in Kali, copy it to an ordinary USB flash drive, and use Windows to transfer it onto the floppy disk. The encryption system doesn’t care where the keyfile was originally created. It only cares about the contents of the file.
🗝️ Creating the Floppy Encryption Key
The keyfile itself is simply 64 bytes of cryptographically random data. We generated it using Linux’s /dev/urandom interface:
umask 077
head -c 64 /dev/urandom > ~/tomato.keyThe umask 077 command restricts access to newly created files, while head -c 64 reads exactly 64 bytes of random data. Unlike a human-generated password, a random 64-byte key is not realistically susceptible to ordinary brute-force guessing.
I then added the keyfile to an available LUKS keyslot:
sudo cryptsetup luksAddKey /dev/sdX2 ~/tomato.keyHere, /dev/sdX2 is a placeholder for the actual encrypted partition. The command prompts for an existing authorized passphrase before adding the new credential.
Afterward, we verified that the keyfile could unlock the volume:
sudo cryptsetup open --test-passphrase \
--key-file ~/tomato.key /dev/sdX2With the key successfully enrolled, we copied tomato.key onto the floppy disk and labeled the disk TOMATOKEY. The label would allow our boot script to find the floppy regardless of whether Linux assigned it /dev/sda, /dev/sdb, or another device name.
🐣🥚 Problem #2: The Chicken-and-Egg Problem of Encrypted Booting
Encrypting the operating system introduces an interesting problem. Linux needs to run cryptsetup to unlock its root filesystem, but the root filesystem contains the operating system and its programs. How can Linux unlock something it hasn’t yet loaded?
The answer is the initramfs, or initial RAM filesystem. This is a small, temporary Linux environment loaded into memory before the actual root filesystem is mounted. It contains the utilities and drivers necessary to locate storage devices, unlock encrypted volumes, and transition into the full operating system.
For Tomato, we needed this early-boot environment to recognize USB storage devices, read the floppy’s FAT12 filesystem, locate tomato.key, and provide its contents to cryptsetup. Once the encrypted root partition was unlocked, the system could proceed with its normal boot sequence.
We configured /etc/crypttab to identify the encrypted partition and use a custom key-reading script. The kernel command line was also updated to point to the decrypted root device:
root=/dev/mapper/cryptrootThe custom script searches for the floppy by its TOMATOKEY volume label, mounts it read-only, and reads the keyfile. It also attempts to provide a recovery-passphrase prompt if the floppy is unavailable, although that fallback still needs additional work.
🐧 Running ARM64 Linux Tools Inside an x86 Kali VM
There was another complication: the Raspberry Pi uses an ARM64 processor, while my Kali virtual machine runs on an x86-64 PC.
To rebuild the Raspberry Pi’s initramfs, we needed to execute programs from its ARM64 installation. We accomplished this using QEMU user-mode emulation and chroot. The chroot utility changes the apparent root directory for a process, allowing us to execute commands using Tomato’s mounted filesystem. QEMU provides the instruction translation necessary to run ARM64 programs on the x86 machine.
First, we installed qemu-user-static and binfmt-support in Kali, allowing the x86 computer to recognize and execute ARM64 binaries through emulation. We then unlocked Tomato’s encrypted microSD partition, mounted its root filesystem at /mnt/radicaleds, and mounted its separate boot partition at /mnt/radicaleds/boot/firmware.
Next, we mounted the necessary Linux virtual filesystems, including /dev, /dev/pts, /proc, /sys, and /run, inside Tomato’s filesystem tree. These provided access to device information, process information, and other resources that programs normally expect to find on a running Linux system.
Finally, we used chroot to enter Tomato’s filesystem and execute its ARM64 programs through QEMU. From inside this environment, we could rebuild the Raspberry Pi’s initramfs using its own installed tools and kernel version:
sudo chroot /mnt/radicaleds /bin/bash -c 'update-initramfs -u -k 6.12.34+rpt-rpi-v8'We then inspected the generated initramfs8 image to verify that it included our custom floppy-unlock script, cryptsetup, the passphrase utility, and the necessary filesystem support.
Everything appeared ready. It wasn’t.
💥 Problem #3: LUKS Wanted More RAM Than the Raspberry Pi Had
The first boot attempt failed. Instead of reaching the desktop, Tomato dropped into an (initramfs) shell. When I attempted to unlock the encrypted partition manually, Linux reported an error involving __vm_enough_memory and insufficient memory for an allocation.
The culprit was Argon2id, the password-based key derivation function configured for our LUKS2 keyslots.
Argon2id is deliberately memory-intensive. This is a security feature intended to make offline password-guessing attacks more expensive. An attacker trying billions of candidate passwords must perform the key derivation operation for each guess, consuming computational resources and memory.
Unfortunately, both of our LUKS keyslots were configured to require 1,048,576 KiB, or 1 GiB of RAM. Tomato’s Raspberry Pi 3B has exactly 1 GB of physical RAM, and some of that memory is already occupied by the kernel and initramfs. In other words, the unlocking process was demanding more memory than the computer could realistically provide.
We discovered this by inspecting the LUKS header:
sudo cryptsetup luksDump /dev/sdX2The solution was to reduce the Argon2id memory requirement for both keyslots to 32 MiB. For the floppy keyslot, we used:
sudo cryptsetup luksConvertKey /dev/sdX2 \
--key-slot 1 \
--key-file ~/tomato.key \
--pbkdf-memory 32768 \
--pbkdf-parallel 1We separately converted the recovery-passphrase keyslot, then verified that both credentials still worked.
This operation didn’t re-encrypt the filesystem or change the actual credentials. It modified the key-derivation parameters associated with the LUKS keyslots.
There is a security tradeoff: reducing Argon2id’s memory requirement also reduces the cost of attempting password guesses. That’s particularly relevant to the recovery passphrase. However, the randomly generated 64-byte floppy key retains enormous entropy regardless of the reduced memory setting.
With the memory issue resolved, it was time for another boot attempt.
🎉 Success! Tomato Boots with a Floppy Disk
This time, Tomato booted successfully.
With the floppy inserted, the Raspberry Pi read tomato.key, unlocked the LUKS2 root partition, and continued into Kali Linux until it reached the login screen. The existing operating system, desktop environment, and custom applications remained intact.
Removing the floppy prevents the machine from completing its normal boot sequence. There is still one unresolved issue: without the disk, the current implementation gets stuck in an I/O retry loop rather than reliably presenting the recovery-passphrase prompt. The recovery credential itself is valid, but the early-boot fallback needs refinement.
Nevertheless, the primary objective is accomplished. Tomato now uses a genuine 3.5-inch floppy disk as a physical encryption credential, and we did it without reinstalling the operating system.
⚡ TL;DR: Use a USB Flash Drive to Unlock Your Encrypted Linux Computer
You don’t need a floppy drive, Raspberry Pi, Kali Linux, VMware, or a second computer to implement the same basic idea. An ordinary USB flash drive can serve as a removable LUKS unlocking key.
These instructions are for a Debian or Ubuntu computer that already has a LUKS-encrypted root filesystem and uses initramfs-tools with cryptsetup-initramfs. Every command below runs directly on the Linux computer you’re securing. No second computer or offline preparation is required.
This tutorial adds USB-key unlocking to an existing encrypted installation. It does not encrypt an unencrypted operating system.
💽 Step 1: Prepare the USB Flash Drive
Insert a USB flash drive into your Linux computer. Using your desktop’s disk-management utility, format it as FAT32 and give it the volume label LUKSKEY. Make sure you select the correct USB device because formatting erases its existing contents.
If the required packages aren’t installed, open a terminal on that same computer and run:
sudo apt update
sudo apt install cryptsetup cryptsetup-initramfs initramfs-tools🔑 Step 2: Generate a Random Encryption Key
Still on the target computer, open a terminal and generate a random 64-byte keyfile:
umask 077
head -c 64 /dev/urandom > ~/luks.keyCopy luks.key to the root directory of the USB flash drive using your file manager. Keep the original file temporarily until you’ve confirmed that USB unlocking works.
🔍 Step 3: Identify Your Encrypted Root Partition
Run:
lsblk -fFind the partition marked crypto_LUKS that contains your root filesystem. It may be something like /dev/nvme0n1p3 or /dev/sda3, but do not assume either name is correct.
For the remaining commands, replace /dev/ENCRYPTED_PARTITION with the actual partition you identified.
🗝️ Step 4: Add the USB Key to LUKS
Enroll your newly generated keyfile:
sudo cryptsetup luksAddKey \
/dev/ENCRYPTED_PARTITION ~/luks.keyEnter your existing LUKS recovery passphrase when prompted. This adds another unlocking credential without removing the original passphrase or re-encrypting the filesystem.
Verify the new keyfile:
sudo cryptsetup open --test-passphrase \
--key-file ~/luks.key \
/dev/ENCRYPTED_PARTITIONIf the command succeeds, your new key is valid.
🧩 Step 5: Create the USB Unlocking Script
On the same Linux computer, create the script directory if necessary:
sudo mkdir -p /etc/cryptsetup/scriptsOpen a text editor:
sudo nano /etc/cryptsetup/scripts/usb-keyPaste the following script:
#!/bin/sh
PATH=/usr/sbin:/usr/bin:/sbin:/bin
mkdir -p /run/luks-usb
i=0
while [ "$i" -lt 10 ]; do
dev=$(blkid -L LUKSKEY 2>/dev/null)
if [ -n "$dev" ] &&
mount -t vfat -o ro "$dev" /run/luks-usb 2>/dev/null; then
if [ -f /run/luks-usb/luks.key ]; then
cat /run/luks-usb/luks.key
umount /run/luks-usb
exit 0
fi
umount /run/luks-usb
fi
i=$((i + 1))
sleep 1
done
exec /usr/lib/cryptsetup/askpass "LUKS recovery passphrase: "Save the file, then make it executable:
sudo chmod 755 /etc/cryptsetup/scripts/usb-keyThe script searches for a USB drive labeled LUKSKEY, mounts it read-only, and reads the keyfile. If it can’t find the drive after approximately ten seconds, it attempts to request the recovery passphrase.
This script is an example rather than a universally verified solution. Its USB detection, initramfs dependencies, and recovery fallback must be tested on your computer.
⚙️ Step 6: Configure LUKS to Use the USB Key
Get the UUID of your encrypted partition:
sudo cryptsetup luksUUID /dev/ENCRYPTED_PARTITIONThen open your existing crypttab configuration:
sudo nano /etc/crypttabFind the entry corresponding to your encrypted root filesystem. Modify that entry to include the keyscript option, preserving any other options your system requires.
For example:
cryptroot UUID=YOUR-LUKS-UUID none luks,initramfs,keyscript=/etc/cryptsetup/scripts/usb-keyReplace YOUR-LUKS-UUID with the UUID from the previous command. Keep the original mapping name if your installation uses something other than cryptroot.
🔄 Step 7: Rebuild the Initramfs
Still on the target Linux computer, rebuild its initramfs images:
sudo update-initramfs -u -k allThis incorporates the updated boot configuration into the early-boot environment used to unlock the encrypted root filesystem.
Check that the current kernel’s initramfs contains the relevant components:
lsinitramfs /boot/initrd.img-$(uname -r) |
grep -E 'usb-key|cryptsetup|askpass'You must also ensure that USB storage, FAT filesystem support, blkid, mount, and the other utilities required by the script are available during early boot. If any are missing, the initramfs configuration needs to be adjusted before testing.
🧪 Step 8: Test Both Unlocking Methods
Before rebooting, make sure you have a working recovery passphrase, a backup of important data, and a securely stored backup of your LUKS header. An incorrect initramfs or crypttab configuration can prevent the computer from booting, even when the encrypted filesystem itself is intact.
Reboot with the USB flash drive inserted and verify that the system unlocks normally. Then test without the USB drive and confirm that you’re prompted for the recovery passphrase.
Do not consider the configuration complete until both unlocking methods work. In particular, the example script’s missing-USB fallback must be verified rather than assumed.
🛡️ Security Considerations
Using removable media as an encryption key provides meaningful protection against someone obtaining the encrypted storage without its unlocking credentials, but it has limitations. A conventional floppy or USB flash drive is not a tamper-resistant authentication device. Anyone who can read the keyfile can copy it, so the removable media must be protected like any other sensitive credential.
It’s also important to understand that removing the floppy or USB drive after the computer has booted doesn’t automatically lock the encrypted filesystem. Once LUKS has unlocked the volume, the operating system continues using the recovered encryption key in memory. Linux can detect the removal of a specific USB device and trigger a response, so I might design a solution that locks the session or suspends access to the encrypted filesystem when the floppy is removed. Suspending an active root filesystem safely, and resuming it afterward, would require additional engineering. Check cyberspacemanmike.com regularly to see if I ever get around to it!
Additionally, the Raspberry Pi’s boot partition remains unencrypted. An attacker with physical access could potentially tamper with the kernel or initramfs to compromise the boot process. LUKS protects data at rest, but it doesn’t automatically provide verified or measured boot integrity.
Finally, maintain secure backups of your recovery credentials and LUKS header. Losing both the removable key and recovery passphrase could mean permanently losing access to the encrypted data.
🌌 See You, Space Cowboy
What began as a simple idea, making a floppy drive useful, turned into an unexpectedly educational exercise in Linux encryption, ARM emulation, early-boot environments, USB compatibility, and memory-hard password derivation. I’ve also learned never to trust anything to do with USB cabling or wiring.
The most surprising discovery was that LUKS2’s Argon2id settings could demand more memory than the Raspberry Pi had available. The most aggravating part was discovering that ordinary USB adapters could stop the floppy drives from working on the Pi, followed by an entirely separate battle with VMware USB passthrough. And the most satisfying moment was watching Tomato finally reach its login screen with the floppy inserted!
Would a USB flash drive be more practical? Absolutely. Would a modern hardware security token offer stronger protection against key copying? Certainly. But neither would have quite the same charm as inserting a floppy disk into a Cowboy Bebop-inspired computer and watching Linux decrypt itself.
Stay tuned to see the culmination of all this Cowboy Bebop themed hardware: a Cowboy Bebop themed IRL CTF named “Satellite D-135!” It is a custom-built, themed cybersecurity CTF combining pentesting, wireless hacking, OSINT, social engineering, AI, custom electronics, and 3D-printed hardware. With over 1,000 hours of development spanning software engineering, electronics, and physical fabrication, it’s my most ambitious project to date!
See you, space cowboy.