Update ASAP to Firefox 139

Maybe too much

Press article of https://shaarli.lyokolux.space/#x6SmSw

ENISA is mandated to develop and maintain the European vulnerability database.

All that's required is to create a malicious software package under a hallucinated package name and then upload the bad package to a package registry or index like PyPI or npm for distribution. Thereafter, when an AI code assistant re-hallucinates the co-opted name, the process of installing dependencies and executing the code will run the malware.

Aboukhadijeh explained that _Iain "automated the creation of thousands of typo-squatted packages (many targeting crypto libraries) and even used ChatGPT to generate realistic-sounding variants of real package names at scale. He shared video tutorials walking others through the process, from publishing the packages to executing payloads on infected machines via a GUI. It’s a clear example of how attackers are weaponizing AI to accelerate software supply chain attacks."

Not in France.

3.5 millions fines after a ransomware attack because no security measure was set.

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.

Modern cryptography

Hashing: BLAKE3, Keccak-based functions (SHA-3, SHAKE256) or BLAKE2b.

Encryption: XChaCha20-Poly1305, ChaCah20-BLAKE3, or, I would like to see keccak-based AEAD constructions.

Key Exchange: X25519, X448

Digital Signatures: Ed25519, Ed448

Password Hashing / Key Derivation: Argon2id

Conceptually it's very simple: when you signup for a service, you generate a private and public keypair. The private key is stored in your passkey manager [...], and the public key is stored in the database of the service. Then, during a login, the server sends an randomly-generated challenge, your device sign it wit the private key, and the server verify that the signature of the challenge matches the public key.

An alternative to passwords.

A demo for passkeys

Based on Cloudflare's observed traffic between September - November 2024, 41% of successful logins across websites protected by Cloudflare involve compromised passwords.

How do they know it exactly?

what is your mother's maiden name?

Pick random words or another password and store it in the password manager. It's easier that way.

Due to being random and unique per site, it's far more secure.

Encoding the malware as an array of UUIDs