Sunday, April 29, 2012

Quick Project #2: Ruby Methods for Protecting Against Timing Attacks

Breaking with my usual style, Quick Project #2 doesn't necessarily relate to music programming.

Today I came across a nice little article and demo on r/compsci about timing attacks.

Timing attacks are something that I had learned about a few years ago but for whatever reason had dropped from the forefront of my engineering consciousness. In order to bash myself over the head with it (and provide a universal solution), I created Ruby wrapper methods for Object#send and block evaluation that are padded with a fixed timing delay.

Here 'tis, including some basic String comparison examples at the bottom:

https://gist.github.com/2554841

To use it, just pass in a "safe" duration (in seconds) that likely exceeds any possible amount of time it could take to evaluate the code. In the following example I use the greatly exaggerated value of .75 seconds. In the wild, you'll most likely be working in smaller durations

  is_match = ExpressionTimer.block(0.75) { "password attempt!" == "my password!" }

When the example is run, no matter how quickly the block actually evaluates, it will always take exactly 3/4s of a second to return. As a result, actual timing information is lost in the ether and can not be gleaned by any outside observer.

1 comment:

  1. I myself prefer a bit of randomness. Something like 0.75 + rand(1000)/10000

    ReplyDelete