[Cryptography] encrypted *broadcasts* ?

[Henry Baker]

-----Original Message-----
From: Henry Baker <hbaker1 at pipeline.com>
Sent: Aug 12, 2025 8:47 AM
To: <cryptography at metzdowd.com>
Subject: encrypted *broadcasts* ?

"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.
https://www.bluetooth.com/auracast/

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.

A traditional method of controlling access has been the *physical ticket*: you get access to the performance if you have an authentic physical ticket.
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.
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) ?
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 ?
This problem is somewhat analogous to the music CD/video DVD problem, since the CD's/DVD's are all identical (aren't they?).
I assume that this digital broadcast problem has already been worked on, so I'm asking for references/links.


Thanks to all for references/links.

What about the following idea for broadcast authorization, which I don't recall being discussed in the references/links suggested ?

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.

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.

Now if there were a *public 1way function* f:authorization-space -> unauthorized union authorized,
where "unauthorized" is a large space of unauthorized tokens and "authorized" is a large space of
authorized tokens, then this function could be used by a legitimate ticket-holder to compute an
authorization token that would decrypt the broadcast, while non-authorized users would have to *guess*
(with negligible probability) an authorization token that belonged to the "authorized" subset.

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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20250817/c4d6fc8f/attachment.htm>