Re: High Latency Offline Conversations

[Daniel Golle]

Hi Cy,

On Sun, Jul 05, 2020 at 09:44:48AM -0700, Cy wrote:
> How high-latency can a gnunet-conversation be? It seems once you do the 
> initial ECDH
> handshake to get a shared secret, you could keep that secret around pretty 
> much forever. I
> was thinking of a UI where conversations were like email exchanges, where you 
> could
> compose it at your leisure, and reply whenever. Is that feasible?

I'm not versed enough in the cryptographic details, hence I leave that
questions for other to answer.

> 
> I know in theory if we both have a shared secret, then if I publish a 
> gnunet-fs://ksk
> record with that secret as the keyword, then you're the only one who can find 
> it, the only
> one who can decrypt it, and we might not even have to be online at the same 
> time because
> intermediate nodes can cache it. But I don't think gnunet-conversation uses 
> ksk records?
> It just sends encrypted data through temporary tunnels that require low 
> latency and
> simultaneous presence online, right?

I think you are confusing conversation with the (early, pre-alpha)
attempts of the secushare folks to build a (group-)chat on top of
GNUnet. conversation implements real-time (ie. RTP-like) duplex
voice-over-IP, ie. "classic" voice-calls using CADET tunnels.

> 
> If so, would it be good to augment gnunet-conversation to use KSK records as 
> a backup to
> synchronize unsent messages, when tunnel establishment fails? Or would it be 
> better to
> have a different "private message" service entirely, that only used 
> gnunet-fs? Can a
> diffie-hellman key exchange be performed over gnunet-fs without some 
> crippling security
> failure?


Independently of that, I like your idea of using KSK records for
offline messaging.
We could add some reliability mechanism in the same way:
In additional to its body, the message could contain a private key
which allows the receiver to publish an ACK which only the original
sender can retrieve. Once the ACK is received by the sender, they could
stop (re-)publishing the message.



Cheers


Daniel