<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, May 30, 2020 at 1:58 AM Paul Wouters <<a href="mailto:paul@cypherpunks.ca">paul@cypherpunks.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, 26 May 2020, other.arkitech via cryptography wrote:<br>
<br>
> 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.<br>
> I wonder why this is not the cypher suite of choice today.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div></div><div class="gmail_default" style="font-size:small"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I haven't looked at the zoom spec. I'm a little sceptical because people<br>
from OTR, Signal and MLS have been working on this problem for a long<br>
time. </blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">They have a particular set of concerns that may be considered 'ideological' wrapped around the axles.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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. </div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Similarly, multicast support in IPsec is another instance of this<br>
problem. It invariable has some kind of binary tree where leaves have<br>
their own symmetric key and if someone leaves, only that lower branch<br>
needs to be given a new crypto key.</blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">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.</div></div><div class="gmail_default" style="font-size:small"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
It's a hard problem. I assume Zoom limits the problem set to "the leader<br>
controls the group memberships", where as for chat protocols like OTR<br>
and Signal, you would need some group agreement before allowing a group<br>
change or someone could sneak in a fake user to get access to the<br>
encrypted group chat.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">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?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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. </div><br></div><div> </div></div></div>