<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 Mon, May 4, 2020 at 2:24 AM Whitfield Diffie <<a href="mailto:whitfield.diffie@gmail.com">whitfield.diffie@gmail.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
BW> Unless the algorithm is rot0 or the user is a savant, some<br>
software is being trusted. And I doubt<br>
BW> that even a savant could handle video encryption at frame rate.<br>
<br>
    This is a different sort of objection and surprises me.  It is a<br>
factual question; does somebody have the facts?<br>
<br>
                          Whit<br></blockquote><div><br></div><div class="gmail_default" style="font-size:small">Since I regularly stream HD video over an IPSEC VPN using AES, my hardware can clearly keep up.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">There are issues that probably need to be considered though. If you want the video to look good over a jerky connection, you need to be able to drop frames so you can catch up. Or switch to a different resolution, etc. etc.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So the approach I think we are going to want is not full hard boiled end to end encryption but a sequence of encrypted frames so that the reflector has sufficient metadata to intelligently manage the video but no access to the content. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">And for a full solution, I would want the client to have the option to send a low res stream on a best effort basis and then forward the full HD stream when it can.</div></div></div>