This is in response to an email I recently received (edited a bit for clarity)

With our current resources we can test passwords to their hash in fractions of a second allowing for well resourced groups to test thousands of passwords every second. This means, given enough time and resources, you can crack any password within a reasonable length and as you increase length you increase the likelihood of people resorting to identifiable patterns in order to remember it.

Solution idea (not unique but not used from what I can tell): Use the hashing function 1000 times on the password. The hash is not any more secure but the time to brute force would change from hours to years. From what I can gather online I heard that multiple hashing creates larger hashes which lead to collisions. This doesn’t make sense to me because I created the example below and I don’t see how it would lead to a change in collision frequency. I do understand that it would guarantee someone the opportunity to “know” the size of the input and do 999 hashes to find the final but considering the size of the hash and the fact that it still doesn’t give you the original input I fail to see how it would matter. Additionally, if there is something I am missing about the collision frequency increasing could we not add a different salt between each function … what are your thoughts?

More→

This post really isn’t up to the standard of most others here. However, there comes a time when writing anything is better than nothing. I’m also glazing over a lot of details that would be important in implementing a Symbolic Execution Engine.

I am interested in the discovery of memory-corruption vulnerabilities. The two often-used methods for finding these vulnerabilities, fuzzing and reverse-engineering, are producing fewer results, and some people have stopped looking for memory-corruption vulnerabilities altogether. As our mainstream software is coded to higher, and more secure, standards, the identification of these vulnerabilities is becoming harder, and we need new methods to find them.

Enter Symbolic Execution. I’m still learning about this method of vulnerability identification and implementing it into rop_tools (source no longer available), but I thought I would share the basic concepts with you. Know that a joint effort between UC Berkely, Carnegie Mellon and the College of William and Mary has brought us BitBlaze, an academic pursuit using much of the technology I’ll be covering.
More→

This post is about a new tool I’ve been working on, rop_tools. This is a tool for working with rop gadgets in ELF binaries (currently only 32-bit). But first I’ll talk about the reasons why I wrote the tool.

I was recently working on exploiting a binary in linux. This binary was small, and I needed all the gadgetry I could find. I turned first to msfrop, but it wasn’t hacking it. I needed to look 2, 3, 4, any arbitrary number of instructions back. I was interested in not just ret gadgets, but gadgets that jump to registers and call registers.
More→

I read an article last night (this one in fact) which included the following sentence:

“That said, it is no longer secure to hash your passwords with MD5, much less when it is unsalted.”

I cringed. I understand this sentence comes from a common misunderstanding of what security a cryptographic hash brings to your password protection scheme. Today, we’re going to try and understand it. A most basic understanding of password cracking is assumed.
More→

This post is a basic explanation of the concepts behind sending/receiving messages with PGP. This is the basic information I want someone to understand before I start communicating with them. These explanations are fairly simplified.

Infeasible means it is very, very difficult to do something. In cryptology, this usually equates to something along the lines of, “It’s possible with known algorithms and the expected advancements in hardware, but it will take thousands/millions of years.”
More→

I just came across this post talking about a reflective XSS attack on google that only worked on IE 6/7. I’m going to make an assumption and assume this is due to Internet Explorer 8′s resistance to reflective XSS. I also came across this issue about a week ago and thought I would share some findings.
More→

I know this talk took place at Shmoocon, and though I was not able to attend it, I just stumbled across this write up of the material covered. I believe it’s time to discuss a project of mine from a couple years ago: The Boot and Pwner (affectionately named The Bwner). I’m tired, so we’re going to keep this brief.
More→

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

More→