<div style="color:rgb(0, 0, 0);font-family:'Courier New', Courier, monospace;font-size:10pt"><p style="margin: 0.1rem 0; line-height: 1.0;"> </p>
<p style="margin: 0.1rem 0; line-height: 1.0;"> </p>
</div>
<div class="elnk-inline-message-container" style="border-left: 1px solid #aaa; box-sizing: border-box; padding: 10px 0 10px 15px; margin: 0;">
<p>-----Original Message-----<br>From: Henry Baker <hbaker1@pipeline.com><br>Sent: Aug 12, 2025 8:47 AM<br>To: <cryptography@metzdowd.com><br>Subject: encrypted *broadcasts* ?</p>
<p style="margin: 0.1rem 0; line-height: 1.0;"> </p>
<p>"Auracast" is a new *broadcast* service of Bluetooth LE which allows for low-latency audio to be broadcast to phones/earbuds/speakers/hearing aids in "public" places.</p>
<p><a class="moz-txt-link-freetext" href="https://www.bluetooth.com/auracast/">https://www.bluetooth.com/auracast/</a></p>
<p> </p>
<p>Auracast supports encryption via passwords; I don't know anything about the details of how it works, but it doesn't matter, since I'm more interested in the general problem of encrypting broadcasts rather than the specific choices/recommendations of Auracast.</p>
<p> </p>
<p>A traditional method of controlling access has been the *physical ticket*: you get access to the performance if you have an authentic physical ticket.</p>
<p>Today's physical tickets each have unique ID's, so there has to be a non-broadcast 1-1 synchronization mechanism in order to mediate access to the broadcast, and receive some sort of access token.</p>
<p>But how do you keep someone who's already gotten an access token from re-distributing his token ("replay attack"), or re-broadcasting the material on another channel ("man-in-the-middle" attack) ?</p>
<p>Re-broadcasting should be noticeable due to the longer latency, but if he/she re-encrypts it with another key, how will anyone know that there's an illegal copy of the first broadcast ?</p>
<p>This problem is somewhat analogous to the music CD/video DVD problem, since the CD's/DVD's are all identical (aren't they?).</p>
<p>I assume that this digital broadcast problem has already been worked on, so I'm asking for references/links.</p>
</div>

<p style="margin: 0.1rem 0; line-height: 1.0;"> </p>
<p style="margin: 0.1rem 0; line-height: 1.0;">Thanks to all for references/links.</p>
<p style="margin: 0.1rem 0; line-height: 1.0;"> </p>
<p style="margin: 0.1rem 0; line-height: 1.0;">What about the following idea for broadcast authorization, which I don't recall being discussed in the references/links suggested ?</p>
<p style="margin: 0.1rem 0; line-height: 1.0;"> </p>
<p style="margin: 0.1rem 0; line-height: 1.0;">Suppose that we have a venue with, say, 512 seats.  We could either sell exactly 512 tickets for the venue, or we could have a larger "ticket space" with orders of magnitude more tickets, but with a negligible probability of duplication if we simply chose 512 elements of the "ticket space" at random.</p>
<p style="margin: 0.1rem 0; line-height: 1.0;"> </p>
<p style="margin: 0.1rem 0; line-height: 1.0;">Using a separate 1-1 non-broadcast channel, each legitimate receiver is given an access token from an "access token" space much larger than even the "ticket space", where the probability of any illegitimate receiver can *guess* a legitimate access token is negligible.</p>
<p style="margin: 0.1rem 0; line-height: 1.0;"> </p>
<p style="margin: 0.1rem 0; line-height: 1.0;">Now if there were a *public 1way function* f:authorization-space -> unauthorized union authorized,</p>
<p style="margin: 0.1rem 0; line-height: 1.0;">where "unauthorized" is a large space of unauthorized tokens and "authorized" is a large space of</p>
<p style="margin: 0.1rem 0; line-height: 1.0;">authorized tokens, then this function could be used by a legitimate ticket-holder to compute an</p>
<p style="margin: 0.1rem 0; line-height: 1.0;">authorization token that would decrypt the broadcast, while non-authorized users would have to *guess*</p>
<p style="margin: 0.1rem 0; line-height: 1.0;">(with negligible probability) an authorization token that belonged to the "authorized" subset.</p>
<p style="margin: 0.1rem 0; line-height: 1.0;"> </p>
<p style="margin: 0.1rem 0; line-height: 1.0;">Depending upon how long the venue expects a hacker to take to finally guess/manufacture an authorized token, the venue could periodically force everyone (both legitimate and illegitimate receivers) to re-authorize and gain a new token.  This would force illegitimate receivers to search the entire space once again to guess a new authorized token.</p>
<p style="margin: 0.1rem 0; line-height: 1.0;"> </p>
<p style="margin: 0.1rem 0; line-height: 1.0;"> </p>