The talks I plan on attending, in chronological order:

I have been a flurry of posts for the past few days, and have gained interest with this simple, pen-and-paper-able cipher. The more I think about it, the more improvements I make.

I am going to start with a brief introduction of some related ciphers, and then break down my cipher. If it seems I am breaking down simple concepts, please remember that not everyone who reads this blog is a crypto-king.

Broken

Feeling confident, I took this cipher to IRC. It was quickly broken. Here is a quick synopsis of irc.freenode.net#crypto:

22:53 < yarrkov> endeavormac: So, let's say the key length is 4, and you know the plaintext for 4*2-1 consecutive characters. Subtract those from the ciphertext to get a piece of keystream.
22:53 < yarrkov> Let's call the KEY character variables a, b, c, d; the OIV is e, f, g.
22:54 < yarrkov> Then you basically know a+e, b+f, c+g, d+e, a+f, b+g, c+e (mod 26). You can solve that as a system of linear equations.
23:08 < endeavormac> yarrkov: just got back, reading
23:13 < endeavormac> ok, now trying to figure this out
23:15 < endeavormac> a+e+KNOWN=KNOWN... d+e+KNOWN=KNOWN ... ok i think i'm getting to this
23:16 < endeavormac> so you're saying 7 unknowns, abcdefg, and 7 equations
23:18 < yarrkov> yeah
23:22 < endeavormac> awesome, thanks. back to the drawing board

Continue Reading »

Nothing is as humbling as realizing your mistakes after-the-fact. Let’s review the cipher from my previous post, locate some flaws, and make some improvements.

First, while permuting the key with ciphertext would make the final text more diffused, because the Vigenere Cipher is not much more than basic modulo arithmetic, the diffusion added from the ciphertext can easily reversed by subtracting previous ciphertext from subsequent ciphertext. IE, if we know the ciphertext[16] was encrypted with key[0] + ciphertext[0], and we know ciphertext[0], we can simply subtract ciphertext[0] from ciphertext[16]. This will remove any diffusion gained from using ciphertext. Using ciphertext to add diffusion was foolish and naive ;).

The alternative is to use plaintext, as is done in the Autokey Cipher. However, plaintext is not random, and this will result in less-than-adequate diffusion in our ciphertext (albeit not subtraction-reversible diffusion). We want to stay away from using plaintext to continue to permute our key.
Continue Reading »

Having too much fun with my droid, I have continued to read about the awesome scripts and programs available. One that caught my eye was A script for blowfish encrypted SMS messages. SMS isn’t secure, and I thought, “How cool would it be if I could encrypt messages on my phone and keep the key in a QR Code.” Passing around a sheet of paper with a QR code on it to a few people gives us all a new key to use for the day. As long as my phone itself wasn’t hacked (which is probably a reasonable fear), and the QR codes were not compromised (which, also, is a reasonable fear), and my own little cipher wasn’t cryptographically destroyed (which, in addition to the other fears, is reasonable) this would be a cool way to keep GSM sniffing hackers from reading my texts. Plus, it would be cool as hell.

And why blowfish? Why not go for something a bit more retro… a bit more 19th century. How about the Vignere Cipher with a few modifications to prevent us from being too-easy pwnsauce.
Continue Reading »

A few days ago I caved in, cancelled my AT&T service early (something I’ve been meaning to do for a while), and picked up a Motorola Droid 2 from Verizon. When I first turned on my new Droid 2, I noticed Verizon had added a bunch of useless apps that I could not remove. A quick search revealed I needed to “root” my phone if I was ever getting rid of those pesky apps. I didn’t quite understand what root was going to do for me until my phone was rooted. This is when I first realized how cool the Android OS is.

The Android OS is built on top of linux. You are given a user account with restricted permissions. Rooting the phone involves a local privs escalation vulnerability to change permissions on /system/bin (Android’s /usr/bin convention), and copying over a su binary for the user to assume root.

After rooting the android, I played around for a bit. It’s an ARM based CPU (duh), and I’m running kernel 2.6.32. Android doesn’t come with a polished set of OS utilities, but a copy of busybox will do the trick. You can use a terminal application for Android, or grab the Android SDK and connect to your droid over usb with “adb shell”. Now that I had control over my droid, I was feeling a bit better. It was time to see how easily I could program this thing.

