[Cryptography] encrypted *broadcasts* ?

[Jon Callas]

> On Aug 17, 2025, at 07:01, Henry Baker <hbaker1 at pipeline.com> wrote:
> 
>  
> 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.
>  

That's pretty much where my thoughts were going. There are lots of things you can do. I was thinking of something similar to 802.1x authentication, and you could use the ticket id to get another token, and use that to auth into the network stream. If you have support in the device, via apps or something, it can be transparent to the user.

One question is how much you care if someone hacks the system. Another is how much you care if a legit customer is denied service.

A thing like an Auracast stream has advantages that it requires the attacker to be physically there, and it's a real-time event sent out only once. In these circumstances, the attacker is pretty constrained. Also interestingly, the cost of a false negative is relatively high -- a paying customer who expected it and paid for it not only gets a refund, but they're going to flame the venue on social media, doing brand damage to both the venue and the technology. 

I would argue that you want to optimize for zero false negatives (customers unhappy), and consider false positives (non-customer getting service) to be a mitigation thing: less is better yet we must have zero false negatives.

I've seen some things that were eye-rolling in the past. Here's a garbled version of the situation. Company A has some service, let's hand wave it as free wifi in many places. Company B has a deal with A, so that their customer can use it. Because Company A's auth was never designed for white labeling, the app B sends to its customers logs into A's infrastructure with the username of "CompanyB" and the password of their customer ID. No checking is done by A, let just let them in, and tell B how much wifi got used. When fraud inevitably shows up they deal with it separately. Like for example, if there's an illegal ID, A lazily figures out it's illegal and then deauths the user. If you find that lots of people are using one customer's ID, change the ID in B's back end, not instantly, but when it's convenient.

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