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]: <https://codeberg.org/nomsg/nomsg>
[2]: <https://nips.nostr.com/1>
[3]: <https://nostr.com/>
[4]: <https://github.com/nostr-protocol/nostr>
_______________________________________________
OTR-dev mailing list
[email protected]
http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
