Lexar Secure Jumpdrives

Brian Kelsay Brian.Kelsay at kcc.usda.gov
Tue Dec 14 11:14:49 CST 2004


That, my friend, was an awesome post.  This may sound like a simple thing to you, since you have been dealing with encryption for a while, but have you thought of doing a detailed write-up and sample scripts to get a person new to encryption started?  That would be a cool thing to post to http://www.gnupg.org/(en)/documentation/howtos.html or as a small project on freshmeat.  (e.g.  Encrypted Jumpdrive/Pendrive Howto)
Just a thought.
Yes, the attempt to be cross-platform is usually the wrench in the works.

I have seen some real small USB fobs that I think only carry an encryption key. They are only about a half inch long or just a bit more.  Have you seen those and do they work in Linux?  If they work, they might be just the thing.  I imagine that if you look at them in Linux, you will find that they only contain a fat16 filesystem with 1-8 MB of flash, maybe less.  A private key  takes up how much space if it is in a text file or compressed?  Not much, maybe a few kb.

Brian Kelsay

>>> Jason Clinton <me at jasonclinton.com> 12/14/04 10:55AM >>>

Well, I put all the questions here together because my suggestion encompasses 
all of them. The Lexar encryption hardware is not compatible with Linux; it's 
done in hardware and, IIRC, it's extremely simple (easy to crack) but no 
device driver exists. Rather than worry about having enough size on either 
the encrypted partition or the non-encrypted partition, I suggest that you 
partition and format the whole thing in VFAT32 and place a copy of gnupg on 
the device. There's a number of ways that you can do it but here's one 
scenario that can vary in size and is compatible with Windows unlike the 
loopback file system method:

On your Linux systems, you have a /usr/local/bin/mount script that you 
manually invoke that mounts the /dev/sd? device to /mnt/cf0. It then looks 
for /mnt/cf0/encrypted_archive.tar.gz and executes gnupg with your private 
key from your home directory and decompresses the archive to some place 
in /tmp or /home/~. You have another /usr/local/bin/umount script that 
reverses all of those steps: wrap up the changes in the directory, encrypt 
_against_your_public key_ on the device, unmount. 

On your Windows systems, the exact same process takes place but it's all 
automatic via the autorun.inf file using MING32 compiled gnupg.exe, tar.exe 
and gzip.exe on the device. If you take your device to another person's 
system, you will need to explore some of the many ways that you can securely 
access your private key from remote locations (perhaps even a separate, 8MB 
pen drive to store your private key -- they make watches that do that that 
have USB connectors). That way, if you lose the device, the person would need 
both the private key and the password to access the data.

Regarding the existing software on the device, there's no danger in losing any 
of it unless you want the Windows-only, weak encryption to work with Windows.

This all sounds rather complicated but in practice, good encryption is hard 
work and the cross-platform nature makes it even more complicated. Good 
encryption is not yet a commodity.





More information about the Kclug mailing list