Thursday, December 10, 2015

Post #17 (Or... "Organic Thoughts: Now GMO Free!")

Time to break away from the technical posts for a brief moment. Well, kinda.

I have always found organic thought processes to be enjoyable and enlightening, especially when they lead to a "discovery". I'll explain, then give a few examples.

I am not a cryptographer. I have no training in cryptography whatsoever. Everything I know I have learned from articles, occasional technical papers, and real world encounters. Still, I often find myself thinking about crypto, whether or not it is a direct or indirect thought. In at least two of these instances, I have reached a realization that suddenly opens up my mental horizons, and I just "get" something. From there, it is easy to find a Wikipedia article or whitepaper describing what I just thought, but the exercise of leading my mind up to the concept with nothing more than breadcrumbs has always delighted me.

And now, those examples.

Realization #1: Wow! Good Crypto Really IS Hard!

Close to a year ago, I found myself in position where I had reason to believe someone may forge my signature on important documents. Without going into details, doing business with this individual was a necessity, so walking away wasn't an option. Still, I wanted to protect myself. I had an idea.

Idea: Sign all documents with some form of serialized string of text.

So, here we go. I am going to start signing all important documents with some form of serial number. My first thought was to combine a series of known numbers, and use that as a serial. For example, I may use my birthday (e.g., 11/24/74) and the current date (e.g., 12/03/15), plus the iteration of document signed that day (e.g., the first document is 1, the second is 2, etc.) So, altogether, my serial would read 1124741203151.

Problem: Way too predictable.

That system would break easily. Anybody could easily see any of my past signatures and figure out the system I was using.

Idea: Don't place the items in such a direct sequence.

So, instead of 1124741203151, I may have 1511741120324.

Problem: Still predictable.

If anybody had access to a set of my previous signatures, they would be able to figure out what changed between each signature and suss out the pattern.

Idea: Randomize the numbers.

There would be no sequence at all at this point. I would simply rearrange the 13 numbers in a random order every time.

Problem: Cumbersome, prone to collisions, and susceptible to forgery.

I would hate to have to sit there and go through the thought process of building a bank of the available serial digits, then picking them 1 by 1 until none remained. Also, depending upon the date and the iteration of signed documents, collisions could occur. Finally, with this level of randomness, someone could pick any random 13-digit number and forge my signature.

Idea: Cipher!

Instead of being random, I could develop a cipher. So, if we go back to the very first number, 1124741203151, I could work off the cipher of "Letter of alphabet corresponding to each number, shifted to the right by the numerical position of said number. For 0's, substitute an unshifted A." So, the first digit, 1, would be B; 1 corresponds to A, and 1 is the first number in our serial, so we move 1 letter to the right, which gives us B. The result of this example would be BCEHLJHJJMLQN.

Problem: Even more cumbersome. That example took me 5 minutes to complete.

Pretty self explanatory. I don't want have to cipher a 13-digit number every time I need to sign something.

Idea: To solve multiple problems, create a tool.

I could speed this along with some basic supplies from an office supply store by creating a small device with some wheels, charts, arrows and such that would allow me to input my plaintext, turn some things here and there, and output my ciphertext.

Problem: Now I have to carry said tool everywhere. People could watch me operating it and see that I am just ciphering my birthdate, the date, and one extra number, then reverse the cipher. Also, I'd want to store everything I'd ever ciphered for confidence's sake (if someone asks me "Is this your signature?", I'd want to be able to answer them with confidence. If the document signed isn't timestamped, I would not necessarily be able to do so.)

It would be burdensome and a chore to carry this cipher tool, use it without revealing its mechanics in public, and store a record of my ciphering operations.

Idea: Smartphone app.

This is where it all culminated. I already carry my smartphone with me. I could fairly easily create an app that generates a SHA256 sum or something comparably complex and unique, asks me for some details about the transaction, then stores the SHA256 sum and the details in a database for both later retrieval and prevention of collisions.

Problem: Kind of defeats the purpose of homebrew crypto.

Realization: And, as such, my thought experiment has ended. I have gained a healthier respect for all the work that goes into cryptography design and implementation.

Oh, and I never implemented this system for signatures. It's got to be a violation of Occam's Razor in dozens of ways, and I hate doing that unless unavoidable.

Realization #2: So THAT'S Why We Salt Passwords!

Referring back to my previous post about ASPXSpy, the sample I encountered had an MD5 sum in it that I later Googled to determine was simply "admin". That knowledge was thanks to someone's submission of that MD5 and its companion plaintext to the public Internet. I know that there are dozens of these projects, and even projects like Phuctor (which I believe is currently down due to a change of hosting provider on the creators' end), which aims to suss out RSA collisions by collecting submissions and comparing them. However, what I wanted to know was this; how could I, programmatically, iterate through as many plaintext strings as possible, hash them with MD5, store the pairing, upload it somewhere, and have others repeat the process while the database checks for duplicate pairings and rejects them. Essentially, how could I develop the project that would destroy MD5 forever?

Problem: Yeah, that has already been done.

So obviously I am not a genius. Nor am I the only person on the Internet thinking that same thought. With all of the brilliant folks out there aiming their mental artillery at this problem, it didn't stand a chance. So, why does MD5 still persist?

Idea: ...wait. Salt is as thing.

Yeah, so, basically, with the use of salt, even if I am able to reduce your hashed plaintext with a dictionary attack, I still can't get from the salted plaintext to what the actual password was before being salted. Unless, y'know, the salting was minimal and the password was awful to begin with (like akdjSimc381&.-&jdmekapcme versus m4o%n7k*e(y!; I bet you can spot the password in one of them, salt or no salt.)

Realization: And that was my final thought; without proper salting, hashing passwords alone is simply not enough. Computing power and the people knowledgeable enough and willing to wield it are far too abundant, and dictionary attacks are just too cheap and easy to get lazy with your password storage.

Anyway, obviously these thoughts were nothing earth shattering, but I do enjoy when I am able to think through the various stepping stones to these conclusions; it reassures me that my mind is tuned to the right frequency for figuring these things out.

No comments:

Post a Comment