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
