[OTR-dev] OTR using PAKE and for group chat

Louis Granboulan louis.granboulan.developer at gmail.com
Wed Mar 17 08:24:08 EDT 2010


On 12 March 2010 14:17, Ian Goldberg <ian at cypherpunks.ca> wrote:

> If you don't have long-term public keys, won't you have to authenticate
> *every time* you talk to someone?  OTR+SMP binds your shared knowledge
> to your long-term fingerprint, so that you don't have to do it every
> time.
>

If the PAKE is used to generate a long-term shared secret key that will be
memorized, then you don't need to re-authenticate to the same partner. With
OTR+SMP, you need to memorize your secret key and one public-key per
partner; with this option, you need to memorize one secret key per partner,
which has the slight drawback of needing a larger trusted memory to store
this nformation.

But secret society meetings aren't held in dark rooms, where you can't
> even see who's speaking.  (And even if some crazy ones are, that's not
> the model most people have in mind for "secure chat room"; imagine the
> UI: it would have to show what people are saying, but not who's saying
> it.  I can't imagine that's what people are looking for.)  *Within* the
> private chat room, there's value in being able to have secure and
> authenticated communications.


There are two different things that the autentication can prove: the right
to be a participant to the chat room, or the identity. They need different
trust models.
I would clearly accept that in a private chat room I don't know personally
everyone, and therefore not everyone is issuing authenticated communications
(from my point of view). However, I want that everyone that participate to
the chat room has the right to know what is told in there.
I don't put the emphasis on the authentication of the sender of messages,
but on the authentication of the receiver.

Louis

PS: by the way, thank you for this interesting discussion.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20100317/7b6d6e78/attachment.html>


More information about the OTR-dev mailing list