The tech, simply put, works like this: When you create an account for a website or app, your device generates a cryptographic public-private key pair. The site or app backend gets a copy of the public key, and your device keeps hold of the private key; that private key stays private to your gear. When you come to login, your device and the backend authentication system interact using their digital keys to prove you are who you say you are, and you get to login. If you don't have the private key or can't prove you have it, you can't login.
PassKeys seem like a bad idea. Google backs them up to the cloud, so if your Google account is compromised then all your private keys are compromised. I don't see how that's an improvement over password+2FA at all.
Now security keys I get; keep the private key on an airgapped device. That's good. Hell I even keep my 2FA-OTP salts on a YubiKey.
Structural security trumps computational security ... or ...
Diffuse structural security trumps amalgamated computational security ...
All your big, strong passkeys in one basket is less secure than your passwords in many individual baskets ...
Trying to explain this to tech bros can resemble pushing a wagon uphill ...
Because they want to sell something, logic is not paramount.
"A password in my brain is generally safer than an app or SMS stream that can be compromised. Although a passphrase may in some cases not be computationally more secure than a token mechanism or two-factor sytem, the simple passphrase is often structurally more secure because that passphrase only links to and exposes one service target."
"I like to compare it to having one basket of eggs in one spot, and many baskets of eggs in many places. If your one basket of eggs has the master key to all the other stronger keys, is it easier to get the one basket, or the many baskets with weaker keys? So in this scenario cipher strength is not the most important factor for security. With a single basket one fox or pick-pocket or one search warrant can own all of your eggs for all your services."
Listening to a #podcast about #cryptography in #golang, and it’s quite interesting. One bonus is that one of the guests has the most Italian accent I’ve ever heard, which makes it fun to listen to him speak.
Everything you need to know about so-called 'Swiss Privacy' we learned decades ago from Operation Thesaurus, AKA, Operation Rubicon. We learned that CIA operations and black budget banking are actually headquartered in the Swiss underground.
If you trust any third-party server to protect your privacy, you're a rube. If you trust Proton Mail to protect your privacy, you're a rube getting 'crossed' by the Swiss Rubi-con. Either you own your keys and your data on your computer or else you have no privacy. Someone else's promise that your data will be 'encrypted' so they can't decipher it is a hollow pledge. If you send any form of plaintext to a remote server, no matter how much they claim to encrypt it, you have zero assurance of data privacy.
if you want to help people access the full, uncensored internet via Tor, and you're a fedi admin, here's a way you can help. you may know about Tor Bridges and how they're used by people behind repressive governments that censor the internet to safely access the net. countries like China or Russia block the public list of Tor relays, for example.
WebTunnel is a Bridge method that uses a reverse proxy that you configure using your existing nginx (etc) web server that points to your server's local tor daemon. so your fedi instance can be a bridge to the Tor network for people who cannot connect to Tor normally. disobey.net is hosting one ^^
one thing to note is that it's important to disable nginx (etc) web server logs, since the people who use bridges are connecting to you as their first, trusted hop onto the tor network. something to keep in mind to maximize privacy and reduce your own liability.
Join us for welcoming returning presenter Sergi Rovira, with Axel Mertens, from Universitat Pompeu Fabra (UPF) and @CosicBe respectively, presenting Convolution-friendly Image Compression in FHE, Apr 25th, 2024 @ 4PM CEST.
Why must the #UX of any kind of #cryptography related tooling on our systems suck so much?
Today's task - manage CA certificates on our clusters' base-systems using #Ansible.
The canonical way on #RHEL systems seems to be, to use #p11kit's "trust" CLI.
"--help" says to use "trust list" - that sounds easy. I'll just compare those certificate serials against my desired state and then import the delta into the trust store…
But: the unique identifier of "trust list"'s output is a PKCS11 URI!
🆕 blog! “Lazy way to cause SHA-256 collisions for lazy evaluators”
Humans are lazy. That's why we have computers; to do the boring work for us. I recently downloaded a file. The website said the file should have a SHA-256 hash of: ca978112ca1bbdcafac231b39a23dc4da786eff8147c4e72b9807785afee48bb So I ran sha256 filename on my machine. And then lazily compared the h…
Nice analysis by Bruno Blanchet that proves that HPKE with ML-KEM (or any other IND-CCA2 KEM) does provide IND-CCA2 security.
“Bruno models the base mode of HPKE, single shot API in CryptoVerif, and showed that if the KEM is IND-CCA2, then so is HPKE.
Since CryptoVerif is PQ-sound, that proves the security of the HPKE base mode, with the single shot API when the KEM is a post-quantum IND-CCA2 KEM.” via Karthikeyan Bhargavan on the CFRG mailing list
The post-quantum transition is causing us to abstract cryptographic protocols over Key Encapsulation Mechanisms as opposed to Diffie-Hellman-like non-interactive key exchanges.
These two papers on the binding models for KEMs are great reads on the gotchas of working with KEMs and the properties they may or may not have.
Swiss authorities intervene, Proton Mail not blocked in India (www.moneycontrol.com)