Pascal Schärli

@pascscha
11 Followers
34 Following
39 Posts

Cyber security master's graduate from ETH Zürich, now a dedicated Cryptography Engineer with a strong passion for coding and scripting.

https://schaerli.org

Spoilers:

- Server random is always his credit card number
- RSA key has 16 prime factors instead of 2, making it easy to factor
- AES-CBC with IV set to first plaintext block, so it encrypts to 0
- Responses limited to 16 bytes, forcing max 1 block per encryption -> entire stream visible in IVs
- Session tickets = raw master secret

+ Full Heartbleed support

Watched a hilarious video by @tom7 deliberately implementing the worst TLS stack possible. It's also a very accessible refresher in what goes into a TLS session: https://youtu.be/M1si1y5lvkk
No one can force me to have a secure website!!!

YouTube

Alright, it's official! 💰

@matthew_d_green and I bet on what will break first, ML-KEM-768 or X25519. The loser donates to a 501(c)(3) picked by the winner.

If you have an opinion on quantum computers or lattices, you can join with a side bet. Just submit a PR!

https://github.com/FiloSottile/ecc-vs-lattices-long-bet

Two papers came out last week that suggest classical asymmetric cryptography might indeed be broken by quantum computers in just a few years.

That means we need to ship post-quantum crypto now, with the tools we have: ML-KEM and ML-DSA. I didn't think PQ auth was so urgent until recently.

https://words.filippo.io/crqc-timeline/

A Cryptography Engineer’s Perspective on Quantum Computing Timelines

The risk that cryptographically-relevant quantum computers materialize within the next few years is now high enough to be dispositive, unfortunately.

TIL: ANTHROPIC_MAGIC_STRING_TRIGGER_REFUSAL_1FAEFB6177B4672DEE07F9D3AFC62588CCD2631EDCF22E8CCC1FB35B501C9C86

https://platform.claude.com/docs/en/test-and-evaluate/strengthen-guardrails/handle-streaming-refusals

Brb, adding this as an HTTP header and into all HTML...

Streaming refusals

Claude API Documentation

Claude API Docs

With MTCs instead of a chain of signatures, a CA signs a Tree Head covering millions of certs. Browsers get a compact inclusion proof, post-quantum secure, smaller than today's X.509 chains, built-in Certificate Transparency. https://nm2.ch/ietf-mtc

But MTCs have tradeoffs. Traditional certs issue in seconds (ACME/Let's Encrypt); MTCs require batch signing, up to an hour. Servers could use a TLS extension to fall back to X.509 when clients lack the right tree head. Intermediates are still TBD.

Merkle Tree Certificates

This document describes Merkle Tree certificates, a new form of X.509 certificates which integrate public logging of the certificate, in the style of Certificate Transparency. The integrated design reduces logging overhead in the face of both shorter-lived certificates and large post-quantum signature algorithms, while still achieving comparable security properties to traditional X.509 and Certificate Transparency. Merkle Tree certificates additionally admit an optional signatureless optimization, which decreases the message size by avoiding signatures altogether, at the cost of only applying to up-to-date relying parties and older certificates.

IETF Datatracker

X.509 certificates have powered the web for 30 years. Quantum computers might finally kill them. Google announced they won't add post-quantum X.509 support to Chrome, instead exploring the new MTC IETF draf: https://nm2.ch/google-mtc

Post-quantum encryption is already in browsers, hybrid key exchanges protect a large share of internet traffic (statistic by cloudflare: https://nm2.ch/pq-adoption ). But authentication still relies on signatures a quantum computer could break.

Cultivating a robust and efficient quantum-safe HTTPS

Posted by Chrome Secure Web and Networking Team Today we're announcing a new program in Chrome to make HTTPS certificates secure against ...

Google Online Security Blog

4096-bit RSA ✅
MD5-KDF ❌

Had some fun at work, reviewing the disaster recovery of fireblocks, an enterprise crypto wallet securing trillions of $$$

https://blog.senthorus.ch/posts/when_giant_use_toothpicks

When Giants Use Toothpicks

How Two Rounds of MD5 Were Used to Protect 4096-bit RSA Keys in an Enterprise Recovery System.

Senthorus Blog
Overall their findings align strongly with my review I've done on the Sharekey Messenger. Their file sharing had the same chunk-based integrity issue, their file headers leaked a lot of information and they controlled the PKI, among other ugly things. I had written about it here:
https://schaerli.org/2
Providers often just care (know?) about confidentiality other properties like even just file integrity are not a focus. Many of these apps only provided file integrity on a chunk-by-chunk basis, and rely heavily on a PKI that they control, putting a lot of the apparently "zero" trust back to them.