[Cryptography] Business opportunities in crypto

[Phillip Hallam-Baker]

On Fri, Apr 16, 2021 at 12:10 PM Kent Borg <kentborg at borg.org> wrote:

> On 4/16/21 7:08 AM, Henry Baker wrote:
>
> Re: In wifi terms it sounds like a temporary SSID that is communicated
> out-of-band.
>
> This is precisely what I'd like to avoid.
>
> If I have a point2point connection within my house, there should be no 'SSID' -- temporary or not -- broadcast that is 'visible' outside the house.
>
> If you are doing this on wifi, assume *something* is receivable outside
> the house. Whether it is visible as an arbitrary SID
> ("orange-couple-sonic", "inside-mustang-iris"…) or is invisible—until some
> sniffer software is updated to display a description of observed
> point2point connections—seems a fine point: Radio signals *will* be
> observable.
>
> Which makes me again wonder what problem is being solved. What are use
> cases? There will be a lot of traffic analysis risks, do you really hope to
> hide that a rendezvous has happened at all? (That's hard.) What do you
> expect to be learnable and what not?
>
I really can't follow these use cases. For me, the only use case of real
interest is Bob wants to use the device he has in his hand to connect to
whatever device Alice has to hand at the moment and the job of the protocol
architect building a presence service to support that use case is to make
that happen no matter what network affordances are involved - WiFi, wired,
whatever.

If Alice and Bob are within WiFi range, and they know each other, why don't
they just talk? The only reason I can see for anything more elaborate is if
we want to actually make use of the WiFi proximity for some post pandemic
orgy hookup protocol only accessible to folk certified as having had their
shots.


Here are the parts (i.e. specs, not code) I can provide today:

Alice and Bob can create pseudo anonymous identifiers not directly
connected to any other identity.
Alice and Bob can both nominate a presence service of their choice.
Alice can initiate communication with Bob (or vice versa) and only the
presence service knows they connected.

I can even route all the traffic over a network so the only observable
external event is that Alice and Bob both changed their communication
pattern at the same time. And we can even mask that if the participants are
willing to endure some lag.

If I wanted more anonymity/traffic analysis protection, I would likely just
introduce an additional blinding layer.

To allow Alice (@alice) to establish anonymous communications with her, she
creates a new id (alice_anon) and requests a connection to @bob which is of
course end to end encrypted and contains a proof that this is really
@alice. So now Bob can contact Alice without the rendezvous service knowing
they are doing this.


I have specified (but not coded) a feature of RUD (formerly RDP) that uses
a stateless ticket approach to blind StreamIds. This is a similar concept
at a different level.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20210416/976229bf/attachment.htm>