AltSci Blog

I have setup TLS for sono.us and www.cell-game.com using Let's Encrypt. Both certificates will expire January 25, 2016.

Instead of running letsencrypt with sudo privileges on my server, I ran letsencrypt-nosudo. According to Issue #5, this can be done using the official client as well. Because letsencrypt-nosudo was very short, I was able to modify it and vet it easily. There are weaknesses in any system, but the options are quite limited in this system. If you'd like my patch, let me know.

Aug 14, 2015

sat1-0.1.tar.xz [sig]

I solved my first SAT problem and in doing so, I had to write a valuable improvement to satispy, a simple and powerful Python frontend to minisat and lingeling. I'm making a pull request to netom, the author of satispy and I am publishing my code on Github since the original was published on Github. Allow me to show you the problem I was working on and the possibly elegant solution.

April 13, 2015

Hi Jim, this is Joel. I'd like to ask you to tell your fellow congresscritters to vote against reauthorizing section 215 of the Patriot Act. You understand that the mass surveillance that is currently occurring under your watch is unconstitutional and makes our country not a functioning democracy but a dictatorship, a tyranny. Tell your fellow congressmen and congresswomen to vote against reauthorizing section 215 of the Patriot Act and that will be a step toward making our nation a functioning democracy with a working system of checks and balances. Nothing can undo the harm that has already occurred under the Patriot Act and we can no doubt expect that the NSA will repeatedly attempt to continue mass surveillance of the entire world, including innocent American citizens here in the US. Constant vigilance is required to ensure that the tyranny that the NSA has created collapses and is never again rebuilt.

I will keep the rest of my thoughts to myself so that you can go on doing your job.

April 8-10, 2015
Permalink
keystream_dupe-0.6.tgz [sig]
keystream_dupe-0.5.tgz [sig]
keystream_dupe-0.4.tgz [sig]
keystream_dupe-0.3.tgz [sig]
keystream_dupe-0.2.tgz [sig]
keystream_dupe-0.1.tgz [sig]

In this very basic cryptography exercise, I have written a simple test of the quality of a cipher. For RC4 and stream ciphers, we can encrypt \x00\x00\x00\x00 to get the first four bytes of the keystream. I do this for the first 1048576 keys (assuming big endian and 64-bit keys) with RC4. Then I find out how many random keys I have to try before I find the same first four keystream bytes. I do this 1024 times. The data shows that this is around 4 million keys.

For block ciphers like AES, we have to do it slightly differently, but the concept is the exact same. I encrypt "GET / HTTP/1.1\r\n" which happens to be 16 bytes, the exactly correct size to fit in a single block of AES plaintext. I store the first four bytes of the ciphertext for the first 1048576 keys (same assumption as above but 128-bit keys). Then I do the same with random keys and I compare the first four bytes of the ciphertext against the first four bytes of the 1048576 partial ciphertexts. I find out how many random keys I have to try before I find the same first four ciphertext bytes. I do this 1024 times. The data shows that this is around 3 million keys. As you can clearly see, this is far smaller than RC4 (which is known to be vulnerable to many attacks).

To test whether the problem is in AES or RC4, I used my system's random number generator (Linux /dev/urandom) to generate random bytes of keystream and tested how many attempts it would take to collide 1024 times. It took on the order of 4 million. This proves that the issue is either in AES or in RC4 and my system's random number generator. Since my system's random number generator is as good a source of entropy as I have, I must conclude that there is no issue with RC4 and that there is an issue with AES.