Data is carelessly collected, stored on insecure servers, shared to countless subcontractors and sold to advertisers. Billions of $ / € and millions of hours are lost every year to the fraud resulting from these data breaches and abuse of trust.

If the past years have taught me something, it is that our digital infrastructure was not designed to withstand attacks from criminals from all around the world, invaders and internal threats aiming for total control and unchallenged power through mass surveillance.

Rust is the best language so far to replace today's most used crypto libraries: OpenSSL, BoringSSL and libsodium.

C libraries often contain a lof of assembly code making them really fast, but potentially unsafe.
pure-Rust libraries benefit from Rust strong typing and generally offer a better API, compile for all platforms including WebAssembly.

It's important to note that pure-Rust libraries might be slightly slower than C and assembly wrappers, but still fast enough for most use cases.

• aws-lc-rs is a cryptograhy create
• libcrux is a Rust wrapper for formally verified C, Assembly and Rust code.
• ring is focused on the implementation, testing, and optimization of a core set of cryptographic operations exposed via an easy-to-use (and hard-to-misuse)
• boring is a safe wrapper around google's boringssl
• dalek-cryptography is a Github organization about pure-Rust elliptic curve cryptography, used by Signal and Diem
• graviola is promising because it's faster than other projects, but not mature enough yet.

There is also blake3

In short, RustCrypto to get pure-Rust implenentations, or aws-lc-rs for linux-servers and best perforamances with FIPS certification.

• ssss dont l'URL du projet n'est plus en ligne mais encore toujours dans Debian
• libgfshare (avec un secret de taille infinie)
• sss garantie l'intégrité du secret, et se veut plus sécurisé
• sssa a plusieurs implémentation, ni récentes ni très utilisés
• splip39 supporte des groupes sur deux niveaux avec une vérification d'intégrité

Je préfère quelque chose de simple, éprouvé, et le fait de pouvoir ajou­ter des nouvelles clés après coup a un énorme avan­tage.

Donc une version de ssss améliorée

All is in the title. There are many misuse of weak encryption showed as examples.

Le chiffrement des mails côté client semble être de plus en plus l'alternative à avoir. ProtonMail en est un exemple. Les métadonnées du mail reste cependant clair.

L'autre alternative est le chiffrement complet côté client. En échange, la recherche des les emails se fait forcément côté client. Tuta est de ce bord. En revanche, ils imposent l'utilisation de leurs outils (POP et IMAP ne fonctionnent pas).

L'email reste une solution peu confidentielle, comme le détaille le modèle de menace décrit dans Ok, je dois utili­ser Tuta alors ?

Source: https://letsencrypt.org/2025/07/01/issuing-our-first-ip-address-certificate/

How Excalidraw handle E2E encryption

[Summary generated by ChatGPT]

The article provides an overview of the JOSE (JSON Object Signing and Encryption) framework, a family of standards for securing JSON-based data and communications. It explains the major JOSE components and how they work together.

Key Components

