A mildly annoying 32bit adventure, also happy 30th PGP!

It’s been 30 years since the initial launch of PGP! Hard to believe what a firestorm it ignited i the 1990’s and the real pity of how the crypto field is just as baffling and confusing to people today as it was back then.

It’s crazy how crypto went from being an obtuse tool, to suddenly being in the hands of normal people with a public web of trust, and widely available source. And of course it was that widely available source that led to the first real people of trying to geofence on the internet, and it was naturally impossible to contain, even in the era before VPN’s people were able to circumvent any and all “protections” and download away. Strong cryptography went from being something considered ‘weapons grade’ and thusly requiring a munitions license to produce and distribute to suddenly being available to the world at large.

Investigations were launched, agencies contacted, and in spite of it all people had signing parities to exchange public keys, and sign the trust building the web. Try as some people may have demanded ‘back door access’ or black box crypto chips, the cat was out of the bag, and all you needed was a C compiler and a zip file small enough to easily fit on a low density 5 1/4″ diskette. It is 1991 after all, and there is still a sizable amount of XT/AT class machines out there, along with the 68000 Amiga/Atari/Macintosh (upgraded QL’s? 128kb really isn’t enough).

PGP 1.0 is from another era, originally written in the late 80’s cleaned up and released in 1991 where mass produced 64bit machines were still a bit off, and thusly PGP 1.0 really supports 16bit & 32bit OS’s. For the purpose of this ‘revival’ I went with the Unix port, the aptly named unix_pgp10.tar.gz. And from the MS-DOS version I extracted the test data to make sure it works in the file pgp10-test-data.tar.gz

$ file pgp
 pgp: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=cd9ecbf51fab24abbb7153a2cc04bb01bbf2ae91, not stripped
$ ./pgp testfile.ctx
 Pretty Good Privacy 1.0 - RSA public key cryptography for the masses.
 (c) Copyright 1990 Philip Zimmermann, Phil's Pretty Good Software.  5 Jun 91
 File is encrypted.  Secret key is required to read it.
 Key for user ID: Bond, James (007)
 288-bit key, Key ID A27A1F, created Sat Oct 19 23:56:24 3006391
 You need a pass phrase to unlock your RSA secret key.
 Enter pass phrase:

While it was simple enough to build, sadly on x64 WSL instance it doesn’t work. There is no pass phrase for the test data.

Normally I have one of usual two choices a) try to fix PGP to be 64bit friendly or b) run it under a 32bit environment. Normally I would do b, but I went digging into some porting strategies for the a choice and ran into this totally underused tech x32.

Long story short you keep your 32bit integers, you run like it’s a 32bit process but you are mapped into a 64bit address space. Even better -static works!

On Debian 10 the environment can be installed with the following:

apt-get install gcc-7 lib32gcc-7-dev libgcc-7-dev libx32gcc-7-dev gcc-7-multilib

Then to invoke it, use gcc-7 -mx32 . It’s that easy.

WSLv1 vs WSLv2

$ ./pgp
 -bash: ./pgp: cannot execute binary file: Exec format error
$ file pgp
 pgp: ELF 32-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, BuildID[sha1]=2aa5f030603018ca1dc6c5c10aa979751b006aca, for GNU/Linux 3.4.0, not stripped

Notice it is now a 32-bit LSB executable, but also in the x86-64 address space! However under the WSLv1 environment it won’t work. Time to update to v2

   wsl --set-version Ubuntu-20.04 2
   Conversion in progress, this may take a few minutes…
   For information on key differences with WSL 2 please visit https://aka.ms/wsl2
   WSL 2 requires an update to its kernel component. For information please visit https://aka.ms/wsl2kernel 

And now with the instance converted:

$ ./pgp
 Pretty Good Privacy 1.0 - RSA public key cryptography for the masses.
 (c) Copyright 1990 Philip Zimmermann, Phil's Pretty Good Software.  5 Jun 91
 For details on free licensing and distribution, see the PGP User's Guide.
 For other cryptography products and custom development services, contact:
 Philip Zimmermann, 3021 11th St, Boulder CO 80304 USA, phone (303)444-4541
 Usage summary:
 To encrypt a plaintext file with recipent's public key, type:
    pgp -e textfile her_userid      (produces textfile.ctx)
 To sign a plaintext file with your secret key, type:
    pgp -s textfile your_userid     (produces textfile.ctx)
 To sign a plaintext file with your secret key, and then encrypt it
    with recipent's public key, producing a .ctx file:
    pgp -es textfile her_userid your_userid
 To encrypt with conventional encryption only:  pgp -c textfile
 To decrypt or check a signature for a ciphertext (.ctx) file:
    pgp ciphertextfile [plaintextfile]
 To generate your own unique public/secret key pair, type:  pgp -k
 To add a public or secret key file's contents to your public
    or secret key ring:   pgp -a keyfile [keyring]
 To remove a key from your public key ring:     pgp -r userid [keyring]
 To view the contents of your public key ring:  pgp -v [userid] [keyring]

And we are in business! Now we can run the example crypto test:

$ ./pgp testfile.ctx
 Pretty Good Privacy 1.0 - RSA public key cryptography for the masses.
 (c) Copyright 1990 Philip Zimmermann, Phil's Pretty Good Software.  5 Jun 91
 File is encrypted.  Secret key is required to read it.
 Key for user ID: Bond, James (007)
 286-bit key, Key ID A27A1F, created (null)
 Advisory warning: This RSA secret key is not protected by a passphrase.
 Just a moment-- .
 File has signature.  Public key is required to check signature. .
 Good signature from user "Smart, Maxwell (86)".
 Signature made Thu Jun  6 05:28:52 1991
 Plaintext filename: testfile

And there we are!

