AltSci Blog

This blog post is a quick video with some backup data for my Small Wide World project.

Welcome to a quick update for Small Wide World. Progress on this project is moving rapidly so I just like to let you know what's going on and how awesome it is. The first improvement you've probably noticed on the website is better looking graphs all over it. That's a good sign that things are improving but that's just showing you the interesting improvements that can be made with a little bit of code. Today I wrote this code I'm going to show you. Here you see a two-node graph with a and b. It's the simplest you can get. You can see that we've added a new node onto a here. So now we have a three node network. And then you see it's the same network c-a-b and we've connected that via a to d. You can see that even though it looks different, we still have c-a-b and d and we've just connected e to a. This is a self-organizing network. It's actually very fast, it uses very few operations so it's going to become the default algorithm for the web, Python, C, and all versions. They will use this algorithm to make the initial pattern. It doesn't work perfectly for all types of graphs, but it works especially well for these types of graphs: graphs which aren't cyclic and are using lots of branches. See that we add g to b. See the angle between g-b-a, g-b-f, and a-b-f are all the same and the length of all the bonds are the same. This is a very easy technique that shows a graph effectively. This makes it so that you can understand the graph more quickly — or at least that is the idea. We've added h, we've added i, we've added j, and k. Then you see we've added l to d, so in order to make a-d-i, i-d-l, and l-d-a equal angles we turned d-i-k sideways. This is just another one rotated because we've added m to a here. You can see n added, we're getting close to where nodes start to overlap with each other. That's one limitation of this algorithm, but I can pretty confidently say that solving that is a job for a more expensive algorithm, for example global optimization. Once this algorithm has finished you can run a global optimization algorithm on it and it will have better success than just a random graph. You can see that k, h, and c are a little crowded, so an optimization algorithm would push these away from each other because k and h are too close to one another. We're almost to the point where it's going to fail. And here we see that it fails with c-h overlapping p-q and c-s overlapping i-k. In order to fix that, an optimization algorithm would only have to move p and q down and i and k up. How much computation does that require? Local minimization algorithms would probably be able to do this in a few million operations (less than a second but far more than this algorithm takes), but if they couldn't properly solve the collision, you'd have to use a global optimization algorithm like basin-hopping or Monte-Carlo Metropolis to finish the job. This could take seconds or even minutes. Small Wide World currently implements basin-hopping using SciPy which I will be testing thoroughly against graphs like these.

July 28, 2015

Update July 29, 2015

Rather than discuss something important or release something interesting, I thought I'd release a piece of non-music audio for the purpose of demonstrating a new breakthrough I've made in sample production and artificial intelligence research. I have automated the process of creating samples based on polynomials. It's a very streamlined process which has produced the below samples. They aren't meant to be musical, so don't complain. Also their volume is way too high so you should turn down your volume before listening to them.

Each are 6 minutes long and it's pretty obvious what the theme is. It doesn't change drastically. That's because it's not music. What is shows is a simple algorithm.

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 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.