[Cryptography] Business opportunities in crypto

[Henry Baker]

At 01:41 PM 4/14/2021, Phillip Hallam-Baker wrote:
>On Wed, Apr 14, 2021 at 2:50 PM Christian Huitema <huitema at huitema.net> wrote:
>I have personally done work on that topic, including the implementation 
>of randomized MAC addresses in Windows 10, and the specification of a 
>privacy preserving version of DHCP (RFC 7844). These specifications hide 
>the "fixed" MAC address of the client, but do not hide the address and 
>SSID of the server. There are indeed scenarios in which you want to hide 
>the identity of both parties -- mobile servers, personal area networks, 
>meeting in airport lounges, etc. RFC 8882 provides a list of 
>requirements in these scenarios, but I don't know of any deployed 
>protocol that meets these requirements. Anonymous rendezvous is a vexing 
>problem.
>
>-- Christian Huitema
>
>I have been working on this very problem. and come up with a protocol:
>
>Mathematical Mesh 3.0 Part VI: Reliable Datagram Protocol (ietf.org)
>
>I concur with Christian, Anonymous rendezvous is a vexing problem. And it is not a problem I think worth solving.
>
>If Alice's phone wants to talk to Alice's tablet via a direct, peer to peer connection, this is not a symmetric problem. The interaction MUST be initiated by one device or the other. And that means that the initiating device has to discover what IP address etc the other is currently sitting on. And that is not simple when we consider constraints such as NAT etc.
>
>So the rule I have is that every connection is established by an initiator talking to a responder and the responder has to be permanently available via a static IP address that is either on the same LAN as the initiator or is on the public Internet (i.e. not behind a NAT).
>
>Since neither Alice's phone nor her tablet meet that criteria, we need an intermediary to broker that type of connection. This is a presence problem and both devices need to have a connection to at least one presence service.
>
>For IoT devices that only connect to a LAN owned by Alice, the presence service should probably be on the LAN side of the NAT scope so they still work when the house loses its external Internet connection. For the mobile and tablet, they probably need a presence service on the Internet and a NAT tunnelling strategy.
>
>I have taken a very different approach to maintaining connections to the traditional crypto approach precisely so that I can support these use cases fluently.
>
>* Datagrams can span packets and be up to at least 64KB of data
>* Connections are essentially permanent once created unless one party decides it isn't.
>* AES keys are constant for the lifetime of a stream.
>* I rekey AES for every Datagram
>* The only reason to renegotiate the shared secret is for forward secrecy, this results in a new stream being created.
>* A device can issue a 'connection ticket' consisting of a network endpoint, shared secret and stream ID that is issued to a broker such as a presence service.
>
>This approach allows me to do things like perform a one time 'device binding' to a digital camera and then configure it so that the user just snaps photographs wherever, whenever they are and those image files automatically end up on their home file server (or one in the cloud). The image files are only deleted off the device after it is confirmed that they have been fully and correctly backed up according to the user's specified policy.
>
>Establishing a complete separation between RDP streams and the network endpoints across which they are realized allows for some really interesting and useful approaches.

Once again, for a direct 'wire replacement' wireless point2point connection,
we shouldn't need any of the baggage of broadcasting, DNS, tunneling,
brokering, etc.

Worst-case scenario: manufacture ships you 2 USB wireless dongles that are
'married' to each other for life; i.e., USB dongle #1 can only *ever* talk
to USB dongle #2 and vice versa.

Slightly better scenario: manufacturer ships you 2 USB wireless dongles
that you 'marry' to each other by physically connecting them together in
a 'marriage ceremony' that you should only have to do once. Once 'married',
these 2 dongles only communicate with one another, and are 'invisible' to
other dongles -- even dongles of the same type from the same manufacturer.

Slightly better still scenario: 'marriage', as above, but with the possibility
of a 'factory reset'/'divorce'.

...