PGP 1.0 suffers from 2 real defects of the era the first being the home brew bassomatic that is apparently full of all kinds of flaws, and the second lurking in rsalib.c

 The RSA public key cryptosystem is patented by the Massachusetts Institute of Technology (U.S. patent #4,405,829).  Public Key  Partners (PKP) holds the exclusive commercial license to sell and  sub-license the RSA public key cryptosystem.  The author of this  software implementation of the RSA algorithm is providing this  implementation for educational use only.  Licensing this algorithm  from PKP is the responsibility of you, the user, not Philip Zimmermann, the author of this implementation.  The author assumes no liability for any breach of patent law resulting from the unlicensed use of this software by the user. These routines implement all of the multiprecision arithmetic necessary for Rivest-Shamir-Adleman (RSA) public key cryptography.

And it ignited so much of a war about licensing the RSA cryptography base. It wasn’t until 1992/1993 that the RSA released their own aptly named rsaref that at least clarified and addressed their licensing restrictions. As we found out later it wasn’t the DOJ shutting down encryption, nor wild acts of congress instead it was US Patent 4,405,829 which finally expired in Sept 21, 2000, along with US patent 4,200,770 Hellman Diffie Merkle, public-key cryptography which expired in September of 1997. So in the end it was the lawyers who were to be feared, not the the US Government.

Another source of annoyance was the public/private key files are stored in a binary format (hence the 16/32/64 issues I’m sure!).

C:\temp>pgp -v jason.pub
 Pretty Good Privacy 1.0 - RSA public key cryptography for the masses.
 (c) Copyright 1990 Philip Zimmermann, Phil's Pretty Good Software.  5 Jun 91
 Key ring: 'jason.pub'
 Type bits/keyID   Date     User ID
 pub  990/F7CAD5 12-Jun-21  Jason Stevens
 1 key(s) examined.
 C:\temp>type jason.pub
 °ü½╟╓iº½t↕Hï╜Æ(↑ªα&E☼lKL$*⌠=└¥╒[╫ès,╔kår~▐MFBv≥≡╫E┴╟Tÿ║µó ╨6,♣◄Ermo▼æ▄;± ùî

So naturally you have to use uuencode which led to MIME collisions and other fun stuff down the road. yay!

begin 666 jason.pub
MF9,`$!C$8`U*87-O;B!3=&[email protected]/5RO>TFV)[email protected]%49RW3NYGD<8*H`3X1

Even though today we have widespread SSL, and all kinds of apps that encrypt by default, but Operation Trojan Shield shows that that an app is simply not enough, and you cannot trust anything.

Though Enigma had some cryptographic weaknesses, in practice it was German procedural flaws, operator mistakes, failure to systematically introduce changes in encipherment procedures, and Allied capture of key tables and hardware that, during the war, enabled Allied cryptologists to succeed and “turned the tide” in the Allies’ favour.[15][16]


And just like the spy movies good crypto is tedious, bulky and rarely used properly*.

Yes please don’t seriously rely on pgp 1.0!

Microsoft to delete legacy updates in the great SHA-1 purge

Get ready to see this quite often.

From the article here, on August 3rd, (aka yesterday) the purge will be complete. Instead of introducing an update to verify SHA-2 into legacy systems, and re-signing old updates, instead MS has taken the path of obsolesce and pulled the downloads instead.

And we’ve been here before.

Microsoft movie maker was a popular download for Windows XP, and MS removed the download, as hosting it was apparently encouraging people to keep on using XP. Naturally this wasn’t taken as a message that people wanted this kind of product, and why fill a void when you can remove a product? So now the majority of downloads that you will find are infected, corrupted and just going to cause further problems.

And here we go again.

Office 2003 SP1 is no more

A quick search on BING for MS Office 2003 updates still shows links, but they are simply no more. The purge is in full force, and search pages haven’t caught up. And as you can see cnet is already in the top downloads, and will become the authoritative download by fiat.

Also the early .NET’s deployment packages are no longer for download, while .NET 1.1 SP1 is still online surprisingly. For reference:

$ shasum -a 512256 NDP1.1sp1-KB867460-X86.exe 
7b44095feff471dee9366a2153dfe2654d70754c21b7e5204ed950cdf4a3f15a  NDP1.1sp1-KB867460-X86.exe

For what it’s worth.

Calculating with shasum offers a few algorighims as this isn’t a simple one shot deal.

-a, --algorithm   1 (default), 224, 256, 384, 512, 512224, 512256

Naturally to add further confusion. Like everything with crypto, it’s so easy to mess it up.

$ shasum -a 1 NDP1.1sp1-KB867460-X86.exe 
74a5b25d65a70b8ecd6a9c301a0aea10d8483a23  NDP1.1sp1-KB867460-X86.exe
$ shasum -a 224 NDP1.1sp1-KB867460-X86.exe 
18507f80722780ca477d7f10528ae28dd176f8d36cbce05a50cc7be0  NDP1.1sp1-KB867460-X86.exe
$ shasum -a 256 NDP1.1sp1-KB867460-X86.exe 
2c0a35409ff0873cfa28b70b8224e9aca2362241c1f0ed6f622fef8d4722fd9a  NDP1.1sp1-KB867460-X86.exe
$ shasum -a 384 NDP1.1sp1-KB867460-X86.exe 
c2372c71f93b5dc2a1c21c804bc74e27d82bfa45ee50fbc9037e713c156f1c591ffbe5e87f94022157906098916403b4  NDP1.1sp1-KB867460-X86.exe
$ shasum -a 512 NDP1.1sp1-KB867460-X86.exe 
bbe643f447f49636732b12d23a052d02681ad41f6920dc1038b073fa600f7589b378ed8e7de97e811543d93ae89ce52871a85ee58aa3b6aeaddc01bc1617ad85  NDP1.1sp1-KB867460-X86.exe
$ shasum -a 512224 NDP1.1sp1-KB867460-X86.exe 
63b2ffb0c5f1cd68abafba23997482b2087d486dcf60bec6fef7446d  NDP1.1sp1-KB867460-X86.exe
$ shasum -a 512256 NDP1.1sp1-KB867460-X86.exe 
7b44095feff471dee9366a2153dfe2654d70754c21b7e5204ed950cdf4a3f15a  NDP1.1sp1-KB867460-X86.exe

Oddly enough a quick search for these checksums isn’t coming up with anything so I guess I’m first. Which of course is a further problem, is that there is no authoritative source from MS. I get the contract obsolescence thing, after-all the strongest competition to NEW MS products is OLD MS products. I still use Excel 3 & MS Word 2, despite having an Office 365 subscription, and various newer versions retail.

The sad thing is that many people will get screwed over from this action, and the only “solution” is of course move to Windows 10, embrace the new, and hope that you don’t have applications that actually require .NET 1.1 (or 1.0!).

Fun with Docker

Well it’s not really all that fun.

SO… in the start of the year I had decided I didn’t want to play site admin all day, and went to a hosted platform.  Things went well for a few months, then things didnt go well with constant database issues.

Then we went down hard for over 24 hours.  I was going to move back, but then everything started to work again.  But things had been spiraling down to unusability again.

So instead of just making a big VM like I had done before , I thought I’d try using Docker to host my website, with a few containers, namely each tier separate.

And oh boy does everyone love edge case docker stuff, but when it comes to actually moving something *INTO* docker, its basically you are on your own.

So yes, the http-https redirect is brokenMy categories are all missing. lots of stuff is busted.  And the supergloblamegacorp.com redirect stuff is missing. I’ll have to re-create that one after I get more stuff sorted out.

I haven’t given up yet…

Half of the fun was setting up the haproxy container, which in itself wasn’t so bad, although some times it wouldn’t pick up any config file changes, so I had to destroy it a few times, but naturally once I ask someone to look, and it’s working fine now.

So for the hell of it, here is my haproxy.cfg

maxconn 256
mode http
timeout connect 5000ms
timeout client 50000ms
timeout server 50000ms

frontend http-in
bind *:80
bind *:443 ssl crt /etc/haproxy/haproxy.pem
http-request set-header Host virtuallyfun.com if { hdr(host) -i virtuallyfun.superglobalmegacorp.com }
http-request set-header Host virtuallyfun.com if { hdr(host) -i superglobalmegacorp.com }
redirect scheme https code 301 if !{ ssl_fc }
mode http
acl host_virtuallyfun hdr(host) -i virtuallyfun.com
acl host_virtuallyfun hdr(host) -i virtuallyfun.superglobalmegacorp.com
acl host_virtuallyfun hdr(host) -i superglobalmegacorp.com
use_backend virtuallyfun if host_virtuallyfun

backend virtuallyfun
balance leastconn
option httpclose
option forwardfor
reqadd X-Forwarded-Proto:\ https
server node1

I wanted to use Let’s Encrypt to ‘secure’ access to the domains I have, and running the certbot manually…. in a ‘dry run’ I always got this fun and informative error:

NewIdentifier : ACMESharp.AcmeClient+AcmeWebException: Unexpected error
+Response from server:
+ Code: BadRequest
+ Content: {
“type”: “urn:acme:error:malformed”,
“detail”: “Error creating new authz :: DNS name does not have enough labels”,
“status”: 400

Which of course got me absolutely nowhere searching.  I thought it may be docker screwing things up, so I shut it down, and fire up an old fashioned standalone copy of Apache, and run the following:

certbot certonly –dry-run –non-interactive –register-unsafely-without-email –agree-tos –expand –webroot –webroot-path /docker/wordpress/html –domain virtuallyfun.com –domain virtuallyfun.superglobalmegacorp.com –domain superglobalmegacorp.com

And get the same result.

I get to the point of absolute frustration, and just decide to forget the dry run all together, as I know I can run it at least 5 times a day before I get banned, for a while, but maybe I’ll get something more useful.

# certbot certonly –non-interactive –register-unsafely-without-email –agree-tos –expand –webroot –webroot-path /var/www/html –domain virtuallyfun.com –domain virtuallyfun.superglobalmegacorp.com –domain superglobalmegacorp.com
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for virtuallyfun.com
http-01 challenge for virtuallyfun.superglobalmegacorp.com
http-01 challenge for superglobalmegacorp.com
Using the webroot path /var/www/html for all unmatched domains.
Waiting for verification…
Cleaning up challenges
Generating key (2048 bits): /etc/letsencrypt/keys/0000_key-certbot.pem
Creating CSR: /etc/letsencrypt/csr/0000_csr-certbot.pem

– Congratulations! Your certificate and chain have been saved at
/etc/letsencrypt/live/virtuallyfun.com/fullchain.pem. Your cert
will expire on 2018-06-26. To obtain a new or tweaked version of
this certificate in the future, simply run certbot again. To
non-interactively renew *all* of your certificates, run “certbot
– If you like Certbot, please consider supporting our work by:

Donating to ISRG / Let’s Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le

Except it actually worked.

Creating the needed haproxy.pem is simple as:

cd /etc/letsencrypt/live/virtuallyfun.com/
cat fullchain.pem privkey.pem > /docker/haproxy.pem

To put the needed key along with the certs.  Naturally when this expires I’ll have to scramble to figure out how I did this.

Managing docker is fun as well. I went ahead and tried out portainer.io, which  naturally deploys as a container.  And it can manage remote servers, which I though was a plus as that means I could deploy it in my office, then simply connect to my server.  But that is where I found out that the config files for Debian are hard coded to always listen on a local socket, which breaks setting the proper JSON file to tell it to listen on a socket, and TCP/IP.  So just edit /etc/systemd/system/docker.service.d/docker.conf and either hard code it all there, or remove it from there and place it in /etc/docker/daemon.json

As always documentation is conflicting and all over the place.

My current feelings about docker…

More thoughts on Minecraft, compression and encryption

So earlier, I had touched on Minecraft, and lamented on how it doesn’t compress it’s network data very well.  Well it turns out that yes, in the server.properties file, there is an option network-compression-threshold, which by default is set to 256, meaning packets larger than 256bytes are compressed


So using this quick stunnel guide, I thought I’d try a quick experiment.  So I loaded up Titan City, and ran some connection experiments:

First, the Minecraft server with a setting of 256000000 which I would imagine effectively turns off compression.  I’m capturing one minutes worth of game play as it tries to render the spawn point.  Then again with the threshold set to 256:

12M 28 Apr 13:44 minecraft-nocompression.cap
1.6M 28 Apr 13:46 minecraft-256compression.cap

So, uncompressed it’s 12MB worth of data!  While with the Minecraft compression on, it’s 1.6 MB worth of data.

And now with stunnel using zlib compression, we get the following results:

2.1M 28 Apr 13:42 stunnel-nocompressioninserver.cap
1.5M 28 Apr 13:48 stunnel-256compression.cap

2.1MB worth of traffic relying on zlib in this case to do all the compression, and 1.5MB with zlib compressing the Minecraft compression.  And for the heck of it, why not compress the data again?
964K 28 Apr 13:46 minecraft-256compression.cap.gz
993K 28 Apr 13:44 minecraft-nocompression.cap.gz
938K 28 Apr 13:48 stunnel-256compression.cap.gz
1.5M 28 Apr 13:42 stunnel-nocompressioninserver.cap.gz

Well, now that is strange, why is the stunnel traffic even compressible, after it’s been encrypted?  Kind of weird to me.  At any rate, here is some more data thanks to the capinfos program:
# capinfos *cap
File name: minecraft-nocompression.cap
File type: Wireshark/tcpdump/… – pcap
File encapsulation: Ethernet
Packet size limit: file hdr: 1520 bytes
Number of packets: 14 k
File size: 12 MB
Data size: 12 MB
Capture duration: 59 seconds
Start time: Tue Apr 28 13:43:30 2015
End time: Tue Apr 28 13:44:29 2015
Data byte rate: 211 kBps
Data bit rate: 1,689 kbps
Average packet size: 844.05 bytes
Average packet rate: 250 packets/sec
SHA1: ffb5542c47da69ddc93da902136e1173d76b56e0
RIPEMD160: bc2102185a924096a8cf145c54375a05ab90e3c6
MD5: ba0e1addfcb36e7db6314764941fa6af
Strict time order: True

File name: minecraft-256compression.cap
File type: Wireshark/tcpdump/… – pcap
File encapsulation: Ethernet
Packet size limit: file hdr: 1520 bytes
Number of packets: 10 k
File size: 1,686 kB
Data size: 1,524 kB
Capture duration: 54 seconds
Start time: Tue Apr 28 13:45:28 2015
End time: Tue Apr 28 13:46:22 2015
Data byte rate: 28 kBps
Data bit rate: 226 kbps
Average packet size: 150.91 bytes
Average packet rate: 187 packets/sec
SHA1: 5b5e51f53f0716fd84a39120afd68eadbfaf9816
RIPEMD160: f2bf3839c084b1d7b31fce0a8a8ce959316643a7
MD5: dc6f56a5a1c10e642548e0eeb979629b
Strict time order: True

And now let’s look at the stunnel captures:

File name: stunnel-nocompressioninserver.cap
File type: Wireshark/tcpdump/… – pcap
File encapsulation: Ethernet
Packet size limit: file hdr: 1520 bytes
Number of packets: 9,949
File size: 2,159 kB
Data size: 1,999 kB
Capture duration: 59 seconds
Start time: Tue Apr 28 13:41:13 2015
End time: Tue Apr 28 13:42:12 2015
Data byte rate: 33 kBps
Data bit rate: 270 kbps
Average packet size: 201.02 bytes
Average packet rate: 168 packets/sec
SHA1: 418cc249c3393d85e6e59a6e02c02060b7b7ce4f
RIPEMD160: bf7f56af412734260e0e96d1a0c7d2f28be3ba95
MD5: 1b96fce1db9d38d8dbbecf9bb2278079
Strict time order: True

File name: stunnel-256compression.cap
File type: Wireshark/tcpdump/… – pcap
File encapsulation: Ethernet
Packet size limit: file hdr: 1520 bytes
Number of packets: 9,585
File size: 1,554 kB
Data size: 1,401 kB
Capture duration: 59 seconds
Start time: Tue Apr 28 13:47:35 2015
End time: Tue Apr 28 13:48:34 2015
Data byte rate: 23 kBps
Data bit rate: 189 kbps
Average packet size: 146.21 bytes
Average packet rate: 162 packets/sec
SHA1: 19b2bbfff8cd9c5c0e460d64ad0f4b966cf3a141
RIPEMD160: e31c226101daea9327a8b13a4a1012a24bea11c1
MD5: a7b4b0d5ecf3e6a472255cff13466b51
Strict time order: True

Well for me this is still interesting.  The stunnel connection sent less packets, and smaller.  I know that this is horrible to ‘measure’ like this, and yes none of the datasets are the same, making this kind of bogus. However, honestly compressing with stunnel does feel faster.

So, want to try?  I guess I can let people try if they want, but you’ll need stunnel.  I’ve read horror stories on griefers and I figure if i raise the bar to connect it’ll be somewhat distractionless.

So here is my stunnel.conf I’m using on the client side.

client = yes
compression = zlib
foreground = yes
debug = 6

accept =
connect = virtuallyfun.com:25566
cert = minecraft.pem

And of course, you need my certificate pair, so here is minecraft.pem:


And I run it something like this from the client side…

# stunnel mine.conf
2015.04.28 14:25:23 LOG5[ui]: stunnel 5.16 on x86_64-apple-darwin14.3.0 platform
2015.04.28 14:25:23 LOG5[ui]: Compiled/running with OpenSSL 0.9.8zd 8 Jan 2015
2015.04.28 14:25:23 LOG5[ui]: Threading:PTHREAD Sockets:SELECT,IPv6 TLS:ENGINE,OCSP
2015.04.28 14:25:23 LOG5[ui]: Reading configuration from file mine.conf
2015.04.28 14:25:23 LOG5[ui]: UTF-8 byte order mark not detected
2015.04.28 14:25:23 LOG6[ui]: Compression enabled: 1 method(s)
2015.04.28 14:25:23 LOG6[ui]: Initializing service [minecraft]
2015.04.28 14:25:23 LOG6[ui]: Loading certificate from file: mine.pem
2015.04.28 14:25:23 LOG6[ui]: Loading key from file: mine.pem
2015.04.28 14:25:23 LOG4[ui]: Insecure file permissions on mine.pem
2015.04.28 14:25:23 LOG5[ui]: Configuration successful

Now with stunnel connected, you just have to add a server, but you connect to ‘localhost’. This will have you talking to the stunnel program which then talks to my server, which then redirects to the VM running Minecraft.


Setup a server to ‘localhost’ to access stunnel


Now you can connect to the stunnel server

No promises on how long it’ll be up though.

Titan City!

Titan City!

For normal clients... (shhhh!)

For normal clients… (shhhh!)

With all the truecrypt hysteria running around

truecrypt-logoI thought I’d go mining for old versions, and put them up on CVS web.  Turns out some old versions are missing, but oddly enough not the 1.0 stuff.

So here is the src2html version, and the raw tree view.

And for the really crazy, I dumped all versions into CVS.

I only briefly looked at it, and noticed the block driver has the ability to look at memory.. I don’t know why, but I don’t think I would want my block drivers being able to do that.  maybe it’s a good thing, I don’t know.  I haven’t tried to build it, and I’ve never used TrueCrypt so I really can’t comment on it.

Also pulling through archvie.org I found some old versions of scramdisk. But I never used that either.