Re: https://old.reddit.com/r/crypto/comments/1pca3r8/introducing_constanttime_support_for_llvm_to/nrzywmp/?context=2

It is simultaneously true that:

  • Most data breaches do not require any cryptographic wizardry
  • Of the ones that involve cryptography, side-channels (timing, power, etc.) are not an attacker's first choice
  • The inability to have guarantees that the compiler will not make code variable-time as part of an "optimization" is a massive pain point in writing secure implementations of cryptography

And, sure, the LLVM work won't stop app developers from fucking up something on the OWASP Top 10 list for a given year. Nor will it stop phishing from being hella effective against most users and services.

But it does reduce compiler doom and various forms of auditor bikeshedding, which makes applied cryptography work a little easier to get done.

And the best mitigation we have for phishing attacks today is WebAuthn... which uses cryptography. :P

Sometimes, naysaying is actually counterproductive.

If you're wondering, "Wait, WebAuthn mitigates phishing?" there's a very good explainer about this topic from the same blog that Reddit thread is about:

https://blog.trailofbits.com/2025/05/14/the-cryptography-behind-passkeys/#anti-phishing-protections

The cryptography behind passkeys

This post will examine the cryptography behind passkeys, the guarantees they do or do not give, and interesting cryptographic things you can do with them, such as generating cryptographic keys and storing certificates.

The Trail of Bits Blog

How it works:

In case of https://fake-bank.com instead of https://bank.com (where you have a passkey for):

1️⃣ In your browser you open https://fake-bank.com
2️⃣ Your browser asks your passkey manager: do you have one or more passkeys for https://fake-bank.com?
3️⃣ The passkey manager replies: no

NO ASYMMETRIC CRYPTOGRAPHY RELATED TO PASSKEYS INVOLVED

🚨 When things get complicated (very rare cases)

1️⃣ Phishing mail: check your GMail account at https://sites.google.com/niceguy which you open in your browser
2️⃣ The site asks you to log in using your google account
3️⃣ Since you have a passkey for https://google.com, your passkey manager will sign the request using your passkey's private key. The signed data will include the full domain name: https://sites.google.com
4️⃣ Google is aware of this risk (see https://github.com/w3ctag/design-reviews/issues/97#issuecomment-175766580) which is why it does not let you log in.

🚨 When things get complicated AND FAIL

🔴 A hijacked domain name gets a certificate (this: https://www.bleepingcomputer.com/news/security/defi-exchange-dydx-v3-website-hacked-in-dns-hijack-attack/ won't protect you). This will not prevent a passkey-login (if the fake site acts as AitM).

🔴 Subdomain hijacking where the main domain does NOT check the full DN in the signed data.

@soatok

#passkeys #CryptoBS

@ErikvanStraten @soatok
Soooo.. if the domain is hijacked and set up to appear identical, people's password managers wouldn't know the difference. Same with passkeys. Same with the people manually entering credentials.

That's not a problem with passkeys here, domain hijacking is out of scope.

@cendyne : fuck scope.

People get promised security when using passkeys. Let's Encrypt and other DV CSP's keep issuing certs to fake and plain criminal websites.

The chain is what matters, not your limited view on "scope".

@soatok

@ErikvanStraten @soatok Can you reach in and force DNS to always point to the right actor for everyone, or is that out of scope to you?

@cendyne : DNS (record) and BGP hijacks *DO* happen.

Why are they out of scope for Joe AverageUser?

@soatok

@ErikvanStraten @soatok Because the average user can't do anything about it, nor can their tools.

@cendyne : https certs are in the chain of trust.

If they are issued to the wrong sites, passkeys fail.

Note that I will NOT login to my bank (using a passkey or whatever) if it suddenly has a junk LE DV cert (soon valid for 45 days without OCSP), because I expect a decent certificate.

Why don't passkeys enforce AT LEAST an OV (Organization Validated) certificate?

@soatok

#BigTechisEvil #LetsEncryptIsEvil #GoogleIsEvil

@ErikvanStraten @soatok Not everyone can afford an OV certificate.

Passkeys don't include any certificate info about the origin to the authenticator, just the textual name of the origin. I do think there's some merit in the idea of having some additional bindings for settings where additional properties are included -- like the organization in the certificate.

Though, that won't stop things when it comes to a rogue CA (rare) or a stolen certificate (more common).

@cendyne "Not everyone can afford an OV certificate"

Correct. However, logical domain names (with a somewhat trustworthy TLD) get pricier every day and more importantly, not every website is configured for passkeys.

Furthermore, certificates do not get "stolen". The risk resulting from a private key being stolen is extremely exaggerated. If that happens, typically the *entire website* was compromised. Usually the noise created by THAT is overwhelming.

Secondly, the attacker must somehow influence DNS or be "on the line in between" to be able to pose a risk. This renders most attacks infeasible.

Edited to add: this is not about "rogue" CA's/CSP's. It's about relying on 1FA for certificance issuance, where that single factor is known to be WEAK - because it depends on DNS *and* BGP. And LE even keeps adding weaknessess: https://letsencrypt.org/2025/12/02/from-90-to-45#making-automation-easier-with-a-new-dns-challenge-type.

A certificate originally was intended to prove (blessed by a hopefully reliable third party) who OWNS (actually: currently hires) a domain name.

Most certs issued by LE are for very short lived criminal domain names or for laundrying previously malicious DN's. For example:
hxxps://www.old.hostmaster.ns.www.bubbleshomecarwww.ultracrypto[.]net
(many more can be seen in the RELATIONS tab of https://www.virustotal.com/gui/ip-address/185.149.120.71).

@soatok