Extending SRP's guarantees to validated registration

This post is about work done jointly with Michael Sanders and Jacob Hurwitz for 6.858 (One of MIT's Computer System's Security courses).

The Stanford Remote Password Protocol is a really amazing little piece of cryptography. Like almost every great crypto-system, it provides seemingly impossible guarantees. Namely, it allows a server to recognize a client without having any real usable information about them.

In most authentication systems, the server is at some point in time privy to sufficient information to impersonate the user: perhaps you send your password to Google, Microsoft, or Facebook, or perhaps you send a hash. Regardless, as some point in the process, the server sees enough information about your password to fake a login later. With SRP, this isn't the case. To quote the SRP website:

SRP is a secure password-based authentication and key-exchange protocol. It solves the problem of authenticating clients to servers securely, in cases where the user of the client software must memorize a small secret (like a password) and carries no other secret information, and where the server carries a verifier for each user, which allows it to authenticate the client but which, if compromised, would not allow the attacker to impersonate the client. In addition, SRP exchanges a cryptographically-strong secret as a byproduct of successful authentication, which enables the two parties to communicate securely.

 Still, there is a slight problem with SRP, if you're willing to crimp down your tinfoil hat a little.

It's been a while!

I haven't forgotten about this blog! I've just been a tad busy recently.

I've got a bunch of projects (mostly classwork, I confess) I plan to post soon, so check back in a week or so!

~Ninjinuity

Voice Controlling Hexy

(This post is a bit rough, but I figured I should get it out there, since I won't be working on Hexy for a little while.)
Before we get started:

1. The code used to make this all work is on Github. I'm new to ROS, so I don't claim that it's set up correctly.
2. To get things to ROSLaunch nicely, I had to make some pretty hacky changes to how PoMoCo deals with directories. Basically, it now has to use full paths to every directory ( these paths are created at runtime using __file__ ). I haven't seen it fail yet, and I can't think of a specific failure mode, but it makes me very uncomfortable, and I'm looking for a way to change it.
3. ROSPoMoCo isn't a full substitute for PoMoCo yet. Offsets, for instance, can't be set in ROS, though they are loaded from the .cfg file.

After a bit of hacking, I've ported most of PoMoCo over to run as a ROS Node. This node listens for new moves on the /moves topic and runs them if it is able to (If it can't find the move, it issues a Warning and ignores it).

At this point, it's time to take advantage of ROS to do neat stuff with Hexy. At first, I wasn't sure what exactly I wanted to do, but some Googling brought up this blog post, in which an iRobot create is controlled by voice. The package used to do this is perfect for controlling something like Hexy -- pocketsphinx will broadcast any recognized phrase on the \output topic, and the set of recognized phrases can be set with a text file.