Hi,
Indeed a formal description of the protocol is much needed.
We currently work on a first draft that you can see here:
https://tuleap.ring.cx/plugins/mediawiki/wiki/ring/index.php/Protocol
We are open to any comment, suggestion or criticism on the protocol itself or
the way it is documented.
About backup/restoration of Ring keys:
It's not formally part of the network protocol, but it's also a important
undocumented feature that we plan to address soon.
Other implementations could use other mechanisms to protect access to
cryptographic material.
On Linux account keys are in
.local/share/ring/{account_id}
inside is:
ring_device.crt : device certificate chain
ring_device.key : private key corresponding to the device certificate public
key
(all standard x509 PEM)
this is enough to place and receive calls if the device certificate is not
revoked.
export.gz : encrypted archive including the account certificate private key
(allowing to sign/revoke device certificates).
this file with the password is enough to "restore" a Ring account (generate a
new device for this account).
the archive is encrypted with AES-GCM-256 using the "Ring account password"
hashed with argon2,
that would indeed need to be documented.
Regards,
Adrien Béraud
Ring project director,
Savoir-faire Linux
De: "Greg Troxel" <[email protected]>
À: "Anthony Léonard" <[email protected]>
Cc: [email protected]
Envoyé: Jeudi 22 Juin 2017 16:11:42
Objet: Re: [Ring] Future of platform-specific clients?
Anthony Léonard <[email protected]> writes:
> Hi,
>
>> It does not clearly give a oprotocol spec.
>
> Writing a protocol spec is a task still to be finished but is
> definitely on the todo list. The protocol is not meant to be a
> “walled garden” ;)
Glad to hear it. I didn't mean to suggest ring was heading to walled
garden - it's clear from the social context that this isn't true. Just
that a protocol spec was missing and needed.
One of the things the protocol spec will help with is discussion of the
security model. I sent an earlier note about a concern with tracking
via the dht.
The other thing that could be discussed is exchange formats for
exporting and importing ring account keys so that people can back them
up and also use the same key on desktop and android, etc.
>> and something RTP/ZRTP-ish to transport the bits.
>
> RTP inside a DTLS channel with Perfect Forward Secrecy encryption and
> peers authenticating each other by their public keys.
I see - so because you have the PK(non-I) already with the peers, you
don't need to play the ZRTP game that would be used to get e2e
confidentiality with regular SIP, and you can just use the peers' keys
and also mix in an ephemeral key to get PFS. That makes total sense.
