In the first part of the blogpost, we tackled the issue of 1v1 conversations, and it is now time to see how this applies to 1vMANY: group chats! We will give an overview of current solutions, and then have a look at the Messaging Layer Security working group.

Today's communications are, as frequently requested by users, more and more secure. In this first part of the blogpost, we will detail some key features of instant messaging applications, in the setting where (only) two parties want to communicate.

This blog post introduces a plugin that provides end-to-end encryption (E2EE) to Mattermost.

Oxen [1] mandated Quarkslab to perform an audit of their instant messaging solution Session [2]. This application, forked from Signal, aims to improve users privacy by using an onion routing mechanism [3]. This mechanism differs from Tor's one by requiring a deposit in their own cryptocurrency to operate a Service Node (Snode [4] ), the Oxen equivalent of a Tor Entry, Relay or Exit Node. While reviewing the architecture of this solution, we found some issues and provided recommendations to improve parts of the implementations.

In recent weeks, Confide, a secure instant messaging application, has gained popularity in some circles. This article presents a quick assessment of the security of this application. The official website boasts the confidentiality provided by the product through three qualifiers: encrypted, ephemeral and screenshot protected. Each of these aspects will be studied.

The encryption protocol will be particularly detailed because it is tagged as battle tested, military grade cryptography. We already knew about military grade cryptography, which seems to be a synonym of put AES-256 somewhere, no matter how you use it in many applications, but we had never heard of battle tested cryptography. This article is an opportunity to present this technology.

Developing properly end-to-end communication systems is complex. As we have seen in the past with iMessage, even if cryptographic primitives are correctly implemented and encryption keys are correctly generated and protected, the design is critical to forbid the service operator from being able to eavesdrop messages.

When appointing computation of private data to a third party, privacy is an issue. How can one delegate computation without giving up one's secrets? This gets trickier when multiple parties are involved. Several works on Multi-Party Computation (MPC) addressed this issue, but a new approach has started to emerge: Fully Homomorphic Encryption (FHE).

In 2014, QuarksLab was missioned by OpenITP [1] to audit the iOS application ChatSecure and to identify any weakness that could lead to information leakage or any other risk that could impact the user.

iMessage is probably one of the most trendy instant messaging systems. Apple presents it as very secure, with high cryptographic standards, including end-to-end encryption preventing even Apple from reading the messages. Is this true?