Cryptography & Security Newsletter

Feisty Duck’s Cryptography & Security Newsletter is a periodic dispatch bringing you commentary and news surrounding cryptography, security, privacy, SSL/TLS, and PKI. It's designed to keep you informed about the latest developments in this space. Enjoyed every month by more than 50,000 subscribers. Written by Ivan Ristić.

Passwords are ubiquitous, but their best days could be behind us. Their replacement, passkeys, have already been deployed—cautiously—by some of the biggest companies on the planet. Apple, Google, Microsoft, and many others are all in. If you haven’t noticed the changes happening in the last couple of years, that’s probably because most companies are first adopting them as the default authentication method for new accounts.

On the surface, passwords are great. To create an account on a website somewhere, you choose your username and a secret that you only know. Technically, this can be secure. In practice, pretty much everyone picks something simple that’s easy to remember and uses it in a variety of places. This leads to a variety of problems:

• Short passwords can be broken by brute force, by iterating through all possible character combinations.
• Common passwords can be placed in a special dictionary and tried first, for even faster results.
• Via phishing, users can be tricked into entering their passwords in random places under the control of the attacker.
• Historically, most websites didn’t (don’t?) keep passwords safe, leading to billions of passwords leaked on the dark web.
• Password reuse makes all of the above much worse.

Various Band-Aids have been attempted, with limited success. For technical users, password managers and two-factor authentication provide a working solution, but this combination doesn’t scale. It’s also pretty awful to use on a daily basis.

Passkeys solve many of these problems by utilizing public key cryptography, replacing secrets (obscure “words”) with cryptography (“keys”). We remove the human element and generate a private-public key pair with the help of very large random numbers. This leads to important results:

• Unique keys are generated for each website individually. No two users have to have the same key ever again: No more guessing or brute-forcing.
• Only public keys are shared with websites, while private keys remain safe with their users: No more password leakage.
• Authentication is done using a challenge-response mechanism that works only on the website for which the passkey had originally been created: No more phishing.
• As an additional benefit, the use of passkeys has to be approved with user interaction (typically biometrics): Implicit second factor.

At present, passkeys are often promoted as more convenient and easier to use, allowing users to authenticate without triggering the two-factor authentication. This saves them having to respond to a text or email or to use their authenticator application. The UK government, for example, just announced that it will deploy passkeys as an alternative to the current text-based two-factor authentication approach. It’s right to do so. According to Microsoft, users have a 98 percent passkey success rate, versus only 32 percent for passwords. Passkeys, which are usually a fingerprint away, are much faster too.

However, in this model, passwords remain in the background, with all their weaknesses. To reap the security benefits, we need to make a leap and embrace a password-less future. Microsoft is doing just that, with new accounts skipping passwords altogether and existing accounts given an option to delete their existing passwords.

Unfortunately, this is where it gets tricky. As bad as they are, passwords can be remembered or written down, printed, and shared if really necessary. Passkeys can’t do any of these things. Losing access to your devices might mean not being able to recover your key accounts. Passkey cloud synchronization can help, but it’s under control of big, often unaccountable organizations. Tread carefully.

Other News

• Craig Gidney published a new paper, “How to factor 2048 bit RSA integers with less than a million noisy qubits.” This is a 20-times reduction from the estimate the same author made six years ago.
• If you have a freshly minted Qualified Website Authentication Certificate (QWAC) and you’d like to check if it’s correctly understood, there is a handy online QWAC validator on the eIDAS Dashboard website that you can use.
• Keyfactor has two new videos in its KEYMASTER series, one about HSMs and PQC, and the other about short-lived certificates.
• The Internet Security Research Group (ISRG) is branching from certificates into the human digital identity space.
• WhatsApp is developing new AI tools that will send private data to the cloud but are “designed to preserve privacy.” Is that still end-to-end encryption?
• In the conversation about CT logs struggling to cope with the volume of requests, Let’s Encrypt reminded us of its caching proxy, ctile, which ensures that its own CT logs run smoothly.
• The UK’s National Cyber Security Centre (NCSC) published a whitepaper on advanced cryptography.
• TeleMessage, a little-known clone of Signal designed to archive messages, has been hacked. This wouldn’t be notable, except for the fact that this tool is used by the Trump administration. Micah Lee provides additional technical details.
• qtap is a new tool that uses eBPF to capture network traffic before it is encrypted. Other similar tools include beyla and ecapture.
• Tuscolo is a new static CT log deployed by Filippo Valsorda.
• John Young, cofounder of web archive Cryptome, has died. The Register spoke to his friends and peers.
• HAProxy wrote about the state of TLS libraries.
• The people behind Rustls, an up-and-coming TLS library written in—you guessed it—Rust, published their follow-up performance benchmark, showing excellent results under high concurrency.
• A blog post from an Amazon engineer turned up on Hacker News and highlighted how “smart forward proxies” deal with certificate encryption in TLS 1.3. In short, they pause the end user request while they open a separate connection to get the server certificate directly. Cisco Secure Firewall calls this TLS Server Identity Discovery. One of the commenters pointed to a Fortinet article that explains how to block Encrypted Client Hello (ECH).
• The Security Cryptography Whatever podcast has a new episode out, this time on attacks against encrypted storage.
• Google extended its Advanced Protection capabilities to Android 16 devices.
• Let’s Encrypt staff wrote about the company’s plans to remove client authentication capabilities from its certificates.
• Google paid Trail of Bits to audit Go cryptography. The results are good.
• A new RFC is being proposed to extend CAA in order to enforce cryptographically constrained domain validation.
• Microsoft added a variety of post-quantum crypto algorithms to its early adopters channel and detailed its adoption roadmap.