From danny at dannyvanheumen.nl Fri Oct 4 19:26:41 2024 From: danny at dannyvanheumen.nl (Danny van Heumen) Date: Fri, 04 Oct 2024 23:26:41 +0000 Subject: [OTR-dev] Idea "NoMsg": nostr + OTR Message-ID: Hi, I've been exploring possibilities in recent months, starting from the premise "What would function as suitable messaging infrastructure for OTR sessions?". As OTR was originally designed to build upon (insecure) existing communication networks, this has different requirements than designing a secure messaging system from scratch. I've been aiming for: ubiquitous/widely-available, minimalistic, with low threshold to adoption/use. Assuming OTR's capabilities as starting point, aiming for supplementary functionality in the messaging infrastructure and to preserve the guarantees provided by OTR, such as deniability. (I am not aiming primarily for "perfect secure messaging".) This is a concept based on Nostr-relays and the flexibility of the nostr-protocol. A very early prototype exists at [1], that just barely proves the idea. The repository contains mostly working-notes and code, so I'll attempt to explain the concept here. Note that there was almost zero consideration given to cryptographic primitives and parameters, as I focused on proving the general idea first: to shape Nostr into a minimal messaging layer for OTR. ## Nostr basics Nostr is defined as a protocol with very basic foundation ([2]). Further extensions define specific use-cases that build on this foundation. Some foundational basics of "nostr" ([3], [4]): 1. Public servers ("relays"): - accept events (messages, of various kinds with same basic structure) for publishing when properly signed; - allow arbitrary subscriptions (per client-connection) according to "filters" (one or more properties match); and - forward any published events to connections for any subscriptions that match this event. 2. No "account creation" or "authentication" is required. (Though some relays exist that do.) 3. Messages are signed (authenticated with ECDSA-keypair, p256k1) and the author is represented by their public key (usually Bech32-encoded with prefix "npub"). ## The idea: "construct private channels for any pair of contacts" Nostr starts out with the idea that one identity ("account") is represented by a keypair. The concept I propose abandons that premise. 1. Derive a fixed, predetermined "rendezvous"-channel specific to each contact, derived from our Nostr keypair and contact's Nostr public key. This "rendezvous"-channel is _not_ confidential, and used only to signal new interactions with the contact. For example, post a "request for private chat" with some random bytes to be used in channel derivation. The main requirement for "rendezvous" channels being that the information posted there is not identifiable, does not distinguish between contacts, and is non-actionable without access to the shared secret (shared between a user and their one specific contact). 2. Based on the "chat-request", another (shared) keypair is derived for this private channel, based on the contact-pair's shared secret and other material. A private channel is confidential to mimic a "private communication channel" on public infrastructure, similar to classic instant-messaging networks isolating instant-messages. The confidentiality serves to hide OTR-encoded messages, such as identifying material in the client-profile. Note that this scopes _OTR's deniability_ to the two participants that have access to this private communication channel, though we know that there are *at least* two participants with access by virtue of shared-secret-derivation. Nostr's authentication is not a concern, because both participants share the same keypair. 3. Within the private channel, establish OTR session (without query-message). The chat-request in (1.) can include an indicator for a mechanism, so based on that request one can assume at-least OTRv4. Start OTRv4 DAKE immediately by sending Identity-message. This first message also "creates" the channel as this is the first event posted with the private channel's identity. Once established, send OTR messages as expected in this "private channel" enjoying the security properties of OTR. Some notes: - There is persistence, meaning that this is less secure than merely relaying messages between two on-line parties. - All interactions with Nostr-relays are based on shared keypairs and shared channel ownership. Nostr's authentication works to restrict access to eligible participants, typically the two participants. - Interactions are not linkable without access to the shared secret. - IIUC, OTR's deniability-property is not deminished/degraded, because all Nostr interactions are based on shared, derived keypairs. - There are two kinds of identities: the nostr-identity effectively provides access to your contactlist, while the OTR-identity proves the person. Nostr-identities are discardable without losing access to (personal) identity, though requires reestablishing contacts. - I'm not disregarding the idea that multiple pairs of participants arrive at same rendezvous-channel and/or private channel. A properly constructed symmetric channel-key prevents decryption by other participants, hence private-channel-messages from different participants can be distinguished by their inaccessibility. Some future interactions on "rendezvous"-channels might prove problematic, although "chat-requests" can easily be verified by whether or not the derived private channel exists, as different combinations of keys would derive different private channels from same random bytes. ## Preliminary observations/considerations: - Messaging is based on mutual participation: if one contact no longer checks the rendezvous-channel, then interaction is no longer possible. Conversely, both contacts need to add one-another for this to work. Hence there is the initial problem of having to exchange public keys. - Assuming a trustworthy relay, analysis is possible through observing the presence, occurrence, timing of messages being posted, although shared keypairs imply that one cannot distinguish between participants. It may be possible to fake timestamps if both participants are on-line (i.e. have active subscriptions for channels) as messages would probably be forwarded immediately as "fresh" incoming events. - Assuming an untrustworthy relay, one can observe actions, sequence and timing of posted events, and by the content of subscriptions. For example, if one would use a single subscription for all rendezvous-channels, it reveals a "contactlist" of sorts, although none of it is linkable to persons. By observing connections and subscriptions, one would be able to identify the connections/addresses of two parties. (Tor could help here to hide ip-addresses.) One "rendezvous"-channel is likely already identifying to a large extent, so there may be little benefit in obfuscation by trickery with multiple connections. - Quantum-computing is in part an issue both for Nostr and OTR. - Nostr's risks are somewhat mitigated because Nostr-keypairs are used only for (one-way) derivation of shared keypairs and symmetric secrets. If not shared publicly, then the Nostr keypairs are only exposed to other contacts. "Rendezvous" channels and private channels all rely on one-way-derived keypairs and secrets. Private channel confidentiality relies on a derived symmetric key from nostr-keypairs. - OTR's client-profiles need to be published on-line to satisfy the deniability-property, so these are targets. - I'm not necessarily satisfied with 2 layers of encryption, though -so far- it makes sense from a requirements-perspective, i.e. they perform different functions. - One as-of-yet open question is whether it is possible to *not* store the contact's public key, but instead work with the derived shared secret and public key fingerprint. (I have not yet explored this idea sufficiently.) I'm not necessarily aiming for this idea to be included into nostr-clients per-se. It would work perfectly fine as an independent "private messenger" that operates on nostr-relays. I hope I was able to convey the general idea. I would appreciate any feedback. Regards, Danny [1]: [2]: [3]: [4]: