Comments on: Cloudy Verification

By: alexr

alexr — Thu, 01 May 2008 02:16:50 +0000

Although Cloudy’s usage model isn’t yet clear, this authentication method appears to require the availability of real-time out-of-band communications. Were I to wish to use Cloudy (for whatever it’s purpose is) with my coworkers in Japan, this might present a problem.

By: hendrik

hendrik — Sun, 27 Apr 2008 06:42:33 +0000

Thanks for the detailed explanation. Clever. I like it.

By: Jens Alfke

Jens Alfke — Sun, 27 Apr 2008 06:23:46 +0000

I don’t blame you, this stuff is confusing! I had to read several papers, argue with a friend, and scrawl notes on paper before I really felt safe implementing the verification protocol.

Each peer does this:

1. Generates a random 64-bit number.
2. Sends it over the connection to the other peer.
3. Concatenates that number with their own public key, takes the SHA-1 hash of that, then takes the first 32 bits of the hash and uses the mnemonicode library to turn those 32 bits into a three-word phrase.
4. This is the challenge phrase that the user needs to hear over another channel and click the radio button for.
5. Repeats step 3 on the 64-bit number received from the peer and the peer’s public key — this is the phrase that will be displayed on-screen for the user to read to the other person.

The trick is that, by basing the challenge phrase in part on a random number that’s not chosen until the procedure begins, it defeats any attempt by the attacker to pick a public key that happens to “look enough like” the one they’re trying to impersonate.

For example, if you just hashed the other person’s public key and used 32 bits of that, the attacker could generate keys over and over ahead of time, till they found one that would generate the same result as the real person’s key. That would take on average only 2^32 operations … feasible if they have weeks to prepare.

But with the real protocol, the hacker would have to do a comparable brute-force search, but couldn’t begin until he received your random number. And no one is going to leave this panel up for a week waiting for a reply.

By: hendrik

hendrik — Sun, 27 Apr 2008 06:04:13 +0000

I initially thought that this would give a man in the middle a 1/6th chance of undetected attack. But I now realize that that is not at all so.

By: Jens Alfke

Jens Alfke — Sun, 27 Apr 2008 04:30:15 +0000

“Is a 1/6th chance of randomly guessing secure enough?”

I decided not to fight too hard against the user. Preventing the automatic click of the OK button is important, but beyond that I’ll make the assumption they’re not just guessing.

Thanks for the compliments on Jed’s art! But as an icon, the original line art just looked too flat to me, against all those sexy Aqua icons next to it in the Dock. Ah well, it’s only a placeholder anyway.

By: hendrik

hendrik — Sun, 27 Apr 2008 01:21:33 +0000

Very interesting writeup. It’s true that we put way too much trust into email and such. Spammers recently started using my work email address as From: address for their spam and I got flooded with all the undeliverable replies from mail servers. It is frustrating to realize that there is exactly nothing I can do about it (except setting up filters to keep those replies out of my inbox).

Is a 1/6th chance of randomly guessing secure enough? Why not have multiple choices for all 3 words independently? Say 5 words each for a 1/125th chance of correct random guessing. The big hurdle here for users really is not the number of clicks in answering this dialog but establishing the second communication channel (phone or such).

I’d recommend loosing that radial gradient in your Cloudy icon. Stay true to your son’s artistic vision! :) Your son is crazy talented by the way, those comic strips are excellent.