[messaging] Viola: A simple secure multiparty messaging system

[George Kadianakis]

George Chatzisofroniou <sophron at latthi.com> writes:

> [ text/plain ]
> Hello,
>
> On  Mon, 02 May 2016, George Kadianakis <desnacked at riseup.net> wrote:
>> I'd like to present you a first version of Viola: a secure multiparty messaging
>> system. It has been a side-project for the past month, and I'm glad to finally
>> push it out to the world :)
>
> The idea looks interesting. I like that Viola aims on a secure yet
> practical multiparty "off-the-record" system, something that is
> apparently missing from the current privacy-enabling solutions.
>
>> On the protocol side, if you take a minute and understand the viola spec, you
>> will realize that it's actually a quite simple protocol with great potential
>> for improvements in every step. If you have a viola improvement in mind, I
>> invite you to hack the spec and the code, and actually implement and test the
>> improvement yourself. If you find a great improvement that works, please let me
>> know!
>
> My main concern has to do with the long-term keys that appear to be
> necessary for the authenticated key exchange. If I understood
> correctly, the secure way to exchange these keys is through
> out-of-band means (OTR / AFK) and this looks against the property of
> practicality. This is of course an issue with all group messaging
> protocols.
>

Indeed, exchanging crypto fingerprints is always a terrible UX procedure.

In the future, it might be worth experimenting with re-using OTR identifiers
(as Carlo suggested), or performing Viola introductions using OTR, or doing
some sort of SMP or Pond-like authentication.

> Since Viola introduces the concept of the "room captain", maybe it
> makes sense to make her responsible for authenticating the other peers
> for the very first time using OTR-like ways (question and answer,
> shared secret or manual fingerprint verification). After successful
> mutual authentication, the key exchange process may happen. Note
> though that this will expand the threat model; room captain should be
> an honest user and if she leaves another peer should take her place.
>

Agreed that it might be an acceptable threat model for some groups.

Actually, this is what the current Viola codebase is doing: When Bob tries to
join a room where Alice is the captain, Alice authenticates Bob, Bob
authenticates Alice, and then Bob joins the room. The room participants
Charlie, Dave, etc. don't have a say on Bob joining the room. As long as Bob is
a mutual friend of Alice, Bob will join the room.

That was done because I hacked the Viola code in haste and implementing full
"everyone-authenticates-everyone" authentication was kind of painful (and
involved evena more design decisions), and also because it would make the UX
even more terrible.

Maybe there should be an option for each user: "Stay in room when a non-friend joins?"

If Charlie does not set that option, Charlie would exit the room if Bob joins
the room and they are not friends. Or ideally a better behavior...

---

That said, I feel that this multiparty identity authentication UX disaster is a
general problem with multiparty messaging protocols, regardless of whether they
use the room captain paradigm, or multiparty key exchanges, or pairwise key
exchanges. So finding a solution for Viola should help us in the future with
other protocols as well. 

>> Have fun playing with Viola and please provide feedback!!!
>
> Hopefully more people will join this conversation.
>

Thanks for the feedback! Keep it coming!

PS: FWIW, there is a pending rename of Viola because of its name being
    offensive in various human languages. I will send an email to this list
    with more information when I perform the rename.