Not having fun with Python/Debian 9.1

Well after my last Star Wars Galaxies adventure, where I tried to run MySQL on Linux Subsystem for Windows v1, I got some weird shared memory error, and it wouldn’t run. Even the old BSDDB engine was bombing out trying to create files. So fine, whatever I thought I could move on, and that is when I found out that somehow OpenSSL & Python had utterly collided.

Python 1.13 (default, Sep 26 2018, 18:42:22) [GCC 6.3.0 20170516] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import ssl Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.7/ssl.py", line 98, in import _ssl # if we can't import it, let the error propagate ImportError: /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1: version `OPENSSL_1_1_0' not found (required by /usr/lib/python2.7/lib-dynload/_ssl.x86_64-linux-gnu.so) >>>

Well isn’t that great. I tried un-installing & re-installing Python over and over, along with trying to force re-install OpenSSL. No dice.

So what finally got it working for me was to purge OpenSSL.

apt-get purge libssl1.1

And after that it pulled out everything that was using it, well over 500MB of stuff I’d installed. And for good measure I followed up with the autoremove for an additional 384MB of stuff to remove. And then for the final step, of just installing Python:

[email protected]:~# apt-get install python2.7 Reading package lists... Done Building dependency tree Reading state information... Done The following additional packages will be installed: libpython2.7-stdlib libssl1.1 Suggested packages: python2.7-doc The following NEW packages will be installed: libpython2.7-stdlib libssl1.1 python2.7 0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded. Need to get 3,537 kB of archives. After this operation, 12.8 MB of additional disk space will be used. Do you want to continue? [Y/n] y Get:1 http://deb.debian.org/debian stretch/main amd64 libssl1.1 amd64 1.1.0j-1~deb9u1 [1,354 kB] Get:2 http://deb.debian.org/debian stretch/main amd64 libpython2.7-stdlib amd64 2.7.13-2+deb9u3 [1,897 kB] Get:3 http://deb.debian.org/debian stretch/main amd64 python2.7 amd64 2.7.13-2+deb9u3 [285 kB] Fetched 3,537 kB in 0s (13.2 MB/s) Preconfiguring packages ... Selecting previously unselected package libssl1.1:amd64. (Reading database ... 27441 files and directories currently installed.) Preparing to unpack .../libssl1.1_1.1.0j-1~deb9u1_amd64.deb ... Unpacking libssl1.1:amd64 (1.1.0j-1~deb9u1) ... Selecting previously unselected package libpython2.7-stdlib:amd64. Preparing to unpack .../libpython2.7-stdlib_2.7.13-2+deb9u3_amd64.deb ... Unpacking libpython2.7-stdlib:amd64 (2.7.13-2+deb9u3) ... Selecting previously unselected package python2.7. Preparing to unpack .../python2.7_2.7.13-2+deb9u3_amd64.deb ... Unpacking python2.7 (2.7.13-2+deb9u3) ... Processing triggers for mime-support (3.60) ... Processing triggers for libc-bin (2.24-11+deb9u4) ... Setting up libssl1.1:amd64 (1.1.0j-1~deb9u1) ... Processing triggers for man-db (2.7.6.1-2) ... Setting up libpython2.7-stdlib:amd64 (2.7.13-2+deb9u3) ... Setting up python2.7 (2.7.13-2+deb9u3) ... Processing triggers for libc-bin (2.24-11+deb9u4) ...

So now you think its going to be broken right? It’s the same libssl package! I didn’t even run an ‘apt-get update’. And guess what?! You would be wrong.

[email protected]:~# python Python 2.7.13 (default, Sep 26 2018, 18:42:22) [GCC 6.3.0 20170516] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import ssl >>>

That’s right, it’s now working.

Speaking of Picard, I hear there will be a new series, inspiringly named ‘Picard’. Apparently it’s going down the same path as STD, complete with a lack of backers, and merch. I’m hoping it’ll be something watchable, although they certainly cannot afford any of the TNG cast as they apparently have zero budget. Maybe it’ll end up as another ‘Jake Skywalker’ or ‘Not my Picard’. But the bad reboot 25% contractual difference could be the difference between something new, or something so divergent that there was no point in even attempting to be a Trek.

Anyone using truecrypt or any derivative work

will want to incorporate these patches on the Windows platform:

https://github.com/veracrypt/VeraCrypt/commit/9b24da3398581da1fa66c6b8f682bbcfa7ded4fd

https://github.com/veracrypt/VeraCrypt/commit/b7f9df6e4f09ba342fdbbadc63af5062cc57eaf2

