[OTR-users] Shared secret authentication?

[Gregory Maxwell]

On Thu, 20 Jan 2005 20:12:19 -0500, Ian Goldberg <ian at cypherpunks.ca> wrote:
> On Thu, Jan 20, 2005 at 07:27:13PM -0500, Ian Goldberg wrote:
> > That's a pretty interesting suggestion.  An easy way would be to
> > calculate SHA-1(dir, sessionid, secret) and exchange those values
> > [once the session is established].  (Use the stretched secret, of
> > course.)
> 
> I just wanted to clarify that this method will authenticate the person
> to whom you're speaking, but not their fingerprint.  If you want to
> authenticate their fingerprint as well, you can either just exchange
> fingerprints in the now-authenticated channel, or include the
> fingerprints in the above hash.

My thought was pretty much exactly that... Except including the
fingerprint in the hash as well so that it's simultaneously
authenticated.   I think passwords are just too easily stolen, they
also present a scaling issue: You need 1 password per potential pair
of communicating users, vs one signature key per user. Users will
likely be silly and reuse the secret or use related words for their
friends, so it's best only this authentication method as infrequently
as possible... And ideally perform it in such a way that an outsider
can't determine when the method is in use, at least without being
intrusive (i.e. by exchanging messages of the same size for every
initiation even when it's not in use).

This way even if the password is potentially weak, users can guard
against a man in the middle by only ever using the password once..  Or
even prearranging a list of words to use in succession.  ... Even
without the extra complexity it should be secure because there
shouldn't be a way to automatically attack it... people will get
suspicious around the 20th attempt to establish an encrypted channel.
:)

It would probably be useful to use the session id as the salt for the
stretching algo, or have each party request a nonce to use from the
other.. (you want something thats per session on the inside of the
expensive algo, so someone doesn't make a huge dictionary of the
expensive part, and reuse that to perform an attack against the normal
SHA1).