[Cryptography] Zoom publishes draft cryptographic design for end-to-end encryption

[Phillip Hallam-Baker]

On Sat, May 30, 2020 at 1:58 AM Paul Wouters <paul at cypherpunks.ca> wrote:

> On Tue, 26 May 2020, other.arkitech via cryptography wrote:
>
> > I wonder why not using the same secp256k1 used by Bitcoin. It is bullet
> proof as it is publicly able to keep safe billions in capitalization.
> > I wonder why this is not the cypher suite of choice today.
>

Because all the elliptic curves are isomorphic and offer the same security
and we don't particularly rate the choices of the BitCoiners. In case you
hadn't noticed, there are multiple billions of dollars of cryptocurrency
fraud a year. So chosen by that crew isn't exactly much of a recommendation.

The reason we chose the keys we did for the CFRG curves are well documented
and have to do with developments since Hal developed BTC. Things like the
DualECRNG issue. The curves are chosen for speed and to limit the choices
to the point where nobody can accuse anyone of having chosen a curve with a
hidden agenda. If there is a particular reason why 2^255-19 is jiggered, it
is unlikely to just affect that number and it certainly isn't something
that NSA has a leg up on breaking. So if the NSA did promote that curve
because it was weak they would break the NOBUS doctrine.

I haven't looked at the zoom spec. I'm a little sceptical because people
> from OTR, Signal and MLS have been working on this problem for a long
> time.


They have a particular set of concerns that may be considered 'ideological'
wrapped around the axles.

They are obsessed with forward secrecy. Which is nice only for a business
call we often want to archive the call. So forward secrecy is moot.


> Similarly, multicast support in IPsec is another instance of this
> problem. It invariable has some kind of binary tree where leaves have
> their own symmetric key and if someone leaves, only that lower branch
> needs to be given a new crypto key.


I don't see the need for this for typical meeting sizes. If you have less
than 20 people in the call, just have a leader compute rekeys for everyone
every 5 mins. Much less complicated than the tree systems which in my
experience are flaky as heck.

It's a hard problem. I assume Zoom limits the problem set to "the leader
> controls the group memberships", where as for chat protocols like OTR
> and Signal, you would need some group agreement before allowing a group
> change or someone could sneak in a fake user to get access to the
> encrypted group chat.
>

I am not sure what is meant by 'fake user' in this context though. It
really depends on the model of who is trusting whom. If I can get a 'fake
user' into the group, well I am already in, aren't I so can't I just defect
directly?

The real difficulty here is setting up the security requirements and
deciding what you want them to be. And I get really skeptical of models
that claim more than two people are peers.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20200530/9ac12d92/attachment.htm>