Protocols

Send a message. Pass measurement results. Connect a device. Confirm a command.

Behind each of these actions are rules of interaction: how the parties recognize each other, establish a connection and protect data. Who may read information, change settings or control equipment.

We treat protocols as part of the engineering foundation of RUS OS. We study open standards, encryption mechanisms and communication architectures so that devices can work together with clear boundaries of responsibility.

Communications under our own control.

Matrix has a particular place in our work on communication systems.

An open federated architecture makes it possible to build one's own communications infrastructure and to organize interaction between independent servers. This gives a basis for personal conversation, work spaces and the exchange of events between services.

We study Matrix in the context of different devices and operating conditions: from everyday correspondence to specialized work environments.

The focus is the whole life cycle of communications: joining participants, verifying devices, delivering messages, managing keys, restoring access and ending trust.

The content is available to the parties of the exchange.

With end-to-end encryption, E2EE, the content is protected on the sender's device and decrypted on the recipients' devices. Delivery servers should not receive keys that would let them read the correspondence.

This protection requires attention to every device in the exchange. How do you confirm the other party? What happens when a new phone is connected? How is the backup protected? What do you do if a device is lost?

We look at E2EE together with authentication, key management and the security of the endpoints. Separately we account for metadata: who interacts, when and with whom. Protecting the content by itself does not hide every fact about the exchange.

The cryptographic basis of E2EE in Matrix.

Olm is used for protected pairwise sessions between devices. Megolm provides encryption of group exchange.

What matters to us are their properties and limits in real cases: work with several devices, passing keys, access to history, a change in the set of participants and the consequences of compromise.

We study these mechanisms together with implementations, integration practice and the results of independent analysis. The security of a system depends on how cryptography is built into the application and how it is managed in operation.

Protection that advances with the correspondence.

The Signal protocol family is an important direction in the development of protected communications.

PQXDH is used to establish a shared secret and adds post-quantum protection of confidentiality at that stage.

Double Ratchet updates keys as messages are exchanged. This limits the consequences of exposing individual keys and, under certain conditions, allows the protection of further exchange to be restored after a compromise.

Triple Ratchet joins Double Ratchet with the post-quantum mechanism SPQR. This approach develops the protection of correspondence with the capabilities of future quantum computers in view.

We study these solutions for their properties, their requirements on devices and their applicability in our own architectures.

End-to-end protection for group interaction.

In group communication the set of participants changes. New devices join, people move between teams, access to work spaces ends.

Messaging Layer Security, MLS, standardized in RFC 9420, defines a key agreement mechanism for protected group exchange.

It provides for key updates when the group changes and is designed for participants who work asynchronously. Among its goals are protection of past messages and restoration of the protection of future exchange after compromise, when the conditions of the protocol are met.

For RUS OS this is a line of research into group communications among people, services and devices.

Protected connections.

Applications call servers, devices receive updates, services exchange data. These connections also need protection.

TLS 1.3 provides encryption of the transport channel, integrity control and authentication of the parties according to the chosen configuration.

In our architectural work, certificate checks, management of trust, mutual authentication where it is required, and predictable behavior on connection errors all matter.

Transport protection and E2EE solve different tasks. TLS protects the connection between its endpoints. End-to-end encryption keeps the content protected between the parties of the exchange across intermediate infrastructure.

Protected interaction of devices and networks.

Noise is a family of patterns for building cryptographic protocols. It sets ways of agreeing keys and authenticating for different conditions of interaction.

WireGuard uses a pattern from the Noise family to create protected network tunnels.

We look at these technologies for connecting devices, remote access and interaction between network boundaries.

When designing such access, identification of nodes, storage and rotation of keys, routing, revocation of permissions and behavior when the link is lost all matter.

Protection that accounts for a long life of data.

Some information must stay confidential for many years. When choosing protection it is necessary to account for the possibility that it is stored today for an attempt to decrypt it in the future.

We study post-quantum standards and ways of moving to them:

• ML-KEM, FIPS 203 - a mechanism for establishing a shared secret.
• ML-DSA, FIPS 204 - a digital signature algorithm.
• SLH-DSA, FIPS 205 - a hash-based digital signature algorithm.

A separate direction is hybrid schemes that join classical and post-quantum mechanisms.

For practical use one has to assess key and message sizes, computational load, the quality of implementations and compatibility. The transition has to account for the whole service life of the system, including devices with limited resources.

Trust has to have a life cycle.

A cryptographic key has to be created, protected, bound to its owner and replaced in time. If a device is lost or compromised, trust in it has to end.

We treat key and identity management as a part of the architecture in its own right:

• Registration and verification of participants.
• Connecting and confirming devices.
• Storage, distribution and rotation of keys.
• Backup and restoration of access.
• Revocation of trust and action on compromise.

A person, a service and a device have different roles. Their authority should match their purpose and stay manageable for the whole time they operate.

The link can break. The rules should stay clear.

A device can stay off the network for a long time. A message can arrive again. A command can lose its relevance before it reaches the recipient.

So we pay attention to work under delay, broken connections and restoration of exchange. We think through delivery confirmation, protection against repeat execution, the lifetime of commands and agreement of state.

This matters especially for intelligent systems. Receiving data, proposing an action and carrying it out are different authorities. They have to be separated and checked at the moment of the request.

Choosing a protocol sets the foundation. Then come implementation, integration, trials and support.

For each direction we assess the threat model, the maturity of the available tools, the limits and the cost of operation. We separate research, prototypes and solutions ready for practical use.

Our aim is devices that understand each other, exchange only the necessary data and act within the authority they were given.

So that a person knows whom the system trusts, what it protects and how control is kept.