HN
Today

Horible public key tricks

This post unravels a surprisingly clever cryptographic stunt: embedding a secret message directly into an RSA public key while keeping the certificate trusted and functional. The author achieves this by manipulating prime factors p and q and successfully convinces a Certificate Authority to sign it, exposing fascinating nuances in how certificate issuance truly works. It's an ingenious blend of technical prowess and subtle protest, sparking debate on cryptographic rigor and the practicalities of the CA ecosystem.

51
Score
20
Comments
#5
Highest Rank
15h
on Front Page
First Seen
Nov 10, 1:00 AM
Last Seen
Nov 10, 3:00 PM
Rank Over Time
11766598911121316222425

The Lowdown

The author, frustrated by the complexities and perceived fragility of SSL/TLS and its certificate authority (CA) system, embarked on a project to create a "protest certificate." This unique certificate would openly display a manipulated public key, yet remain fully trusted and functional, challenging the assumptions behind CA validation. The goal was to demonstrate how one could embed a custom message within a standard RSA public key.

  • The core idea involves embedding a message into the RSA modulus n, which is the product of two large prime numbers, p and q.
  • Since the public exponent e is usually fixed (e.g., 65537), n provides the "user-controlled" bits for manipulation.
  • The technique starts by generating n from random p and q, then directly modifying bytes within n's base64 representation to insert the desired message.
  • To maintain cryptographic validity, the q value is recalculated as n/p, and then rounded up to the next prime, ensuring the modified n can still be factored.
  • This adjusted p and q pair allows for the creation of a functional private key.
  • The resulting key pair is then used to generate a Certificate Signing Request (CSR), which a standard CA (like Let's Encrypt) is shown to sign successfully via ACME challenges.
  • While acknowledging a reduction in key entropy and potential risks like p and q being too close, the author suggests the key should remain secure enough for public websites due to modern TLS's forward secrecy.
  • The method offers space for approximately 150-320 characters in RSA-2048/4096 keys for embedding messages.

This project ingeniously highlights both the flexibility and potential blind spots within the current SSL/TLS certificate issuance process. It serves as a fascinating technical demonstration of cryptographic manipulation, subtly critiquing the practical checks CAs perform, while still providing a functional, trusted certificate.

The Gossip

Certifiable Complaints and Crypto Context

Commenters engage with the author's initial premise about SSL/TLS complexity and the perceived weaknesses of Certificate Authorities. While some acknowledge the vast improvements brought by services like Let's Encrypt, others echo the sentiment that the system remains overly complex or vulnerable, particularly referencing past incidents like the "4" CA key. A key debate emerges around whether CAs *should* be responsible for detecting intentionally weak or malformed keys, balancing security checks against the sheer volume of certificates issued daily.

Key Concerns and Cryptographic Checks

A significant portion of the discussion revolves around the security implications of intentionally manipulated or weak public keys, especially in light of the infamous "4" CA incident. Commenters debate the extent to which Certificate Authorities should validate the strength and randomness of submitted keys. While some argue that CAs are primarily for identity verification and not for policing user key choices, others believe basic checks for obviously weak or statistically improbable keys are essential to maintain trust in the ecosystem. The concept of zero-knowledge proofs for key randomness is also introduced as a potential solution.

Related Reading and Reader Reactions

This theme covers practical aspects, related technical works, and general reader reactions to the article. Commenters share links to similar "protest SSL" implementations and discuss how modern attacks typically involve traffic diversion rather than passive eavesdropping. There's also some appreciation for the article's style and presentation, with one user offering a UI tip for reading the article.