So yeah, apparently you can get full admin rights through the driver. oops.

Fun with PGP 1.0

Well I got slightly bored, and thought I’d dig into some old crypto software.  And PGP 1.0 was as good as any place to start.

Now one scandalous thing at the time was the inclusion of RSAREF 1.0, the RSA reference library which redistribution required a license that wasn’t exactly included with PGP.

A company called Public Key Partners (PKP) holds the exclusive
commercial license to sell and sub-license the RSA public key
cryptosystem. For licensing details on the RSA algorithm, you can
contact Robert Fougner at PKP, at 408/735-6779. The author of this
software implementation of the RSA algorithm is providing this
implementation for educational use only.

And wow was this fun at the time.  As far as I know this license lapsed on September 21, 2000

And then there was this slight issue:

After Biham and Zimmermann go their food and sat down, Zimmermann took out a few pages of computer listings.  Within minutes, Birham was finding fundamental flaws in Bass-O-Matic.  Some of the flaws were subtle-weaknesses that made the algorithm susceptible to differential cryptanalysis, which was Birham’s speciality. Others were more embarrassing, like a conceptual error in Zimmermann’s algorithm that prevented the last bit of each byte from being properly encrypted.  After ten minutes of Birham’s onslaught, Zimmermann realized that Bass-O-Matic was a lost cause.

So now you would be wondering, why would I even bother with what was a quickly abandoned encryption?  Well I was bored, and I was more interested if I could locate the source to 1.0.  What would be more interesting to me is to revive it onto somewhat more modern 32-bit platforms.  Namely OS X, Win32 and MS-DOS.

With a little luck, I found the unix_pgp10.tar.gz, which does contain the source code for a Unix version of PGP!  This version is more so geared to the SPARC of all things. Specifically it mentions:

Tested on SunOS 4.1 with gcc 1.39

However building on OS X was trival with changing the Makefile.  The CC had to be changed to reflect a 32bit build, and the DEFINES had to remove the HIGHFIRST define, as the x86 platform is little endian.

CC=cc -arch i386

DEFINES= -DUNIX -DPSEUDORANDOM -DUNIT16 -DPORTABLE

Is the relevant changes.

And even better it’ll work!

$ pgp pgp.ctx pgp.exe

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 has signature. Public key is required to check signature.
File ‘pgp.ctx’ has signature, but with no text.
Text is assumed to be in file ‘pgp.exe’.
.
Good signature from user “Zimmermann, Philip R. – [email protected]”.
Signature made Wed Jun 5 13:51:18 1991

Signature and text are separate. No output file produced.
Plaintext filename: pgp.exe

Wasn’t that great!

Now getting this to run on Windows was a little bit more of a challenge.  I was going to build from the UNIX source code again, however both Visual C++, and Watcom C++ build an executable, but neither are able to add keys to the keyring, verify the executable reliably and deadlock all the time.

So I thought I’d get a little creative and start replacing some code from the MS-DOS version of PGP. It turns out that all I needed was rsaio.c & rsaio.h and I was able to build an executable.  But I ran into other snags, and stack errors.  A glance at the MS-DOS Makefile, and I saw that they had to up the stack size from the defaults.  So I figured the same would hold true, and I picked a much larger 32kb stack for the heck of it.  I mean it is 2014, and if you can’t handle a 32kb stack well..

Compiling on Visual C++ went like this:

cl386 -c /DPSEUDORANDOM /DUNIT16 /DPORTABLE *.c
cl *.obj /F32768 /Fepgp.exe

And for Watcom C++

wcl386 -c -dPSEUDORANDOM -dUNIT16 -dPORTABLE *.c
wcl386 *.obj -fe=pgp.exe -k32768

And now I can build for either compiler.  And even better, it works!

PGP 1.0 on Win32

PGP 1.0 on Win32

Even for completness sakes, DOS4G/W works as well! Just remember to link for MS-DOS

wcl386 *.obj -fe=pgp.exe -k32768 -l=dos4g

And you should be good to go.

PGP for 32bit MS-DOS

PGP for 32bit MS-DOS

So what happened to PGP?  Well version 2 used a more ‘acceptable’ encryption, the IDEA cypher, then the company was sold, IP was sold again and again.  It’s still out there, mostly for email encryption.

While it sure did ignite the world on fire for a while, the overall difficulty of using it, combined with the ease of losing the private key and all your data is just too easy.  But this really is the nature of the beast.

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.