So, other than Dual_EC_DRBG, NIST's cryptography may not be backdoored, but maybe backdoors aren't needed when the standardized cryptography is far from the state of the art and full of holes that weaken too many projects. Maybe the lack of secure-by-design cryptography is a feature for some, not a bug. Or maybe there are legitimate reasons for promoting legacy algorithms, who knows.

The thing is, modern and secureby-design cryptography exists, notably from D. J. Bernstein:

• ChaCha20 for secure and fast encryption
• X25519 for key exchange
• Ed25519 for signatures
• BLAKE3 for hashing, key derivation, and symmetric signatures (MAC) (BLAKE3 is based on a slightly modified core of the ChaCha20 function)
• The Safe Curve list

[Generated by AI]

The paper critically analyzes the security claims made by several widely-used cloud-based password managers that advertise “zero-knowledge encryption”. This is the property where the provider theoretically has no access to users’ plaintext passwords or vault contents.

The researchers assume a fully malicious server — that is, attackers who have complete control over the server infrastructure and can respond arbitrarily to client interactions. This is stronger than traditional models where attackers might only obtain stored encrypted data.

Three major password managers were analyzed: Bitwarden, LastPass, Dashlane. These services account for 10 millions of users (~23% market share).

The paper identifies multiple distinct attacks that break various security guarantees under the malicious-server model:

• 12 attacks against Bitwarden
• 7 against LastPass
• 6 against Dashlane

These range from integrity violations of specific user vaults to complete compromise of all vault data in an organization. Many of the identified attacks can lead to full recovery of stored passwords when the server behaves maliciously — undermining the advertised zero-knowledge guarantees.

The results highlight a broader point: cryptographic assurances depend heavily on threat models — in particular, whether the server can be fully malicious. If real zero-knowledge security under malicious servers is required, current designs may be insufficient.

Takeways:

• Users should be aware that “zero-knowledge encryption” may not be robust in server-compromise scenarios — even if it protects against passive breaches of encrypted data.
• The security of password managers still significantly improves over reusing passwords or storing passwords unencrypted — but the strongest claims require careful interpretation relative to rigorous threat models.

Publié le 17 juillet 1998.

A l'époque, la France limitait le chiffrement avec une clé de 40 bits, là où l'EFF avait cassé un chiffrement 56 bits avec une machine de 250 000$. Donc ce prototype de l'EFF cassait la clé de 40 bits en 3 secondes.

L'auteur recommandait

Bref, il est temps que les gouvernements se décident à autoriser un cryptage un rien plus costaud. Un cryptage à l’aide de clefs de 64 bits est déjà largement plus puissant. Évidement, cela ne résoudra pas le problème de l’état qui veut avoir un oeil sur tout.
Mais sérieusement, est-ce que les criminels en tout genre vont s’amuser à crypter en utilisant des outils légaux ? Non, ces mêmes criminels utilisent des clefs de 1024 bits ou même de 2048 bits (PGP est capable de coder avec une telle puissance et il est très simple à mettre en œuvre)."
Donc, le seul qui est gêné dans l’histoire c’est l’honnête citoyen qui désire simplement éviter que son patron, son provider, une tierce personne aille mettre un nez dans ses affaires

The project: https://github.com/elandio-com/sharemylogin

I like how this project is small, efficient and can be easily adapted to something else.

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

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.