• JWS (JSON Web Signature): Adds a digital signature to JSON data to ensure integrity (the data wasn't altered) and authenticity (it came from the expected sender). A JWS contains a header, payload, and signature. It does not encrypt the content, so anyone can read it.

• JWE (JSON Web Encryption): Encrypts JSON content to provide confidentiality. The article describes the typical process: generate an encryption key, encrypt the payload, encrypt the key for the recipient, and package everything into a JWE structure containing metadata, encrypted key, initialization vector, ciphertext, and authentication information.

• JWK (JSON Web Key): A standardized JSON representation of cryptographic keys. JWKs can represent RSA, EC, symmetric, and other key types, and include metadata such as key type, algorithm, usage, and key ID. They are used by JWS and JWE for signing, verification, encryption, and decryption. ([Medium][1])

• JWT (JSON Web Token): A compact token format commonly used for authentication and authorization. A JWT consists of:

  1. Header (algorithm and token type)
  2. Payload (claims/data)
  3. Signature (verification data)
     JWTs allow systems to securely transmit user identity and permissions without repeatedly querying a database. The article emphasizes that JWTs should still be used over secure channels such as HTTPS.

• JWA (JSON Web Algorithms): Defines the cryptographic algorithms used by JWS and JWE for signing, encryption, and key management.

Security Goals Addressed by JOSE

The framework is designed to support four common security objectives:

([Medium][1])

JWE vs. HSM

The article briefly compares JWE with Hardware Security Modules (HSMs):

• JWE protects data in transit through encryption.
• HSMs are physical devices that securely store and manage cryptographic keys and perform cryptographic operations.
  They solve different security problems and are often complementary.

Main Takeaways

• Use JWS when you need proof that data has not been modified.
• Use JWE when the data must remain secret.
• Use JWK to exchange and manage cryptographic keys in a standardized format.
• Use JWT to package claims or identity information in a compact, signed (and optionally encrypted) token.
• JOSE provides interoperable, language-agnostic standards that are widely adopted across industries for secure API and application communication.

In one sentence: JOSE is a toolkit of standards that lets developers sign, encrypt, manage keys, and securely transmit JSON-based information in a consistent and interoperable way.

CryptPad is a great tool and I can only be relieved that the United Nations start to use it.

The project runs mainly thanks to research grants. Only 20% comes from donations or suscriptions.

The main selling poitn is it's easy for users to share encryption keys for sharing documents.

The first method — for those without accounts — works like this: When you create a document, a key is generated in your browser and stored locally in your computer or your encrypted drive. When you share this document with a user without a CryptPad account, a URL with a long string after the “#” is sent, containing both the address of the document and the encryption key. What is important is that all content in the URL after the “#” is never transmitted to the server, which means the encryption key stays private.

If you and the person with whom you are sharing both have accounts with CryptPad, you have the additional option to share content using CryptPad’s internal sharing mechanism. This allows sending the document keys in a public-key encrypted box that only designated recipients can open. [...] Also, CryptPad is even more private, because an important feature is that anyone who hosts your data will never have access to the encryption keys.

Another thing to remember is CryptPad will only be as secure as your computer and browser.

Also be careful with browser extensions, because these can snoop in your URLs.

Auprès de Next, elle déclarait en revanche : « la promesse est toujours la même : si vous nous donnez accès à tout, nous pourrons résoudre tous les problèmes du monde. Sauf qu’il n’y a aucune preuve de cela, pas plus que de démonstration que le chiffrement soit le coupable. »

La création d'une porte dérobée aux forces de l'ordre est aussi une porte exploitable un jour ou l'autre par des pirates.

L'ONG Access Now décrit à Wired 3 types d'attaques: la demande par des gouvernements d'obtenir un accès légal aux données chiffrés; la deuxième consiste à analyser les données du côté client; ou alors suspendre l'accès aux services de messageries chiffrées.

Cela dit, des voix importantes s’élèvent aussi en faveur du chiffrement. Aux États-Unis, à la suite de la cyberattaque Salt Typhoon, plusieurs représentants du FBI et de la CISA (US Cybersecurity and Infrastructure Security Agency) ont encouragé la population à largement utiliser des applications de messagerie chiffrées.

(via https://sebsauvage.net/links/?kiLHhA)

Brussels is proposing some form of government-mandated backdoor for communication platforms protected by end-to-end encryption.

Fin de l’article ??? Naaaaan ! Attendez une minute, bande d’impatients ! Car quand on regarde sous le capot, on se rend compte que Google joue “un peu” avec les mots. Ils appellent ça “end-to-end encryption” (E2EE), mais les puristes de la sécurité sont en train d’hurler au scandale (et pas “d’hurler aux sandales”, c’est pas encore les vacances). En réalité, ce qu’a mis en place Google s’appelle du “client-side encryption” (CSE). La différence n’est pas juste sémantique, elle est fondamentale !

Dans un vrai système E2EE comme Signal ou WhatsApp, les clés de chiffrement sont générées et restent uniquement sur les appareils des utilisateurs finaux. Personne d’autre, pas même le fournisseur du service, ne peut déchiffrer les messages. C’est le Saint Graal de la sécurité des communications et c’est bien pour ça que les Etats veulent des backdoor dans tous ces services !

Mais avec le CSE de Google, les clés sont générées ET stockées dans un service cloud de gestion des clés. Les administrateurs peuvent donc y accéder, révoquer des accès, surveiller ce que les utilisateurs chiffrent. Donc c’est un genre de un coffre-fort ultra-sécurisé protégeant vos données les plus sensibles, mais où le mec qui l’a installé a gardé un double de la clé “au cas où”, et pourrait même regarder ce que vous y stockez s’il s’emmerde.

Using both encryption algorithm: one as usual and another quantum resistant.

(via https://sebsauvage.net/links/?1IxNPQ)