[cryptography] Peer review request - Loplop

Uncle Zzzen unclezzzen at gmail.com
Sat Nov 17 06:48:36 EST 2012

On Sat, Nov 17, 2012 at 9:51 AM, Kyle Creyts <kyle.creyts at gmail.com> wrote:

> giving it an extremely brief run-through, I'd say that you've made a
> different compromise than the app-maker chose in making the limit 8.
> the choice of 8 base64 digits out of the 24 given by the md5 appears
> to have been explicitly done to combat attempts to attack the master
> password, or other account passwords, based on the possession of any
> one (or several) account passwords and nicknames or labels.
> while you may have succeeded in making your individual passwords
> somewhat harder to brute-force, you've also used a larger portion of
> the md5, increasing the amount of information an attacker is given by
> the compromise of an individual password, and shrinking the number of
> possible candidate md5s they would have to guess to attempt to collide
> in hopes of getting your master password.

Interesting point, but IIUC, the difference is that if they come up with N
master passphrase (MP) candidates knowing a nickname and an 8 character
password, then with a 16 character password, they'll end up with sqrt(N)
candidates (am I right? I'm using "intuitive math" here).
My intuition also says N wouldn't be very large (in the sense that trying
all N would be a lot less work than finding them), and reducing the work by
a factor of sqrt(N) wouldn't be much of an achievement.

N can also be reduced further by sorting the MPs by heuristics re the
likelihood of a string being a human-memorable MP (would mainly consist of
dictionary+leet, dates, phone numbers, etc.). My intuition tells me such
heuristics were researched already (am I right?).

> in addition, they would
> likely have to have at least another of your passwords and nicknames
> to confirm the plausibility of the correctness of a given collision
> for a given MD5 guess, if I understand it correctly.

Not sure the nickname is needed.
My intuition says most [l]oplop users would have some simplistic method for
picking the nickname (otherwise they'd have to write them down and end up
with a cumbersome equivalent of a traditional password manager). Chances
are that the other nickname (you already know) of the user looks like
alice at twitter,TwitterAlice2012, etc. and you can get a high success rate
with a very small manually-prepared dictionary of guesses.

> only using base64 strings with numbers in them, and prepending a 1 in
> some cases... this seems like it would shrink the keyspace/randomness
> by at least a few bits. shrug.
I feel you :)
That weird make-sure-there's-a-digit trick makes distribution of 1 as first
character higher than "in nature" (by how much? I hope it doesn't matter).
Why not something like, say, xor-hash-bytes-mod-10?

I've maintained this behavior in order to have an "oplop compatibility
mode", because users are likely to have some legacy passwords (at least
during a transition period).

Let's hope it doesn't get any worse than a shrug :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20121117/d4243e4d/attachment.html>

More information about the cryptography mailing list