¶ PVYmessenger | Introduction
Protecting your communications, including who you communicate with and what you discuss, is as important as safeguarding your thoughts. Like your thoughts, communications should remain private and secure, protecting both your privacy and intellectual property. Despite the 2014 Snowden revelations suggesting that digital assets can’t be protected, this is not true. We simply need to use the right tools.
¶ The Concept
To secure communications without requiring a complicated setup involving multiple tools that are too complex for the average person, we need to rethink how such services should function to ensure easy adoption by a wide range of users who value privacy as much as those entrusted with protecting state secrets do.
Centralized messengers like WhatsApp claim to provide true security but fall short. For example, WhatsApp states, “Your chats and calls are private, and thanks to its end-to-end encryption feature, your personal messages and calls remain between you and the people you choose. Even WhatsApp cannot read or listen to these contents.” However, WhatsApp can automatically change the end-to-end encryption keys used by users and resend messages with new keys, allowing it to access your messages.
PVYmessenger offers a decentralized messaging solution. Developed by PVY.swiss, it ensures no middleman can intercept communications, delivering messages directly from device to device without storing them, using the Peer-to-Peer communication protocol.
¶ The Encryption
¶ Overview
Each user has their own encryption key, so the entire communication between sender and receiver is key-based. This means the receiver needs to know the sender’s key and vice versa. To simplify this process, PVYmessenger offers several easy-to-use verification methods to ensure communications are secure and not intercepted.
¶ Megolm algorithm
An AES-based cryptographic ratchet, called Megolm, is used for group communications. Megolm is designed for encrypted messaging applications with a large number of recipients per message, making peer-to-peer encryption systems like Olm impractical.
Megolm also allows recipients to decrypt received messages multiple times. For example, in client/server applications, a copy of the ciphertext can be stored on the (untrusted) server, while the client only needs to store the session keys
¶ Overview
Each participant in a conversation uses their own outbound session for encrypting messages. A session consists of a ratchet and an Ed25519 keypair. Secrecy is provided by the ratchet, which can be wound forwards but not backwards, and is used to derive a distinct message key for each message.
Authenticity is provided via Ed25519 signatures. The value of the ratchet, and the public part of the Ed25519 key, are shared with other participants in the conversation via secure peer-to-peer channels.
Provided that peer-to-peer channel provides authenticity of the messages to the participants and deniability of the messages to third parties, the Megolm session will inherit those properties.
¶ The Algorithm
The Megolm ratchet consists of four parts, for 0,1,2,3. The length of each part depends on the hash function in use (256 bits for this version of Megolm).
The ratchet is initialised with cryptographically-secure random data, and advanced as follows:
where , , , and are different hash functions. In summary: every iterations, is reseeded from . Every iterations,
and
are reseeded from . Every iterations, , and are reseeded from .
The complete ratchet value, , is hashed to generate the keys used to encrypt each message. This scheme allows the ratchet to be advanced an arbitrary amount forwards while needing at most 1020 hash computations. A client can decrypt chat history onwards from the earliest value of the ratchet it is aware of, but cannot decrypt history from before that point without reversing the hash function.
This allows a participant to share its ability to decrypt chat history with another from a point in the conversation onwards by giving a copy of the ratchet at that point in the conversation.
¶ The Megolm protocol
¶ Session setup
Each participant in a conversation generates their own Megolm session. A session consists of three parts:
- a 32 bit counter, .
- an [Ed25519][] keypair, .
- a ratchet, , which consists of four 256-bit values,
for .
The counter is initialised to . A new Ed25519 keypair is generated for . The ratchet is simply initialised with 1024 bits of cryptographically-secure random data.
A single participant may use multiple sessions over the lifetime of a conversation. The public part of is used as an identifier to discriminate between sessions.
¶ Sharing session data
To allow other participants in the conversation to decrypt messages, the session data is formatted as described in Session-sharing format. It is then shared with other participants in the conversation via a secure peer-to-peer channel (such as that provided by [Olm][]).
When the session data is received from other participants, the recipient first checks that the signature matches the public key. They then store their own copy of the counter, ratchet, and public key.
¶ Message encryption
This version of Megolm uses [AES-256][] in [CBC][] mode with [PKCS#7][] padding and [HMAC-SHA-256][] (truncated to 64 bits). The 256 bit AES key, 256 bit HMAC key, and 128 bit AES IV are derived from the megolm ratchet :
where represents string splitting, and refers to the [HMAC-based keyderivation function][] using using [SHA-256][] as the hash function ([HKDF-SHA-256][]) with a salt value of , input key material of , context string , and output keying material length of bytes.
The plain-text is encrypted with AES-256, using the key and the IV to give the cipher-text, .
The ratchet index , and the cipher-text , are then packed into a message as described in Message format. Then the entire message (including the version bytes and all payload bytes) are passed through HMAC-SHA-256. The first 8 bytes of the MAC are appended to the message.
Finally, the authenticated message is signed using the Ed25519 keypair; the 64 byte signature is appended to the message.
The complete signed message, together with the public part of (acting as a session identifier), can then be sent over an insecure channel. The message can then be authenticated and decrypted only by recipients who have received the session data.
¶ Advancing the ratchet
After each message is encrypted, the ratchet is advanced. This is done as described in The Megolm ratchet algorithm, using the following definitions:
where is the HMAC-SHA-256 of T, using A as the key.
For outbound sessions, the updated ratchet and counter are stored in the session.
In order to maintain the ability to decrypt conversation history, inbound sessions should store a copy of their earliest known ratchet value (unless they explicitly want to drop the ability to decrypt that history - see Partial Forward Secrecy. They may also choose to cache calculated ratchet values, but the decision of which ratchet states to cache is left to the application.
¶ Data exchange formats
¶ Session sharing format
This format is used for the initial sharing of a Megolm session with other group participants who need to be able to read messages encrypted by this session.
The session sharing format is as follows:
+---+----+--------+--------+--------+--------+------+-----------+
| V | i | R(i,0) | R(i,1) | R(i,2) | R(i,3) | Kpub | Signature |
+---+----+--------+--------+--------+--------+------+-----------+
0 1 5 37 69 101 133 165 229 bytes
The version byte, V, is "\x02".
This is followed by the ratchet index, , which is encoded as a big-endian 32-bit integer; the ratchet values ; and the public part of the Ed25519 keypair .
The data is then signed using the Ed25519 keypair, and the 64-byte signature is appended.
¶ Session export format
Once the session is initially shared with the group participants, each participant needs to retain a copy of the session if they want to maintain their ability to decrypt messages encrypted with that session.
For forward-secrecy purposes, a participant may choose to store a ratcheted version of the session. But since the ratchet index is covered by the signature, this would invalidate the signature. So we define a similar format, called the session export format, which is identical to the session sharing format except for dropping the signature.
The Megolm session export format is thus as follows:
+---+----+--------+--------+--------+--------+------+
| V | i | R(i,0) | R(i,1) | R(i,2) | R(i,3) | Kpub |
+---+----+--------+--------+--------+--------+------+
0 1 5 37 69 101 133 165 bytes
The version byte, V, is "\x01".
This is followed by the ratchet index, , which is encoded as a big-endian 32-bit integer; the ratchet values ; and the public part of the Ed25519 keypair .
¶ Message format
Megolm messages consist of a one byte version, followed by a variable length payload, a fixed length message authentication code, and a fixed length signature.
+---+------------------------------------+-----------+------------------+
| V | Payload Bytes | MAC Bytes | Signature Bytes |
+---+------------------------------------+-----------+------------------+
0 1 N N+8 N+72 bytes
The version byte, V, is "\x03".
The payload uses a format based on the [Protocol Buffers encoding][]. It consists of the following key-value pairs:
| Name | Tag | Type | Meaning | |||
|---|---|---|---|---|---|---|
| Message-Index | 0x08 | Integer | The index of the ratchet, i Cipher-Text | 0x12 | String | The cipher-text, Xi, of the message. |
Within the payload, integers are encoded using a variable length encoding. Each integer is encoded as a sequence of bytes with the high bit set followed by a byte with the high bit clear. The seven low bits of each byte store the bits of the integer. The least significant bits are stored in the first byte.
Strings are encoded as a variable-length integer followed by the string itself.
Each key-value pair is encoded as a variable-length integer giving the tag,followed by a string or variable-length integer giving the value.
The payload is followed by the MAC. The length of the MAC is determined by the authenticated encryption algorithm being used (8 bytes in this version of the protocol). The MAC protects all of the bytes preceding the MAC.
The length of the signature is determined by the signing algorithm being used (64 bytes in this version of the protocol). The signature covers all of the bytes preceding the signature.
¶ Limitations
¶ Message Replays
A message can be decrypted successfully multiple times. This means that an attacker can re-send a copy of an old message, and the recipient will treat it as a new message.
To mitigate this it is recommended that applications track the ratchet indices they have received and that they reject messages with a ratchet index that they have already decrypted.
¶ Lack of Transcript Consistency
In a group conversation, there is no guarantee that all recipients have received the same messages. For example, if Alice is in a conversation with Bob and Charlie, she could send different messages to Bob and Charlie, or could send some messages to Bob but not Charlie, or vice versa.
Solving this is, in general, a hard problem, particularly in a protocol which does not guarantee in-order message delivery. For now it remains the subject of future research.
¶ Lack of Backward Secrecy
Backward secrecy
(also called ‘future secrecy’ or ‘post-compromise security’) is the property that if current private keys are compromised, an attacker cannot decrypt future messages in a given session. In other words, when looking backwards in time at a compromise which has already happened, current messages are still secret.
By itself, Megolm does not possess this property: once the key to a Megolm session is compromised, the attacker can decrypt any message that was encrypted using a key derived from the compromised or subsequent ratchet
values.
In order to mitigate this, the application should ensure that Megolm sessions are not used indefinitely. Instead it should periodically start a new session, with new keys shared over a secure channel.
¶ Partial Forward Secrecy
Forward secrecy
(also called ‘perfect forward secrecy’) is the property that if the current private keys are compromised, an attacker cannot decrypt past messages in a given session. In other words, when looking forwards in time towards a potential future compromise, current messages will be secret.
In Megolm, each recipient maintains a record of the ratchet value which allows them to decrypt any messages sent in the session after the corresponding point in the conversation. If this value is compromised, an attacker can similarly decrypt past messages which were encrypted by a key derived from the compromised or subsequent ratchet values. This gives ‘partial’ forward secrecy.
To mitigate this issue, the application should offer the user the option to discard historical conversations, by winding forward any stored ratchet values,or discarding sessions altogether.
¶ Dependency on secure channel for key exchange
The design of the Megolm ratchet relies on the availability of a secure peer-to-peer channel for the exchange of session keys. Any vulnerabilities in the underlying channel are likely to be amplified when applied to Megolm session setup.
For example, if the peer-to-peer channel is vulnerable to an unknown key-share attack, the entire Megolm session become similarly vulnerable. For example:
Alice starts a group chat with Eve, and shares the session keys with Eve. Eve uses the unknown key-share attack to forward the session keys to Bob, who believes Alice is starting the session with him. Eve then forwards messages from the Megolm session to Bob, who again believes they are coming from Alice.
Provided the peer-to-peer channel is not vulnerable to this attack, Bob will realise that the key-sharing message was forwarded by Eve, and can treat the Megolm session as a forgery.
A second example: if the peer-to-peer channel is vulnerable to a replay attack, this can be extended to entire Megolm sessions.
¶ Considerations, recommendations & future releases
It is almost impossible for a current session key to be leaked without user error, as peer-to-peer communication requires an attacker to physically compromise a device, control it remotely, and export the key.
For added security, paranoid users can establish a policy to renew sessions on a weekly or bi-monthly basis. This involves canceling verified trusted sessions and re-establishing the session verification process with contacts and channels.
We are considering adding a session timer mechanism to force re-verification of sessions based on a set period, configurable in the app’s security settings menu. However, even without this feature and considering its limitations, PVYmessenger remains one of the most secure messengers in the world.
Additionally, if you use PVYvpn, one of the most secure encrypted VPNs worldwide, it is not just unlikely but impossible for your PVYmessenger encryption key to be leaked during a service/traffic mirror attack, as even quantum decipher tests have failed against it.
¶ As a Private Cloud Service
For convenience and by default, PVYmessenger’s signaling services are provided from our Swiss data center. This allows you to start using the service with your PVY-ID immediately after installing the app on your devices.
Messages are still sent peer-to-peer and are not stored on our data center servers, unlike other popular messaging services such as Telegram, WhatsApp and iMessage.
The signaling service simply handles push notifications and ensures that the sender’s device knows where to deliver the message peer-to-peer to the receiver’s devices. Neither the message content nor the receiver’s name is disclosed on the signaling server.
In fact, we have no idea who is communicating with whom. We also do not use Apple’s Push Network or Google’s Firebase for delivering push notifications. Instead, we use our own CPNs push servers, ensuring that none of the push notifications go over untrusted networks.
¶ Hosted on your PVY@Home / PVY@Office Appliance
Every PVY customer can run essential PVYmessenger services on their own PVY@Home or PVY@Office personal cloud appliance. It is impossible for the system administrator or anyone else to decrypt and read your messages or the encrypted channels you host on the appliance. Even if the appliance is stolen, the thief will not have access to your messages or data.
This does not apply to public, unencrypted channels you host. However, the service deployment is encrypted in containers, so it would take significant effort to crack. You can always push a public, unencrypted channel from your appliance to the PVY.swiss data center.
This is useful, for example, if you start a small hobby channel that becomes popular. By moving it to the PVY.swiss data center, you avoid sharing your internet bandwidth and hardware with the public. Additionally, hosting in an EMF-proof data center with restricted access ensures a high level of security.
¶ The main difference to other popular Matrix driven Messengers
¶ PVY Secure Messaging
Session-less keybased peer-to-peer VPN - no handshake - Quantum hacking proof
Inside P2P Tunnel from Device to Device to Server to Server: Messages, Files, Media encrypted with Megolm 512 bit AES Encryption for PVYmessenger. Between PVYmessenger Services & Components P2P session-less (UDP) VPN.
- Own Firebase Push Server instead of Google Firebase ensures truly private Messaging
- Apple Certified Push Server CPNs operated by PVY.swiss ensures truly private Messaging utilizing a P2P VPN network
¶ Matrix Secure Messaging
Matrix compatible Encryption for: Messages, Files, Media encrypted with Megolm 256 bit AES Encryption compatible with the Matrix Network and popular clients such as Element. Between Matrix/Element services & components only SSL connections used.
We do not diminish the value and achievement of the Matrix protocol and its impressive Megolm algorithm, which has become an open-source standard. Instead, we enhance it with a Zero Configuration Networking (Zeroconf) approach, making the service seamless and running effortlessly in the background for the user.
¶ Noteworthy: Push Messages are encrypted by SSL only and can be cached, decrypted and indexed
¶ Encryption & P2P Functionality
PVYmessenger offers more than twice the encryption and security compared to Matrix-based networks and clients that use P2P. Additionaly, it operates encapsulated within a peer-to-peer VPN, featuring key-based synchronous encryption, where each IP packet receives its own key.
The VPN is secure and not interceptable, as it operates using peer-to-peer communication, with each party responding only if the key is known.
Additionally, each PVY@Home and PVY@Office personal cloud appliance or PVY@Cloud can establish an encrypted peer-to-peer VPN with other known PVY devices to share photos, albums, files, and specific folders directly through an encrypted tunnel. Through PVYcentral, families and organizations can manage their setups and establish a partner network via API with another known PVY-ID. The other party must accept the connection.
For PVYfiles and PVYphotos, the dpham 4096-bit military-grade encryption library can be enabled for syncing over the peer-to-peer VPN within the encapsulation, even with password protection. This ensures secure transfer of highly sensitive data and photos, such as those from your summer holiday, without the risk of third-party access or interception.
¶ F.A.Q.
Q: Can PVY.swiss or a PVY@Home System Administrator decipher or read messages from its users ?
A: No, there is no master key that allows any system administrator to access user communications over encrypted channels.
Q: Can PVY.swiss or a PVY@Home System Administrator see, which users are communicating with each other ?
A: No. The only indicator is that if, for example, three users are online simultaneously, it may be inferred that the other two are likely having a direct conversation. However, this is still just a guess.
Q: When different Home@Appliances or PVY@Cloud own domain driven PVYmessenger Servers are connecting P2P to each other, is this visible ?
A: When you establish a P2P messenger request between appliances, you can choose to make this visible only to the invited user or allow other appliances to discover public channels. If you permit the discovery of public channels by users on a remote appliance, they can browse and request to join these channels. Such requests must be authorized by the channel admin or moderator according to their security settings.
For PVY.swiss, channel information is not visible unless we receive an invite from another PVY@Home appliance or a direct invitation to a Matrix service channel. PVY.swiss cannot see the channel connections between different home appliances or cloud users.
Q: What is the difference between traditional Matrix Clients and PVYmessenger Service ?
A: Zero Config Deployment, out of the Box usable without IT-Skills. Eliminating weak Points, such as the usage of Apple Push Services (SSL only, which can be decoded on the fly from any open source firewall) and running independent Push Servers, which are going P2P encrypted. More than the double of Encryption and additional encapsulation.
Furthermore, PVY.swiss gives PVY@Home or PVY@Cloud Users optional tight integrations with other PVYapps, such as PVYautomator, PVYserviceDesk, PVYdevices, PVYcal and offers like Microsoft Teams Business Telephony integrated with a customers own carrier subscription and PVYpbx Functionality in an Enterprise Scale.
¶ Decentralized with Global, Domain or Local only Federation
¶ The Matrix Protocol
The Matrix Protocol, initially developed for peer-to-peer file sharing without the need for a centralized server, is utilized in PVYmessenger and other PVYapps. Unlike centralized file sharing, where files are uploaded to a server which the other user has to download with their client, the Matrix Protocol allows direct file sharing between users. There are many “Matrix” protocol compatible messenger services on the market and PVYmessenger builds on this protocol for several reasons:
- Utilizing the peer-to-peer concept
- Ensuring compatibility with millions of existing Matrix users who can connect with you using security standards similar to those offered in PVYmessenger
- Supporting the establishment of the Matrix Protocol as a cornerstone for decentralized information exchange
¶ The Peer-to-Peer Mechanism
Do you believe that messenger services relying on cloud systems controlled by major corporations (the MAGAS) are truly secure? Just as we learned that Santa Claus is not real, we must consider that other claims of absolute security might also be false.
Peer-to-peer communication offers the advantage of eliminating the possibility of a backdoor or master decipher key. However, each peer needs to know how to find other peers. Therefore, in a decentralized setup with federation across multiple domains and ownership, a signaling server is necessary.
¶ The underlying P2P VPN with encryption
¶ Encryption Algorithm
¶ Architecture Overview
¶ Why yet another “Secure” Messenger?
because IT matters. Many so-called secure messengers store received messages in plaintext on your local device and keep attachments unencrypted in locations like Users/Library/Application Support/MySuperSecureMessenger.
We define security differently, and our customers know this. With PVYmessenger, we aim to simplify secure communication for families and businesses, making it accessible even to those with minimal technical expertise, such as grandparents.
¶ PVYmessenger Channels
Similar to other popular messengers, like Telegram, PVYmessenger offers channels, which can be Private with Encryption, Private without Encryption, Public with Encryption and Public without Encryption. The difference is, that if you enable Encryption, you have real encryption. Please note, that you have on your Account Security Settings, also the posibility to create a Backup of your Channel Encryption Key.
¶ Encrypted Direct Messages
When communicating from one PVY-ID user to another, you benefit from 512-bit AES encryption for audio and video calls, as well as media and file sharing such as voice messages, pictures, videos, and files. Attachments are sent encrypted and decrypted by the recipient.
When communicating with any external Matrix-ID, you benefit from 256-bit AES encryption for audio and video calls, as well as media and file sharing such as voice messages, pictures, videos, and files. Attachments are sent encrypted and decrypted by the recipient.
¶ Encrypted Channels
Designed for organizational team communication, PVYmessenger allows you to create multiple topic-related channels. These channels can also be used for news and notification aggregation from external sources or other PVYapps. Channels can be published to the domain/owner-specific directory for others to discover and request to join, or they can be kept hidden and accessible only by invitation.
For example, within a team channel, you can integrate ongoing sales data from your eCommerce or ERP system using webhooks to streamline tasks and get things done.
¶ Unencrypted Channels
Intended for community management or using bots that do not support encryption yet, you can create a private unencrypted channel and use the PVYmessenger bot, for example “Telegram” or “Discord”, you can integrate your Telegram or Discord account into one unified messaging system, receiving all your direct messages from Telegram into PVYmessenger.
¶ Current Status
- Telegram Bot: Works only with unencrypted channels as the destination (we are working on a solution).
- Discord Bot: Works with encrypted channels as destination
¶ PVYmessenger Integrations & Bots
Bots are a great way to act as a bridge to the outside world for information aggregation, fun, or community management. The following bots can be invited to either an encrypted private channel or an encrypted public channel with one or more participants:
| Bot Name | Purpose | Encrypted | Unencrypted | |
|---|---|---|---|---|
| Telegram | Bridge your Telegram Channel into PVYmessenger | Soon | Yes | |
| Discord | Bridge your Discord Channel into PVYmessenger | Yes | No | |
| Gitlab | Track your issues, merge requests, and project’s progress with the GitLab bot | Yes | No | |
| Trello | Track and Coordinates your Projects managed with Trello | Yes | No | |
| RSS | Keep your community informed by subscribing to RSS and Atom feeds. Or create your own News Channel | Yes | No | |
| Publish your Newsletter into a PVYmessenger Channel to keep your Audience updated | Yes | No | ||
| Reminders | Simple Textinput to remind you for a upcoming task in certain timeframe | Yes | No | |
| PVYgroupware | Mark a specific Chat Message and convert it to a Task or Calendar Event | Yes | No | |
| PVYbookmarks | Let you automatically collect shared Links on PVYmessenger encrypted Channels | Yes | No |
| Bot Name | Purpose | Encrypted | Unencrypted |
|---|---|---|---|
| Welcome Back | Community Management: Welcome inactive community members back to the conversation | Yes | No |
| Haiku | Unintentionally create short poems from people’s messages | Yes | No |
| Trivia | This bot can, on demand, make polls and keep track of scores for trivia questions. | Yes | No |
| PVYforms | This bot can, on demand, make polls and keep track of scores for PVYforms surveys. | Yes | No |
| Reddit Correction | Ensure your community links to subreddits correctly. | Yes | No |
Webhooks are being supported out of the Box in many PVYapps, such as from PVYautomat, natively, with twisted Slack Webhook Standards. However, we made a Webhooks bot, which you can invite to an Channel.
¶ PVYmessenger Bot Directory
You can find a simple Website with all available Bots, and instructions, under https://bots.pvy.swiss
All Bots are being coming from our own Infrastruture, and are only compatible with PVYmessenger.
¶ Business Voice
Since part of our Software and Network Engineers where involved from 2006 - 2019 into the Development of Carrier-grade Class 4 and Class 5 SIP/PSTN Switches, virtual PBX, Billing and Tier Platforms and made Carrier Solutions including VoIP Applications for Mobile and Desktop, we utilized that broad and deep knowlegde to make PVYpbx. That means, any Organisation can use their current Provider for their Business or Home Telephony not only within PVYmessenger, but also benefiting from one of the best PBX System on the Market. And Encrypted Calls.
¶ Channel Security Settings
Please note that each of your channels has its own security settings. By default, link preview is disabled to prevent revealing your IP address to the website or web app. You can enable link preview for specific channels if desired. If you are highly security-conscious, you can use the web version of PVYmessenger to browse channels with RSS news and link preview, keeping your IP address hidden.
¶ Read the docs
Take me to the PVYmessenger Quick Start Guide