Justin Troutman

“I’ll have the pancakes, please.” I’ll need to see some I.D. first.

The last place I expected to see a security issue was IHOP. Sure enough, though, this very thing happened in Quincy, Massachusetts. Here's the skinny. You walk into IHOP and ask to be seated, only to have a security guard ask to hold your I.D. What? This reminds me of the problem with drivers pulling out of gas stations without paying, which prompted the prepay idea. Logically, this would have been an obvious solution to try. Fortunately, this was the unauthorized move by a boneheaded employee, and not a corporate policy change. Customer, John Russo, replied, after being confronted by the security guard slash I.D. valet, “You want my license? I'm going for pancakes. I'm not buying the Hope diamond.” I heard a humorous joke about it, along the lines of needing a passport to order a Belgian waffle. Jokes aside, apart from being a ridiculous occurrence, the security implications of this situation are numerous.

The Hunt For Hash September.

Immediately following this years CRYPTO conference in Santa Barbara, NIST held The Second Cryptographic Hash Workshop. From that link, you can access the papers and presentations from the workshop. This, as some of you might know, is the think-tank for ideas that may eventually result in a new hash function standard. For now, the SHA-256 is a good interim standard, but we're going to need something new. I, as are many others, would love to see an AES-style competition for a new hash function standard. If it comes anywhere close to the success of the AES selection process, it would be yet another job-well-done by the cryptographic community.

I'm all for it. Until then, if you need a standard, for whatever the reason, go with SHA-256 for a 128-bit level of security. If you don't need a standard, and are flexible to choose any primitive, I'd suggest looking at Whirlpool; it's based on the wide trail design strategy that's found in Rijndael's (AES's) design, and was co-designed by Vincent Rijmen (The "Rij" in "Rijndael.) Until next time – cheers!

Honeyota – if Winnie was a car thief.

Minneapolis has this so-called "bait-car" program. Simply put, the police use nice rides as decoys to lure in car thieves. Concepts like this are certainly not new, but hey, it's something I just read in the "news" and my first thought was that it's analogous to honeypots, in some regards. The article opens up with the mention of a Toyota Camry being used as a decoy.

Those of you who are aware of my habit of concocting portmanteaux shouldn't be surprised at the title of this blog entry, which I've so guiltlessly dubbed, "Honeyota." Hehe. I'm anxious to hear about any other similar concepts you folks have used to lure in attackers, even if just for the purpose of siphoning useful information that may aid in thwarting potential future attacks on crucial systems.

Cheers, y'all.

DataDot – protect your goods (or own someone else’s!)

Okay, so this isn't new, but I've been wanting to point out what I feel is an obvious security failure. Essentially, these "DataDots" are laser-etched dots, granular in size, much like sand. They're prepared in a UV-based adhesive for application. The dots contain a unique identifier code, that upon application, will allow your property to be identified as belonging to you. This is beneficial, for stolen items that are recovered – at least, that's what they're aiming for. Here's their home page, and here's a video that introduces the concept.

My questions are: "What happens if I put my DataDots on someone else's property, and report it stolen?" "What happens when property is sold that contains DataDots?" "What happens if there are multiple DataDots, with different identification numbers, on the same item?" There are various ways to look at this problem, but these are the first few questions that pop into mind. This reminds me of a cryptographic problem involving MACs. (Y'all know how much I love MACs.)

The problem I'm referring to is as follows. A MAC, or Message Authentication Code, is a keyed function that serves the purpose of preserving the integrity of a message. Let's say Alice and Bob are communicating, and want to ensure that an adversary doesn't tamper with the message. Alice and Bob share an authentication key. Alice computes a MAC on the message, using this shared key. When Bob receives the message, he authenticates it using the same key. If the MAC he computes matches the MAC sent along with the message, then the message hasn't been tampered w

Scroll to Top