That’s when I came across SL4A, or Scripting Layer For Android. You can find the project here. The great people at SL4A have python, jruby (no metasploit for jruby yet :(), lua, perl, and a few other languages all running on the Android OS. However, here’s what’s really cool. They have taken a large portion of the Android API and created a high-level, scriptable interface to it. The folks over at SL4A are now my favorite people in the world.
Continue Reading »

This post serves as a (hopefully soft) introduction to the MD5 cryptographic hash. It has been written to bring some of the people I work with up-to-speed on exactly how MD5 works in the hopes they will stop giving me strange looks when I talk about it.

What is MD5?

MD5 is a cryptographic hash. It has a 128-bit checksum, or resulting hash value, which is split into 4 32-bit words. It processes data in 512-bit chunks, or 64 bytes at a time.

Basically, these two properties are supposed to hold true for MD5:

It’s also a great generic hash, and once you understand MD5 other hashing algorithms seem much less daunting.
Continue Reading »

Recently I found myself coming across numerous WPA-PSK encrypted wireless APs, with a desire to access them. I think it’s safe to say we all know about the WPA CoWPAtty tables, but these APs did not have names that were in the tables. To make matters worse, at the time the only available hardware I had available was my netbook, and I was attempting ~280 keys a second. With my massive dictionaries with millions and millions of real-world passwords to attempt, it was going to take hours for each AP.

I decided I needed to order my password dictionaries in a manner that would bring the more likely passwords to the beginning, and the least likely passwords to the end. I wasn’t aware of any program that did this, and figured I would write my own.

A few hundred lines of C later and I have a very fast password dictionary ordering program. It is far from perfect, but much better than nothing. It loads the entire dictionary into memory, creates all the information necessary for markov chains, and then uses this information to score each individual password. The passwords are then ordered by their score.

You can find the code in the rainbowsandpwnies googlecode svn repo.

Only about 1/4 of my projects ever make it to any sort of announcement or release. Usually, those releases are silent through svn somewhere. However, I’ve finally reached the time to take a look at the stock market, and have figured, naturally, my best bet is with tech stocks.

In any case, I thought tonight would be a good chance to share one of those many projects that never see foreign eyes. I thereby present you with my custom spin on what a tech stock tracker should look like. I’m not trading minute to minute, or hour to hour, so I don’t care about real-time stock quotes. What I do care about are new announcements that may tip a stock one way or the other, or stocks that look like they may be headed towards rapid change.

Right now, you’re looking a few hours in python, on a 10 minute cron. It grabs information, parses it, and generates static html. I have plans yet to continue to improve this project. More specifically, I’d like to delve deeper into the news articles, counting keywords that may indicate the direction a stock is about to head. I also planning on grabbing historical stock information and running some regression stats in an attempt to automate finding what stocks are very closely related to one another. If stocks A, B and C are all closely related, and news indicates good things for A and B, good things are most likely in store for C.

A Quick Background on Perfect Rainbow Tables

Rainbow tables allow us to find plaintexts to cryptographic hash algorithms quickly. They are based off of Hellman Martin’s “A Cryptanalytic Time – Memory Trade-Off“. By including the step in the reduction function, Phillipe Oechslin was able to improve on Hellman Martin’s method, and we came up with Rainbow Tables, the “Faster Cryptanalytic Time – Memory Trade-Off“.

If you are unfamiliar with rainbow tables, it is suggested you become familiar before continuing.

Even rainbow tables are not perfect. They still merge, and merges mean wasted information, wasted space, wasted time. What we really want are perfect rainbow tables. In perfect rainbow tables, each chain has a unique endpoint. We have no merges. They give us nearly the same percentage to find a plaintext as non-perfect rainbow tables, but are much smaller.
Continue Reading »

I posted x86 Assembly for C Programmers 1 to reddit and got some great feedback. There were a few things that were brought up, and I’m taking a minute to address some of them (I’m not addressing everything).  Thanks to everyone out there who took the time to point out mistakes and make suggestions. Continue Reading »