I’ve been thinking about the security of RSA lately. RSA’s cryptography relies on the difficulty of factoring a large semiprime number, but what “large” means is an interesting question. The Web PKI deprecated 1024-bit RSA over a decade ago, and while I don’t know of anyone factoring a key of that size, it’s within the realm of possibility for a government or other organization with a large number of computers. Just a few days ago, someone factored the 862-bit RSA-260 key from the RSA factoring challenge. That’s the largest factorization I’m aware of. Today, the world uses RSA of at least 2048 bits, but even that will be deprecated soon with the risk of quantum computers in the future.

This led me to wonder: small RSA keys can be factored on even a modest desktop computer. And in the early days of the Web PKI, there were no standards, and no minimum requirements. Netscape shipped SSL support in 1994, and IE shortly afterwards. This was still the era of export restrictions on cryptography. Are there any keys small enough that I can factor? I don’t have any good reason to do that, but it seems like fun.

The spoiler is of course, yes, but first we need to find a key to crack.

Fortunately, root certificates were shipped with browser installers, and there are archives of both Internet Explorer and Netscape on archive.org. The archives aren’t comprehensive, but they should provide good coverage of old root CAs. I downloaded both collections and set Claude Code on extracting all the roots. I’ve hosted a Claude-generated webpage with all those old-timey, ancient roots. While I haven’t verified this LLM output is entirely trustworthy, it looks pretty plausible.

Using the filters on that site, we can find what small keys are trusted for SSL.

Aha! We have a target. Back in March 1999, Netscape 4.51 shipped a 512-bit RSA certificate authority trusted for SSL, and another for S/MIME. These two roots were both from the long-defunct Canadian certificate authority called E-Certify.

Later that year, the 512-bit RSA-155 was factored, so even in its era this was too weak and probably shouldn’t have shipped in the first place.

The E-Certify 512-bit roots were removed by Netscape in 2002. Unfortunately, Internet Explorer seems to have never shipped any 512-bit roots for SSL, so our fun will be limited to Netscape from a relatively small time frame.

Factoring the public keys in the root certificates will give me the two primes that I need to reconstruct the private key. I ran CADO-NFS on my Ryzen 9 5950X desktop; it took 32 hours to factor E-Certify RSA 512 Gold Server for SSL, and another 29 hours for E-Certify RSA 512 Gold Client for S/MIME. You can get the resulting private keys below.

Assuming you’re somehow running Netscape 4.51 with a clock set before E-Certify roots expired on 2003-10-16, you can use these private keys to issue certificates. This describes zero people on the planet… except for this VM I set up.

Verifying that the issued certificates would work in Netscape 4.51 was an adventure in itself, as there is zero overlap in TLS capability between Netscape 4.51 and any modern TLS stack. So it was back to Claude Code to make a custom old-timey TLS server in Go. This site is publicly hosted at e-certify.fly.dev, which you are welcome to try out with your own copy of Netscape, but it won’t load in any modern browser.

Or, if you’d like to host your own website using these old-timey keys, the keys and tools are all in the repo at https://github.com/mcpherrinm/ancientroots. Or do worse, like MitM the SSL of all those Netscape 4.51 users with their clocks set to 25 years ago…

C=CA, O=E-Certify, OU=RSA Gold Server, CN=E-Certify RSA 512 Gold Server
-----BEGIN CERTIFICATE-----
MIIByjCCAXSgAwIBAgIBATANBgkqhkiG9w0BAQQFADBjMQswCQYDVQQGEwJDQTES
MBAGA1UEChMJRS1DZXJ0aWZ5MRgwFgYDVQQLEw9SU0EgR29sZCBTZXJ2ZXIxJjAk
BgNVBAMTHUUtQ2VydGlmeSBSU0EgNTEyIEdvbGQgU2VydmVyMB4XDTk4MTAxNjEz
Mzc1M1oXDTAzMTAxNjEzMzc1M1owYzELMAkGA1UEBhMCQ0ExEjAQBgNVBAoTCUUt
Q2VydGlmeTEYMBYGA1UECxMPUlNBIEdvbGQgU2VydmVyMSYwJAYDVQQDEx1FLUNl
cnRpZnkgUlNBIDUxMiBHb2xkIFNlcnZlcjBcMA0GCSqGSIb3DQEBAQUAA0sAMEgC
QQDNVQ93Ev7zgNaJAR1Z7gCydU6mky1e/B4EbY1NsdtfsitU9cELqg5uRJDPA40n
CDPeOyil1lJ5N8hekcqJAkkXAgMBAAGjEzARMA8GA1UdEwEB/wQFMAMBAf8wDQYJ
KoZIhvcNAQEEBQADQQB09SV6OeeDEP8Je3DOLNZ24U98NHqIBTDyB4sRpDmNdHum
+3rm4AYtznBxG5hEShO89bcWi3yJtBITGuTRDnMq
-----END CERTIFICATE-----
-----BEGIN RSA PRIVATE KEY-----
MIIBOgIBAAJBAM1VD3cS/vOA1okBHVnuALJ1TqaTLV78HgRtjU2x21+yK1T1wQuq
Dm5EkM8DjScIM947KKXWUnk3yF6RyokCSRcCAwEAAQJAWZ2FOWf+A9K4T2VAJS69
+SU/pW3YwHrysuYJZN56K0Iz+Hqd1hBhCeJ3/T+/cvXq+ctD0x3uOxU1rDSeCoMO
KQIhAPdbc1wTm3twWDYi1iXmRBXz97MYxRFld/KFr8x5+tK9AiEA1IG09a+oVg6j
NMDj6GD7spaD4q9t1wk/Nyq/MTLPkmMCIEzzYjvuzZvlI0wUIlLAA8Zgk1pgBk6X
Jm2IMVyHRgRxAiEAjZKgCTHuVu7HgiSjcTPzW0X1NTckWSc66zjaSR+Ns/sCICxT
yXoTXWQCWL6BMpf2no7IlvoEnBIrED2Frq3PxlEA
-----END RSA PRIVATE KEY-----

C=CA, O=E-Certify, OU=RSA Gold Client, CN=E-Certify RSA 512 Gold Client
-----BEGIN CERTIFICATE-----
MIIByjCCAXSgAwIBAgIBAjANBgkqhkiG9w0BAQQFADBjMQswCQYDVQQGEwJDQTES
MBAGA1UEChMJRS1DZXJ0aWZ5MRgwFgYDVQQLEw9SU0EgR29sZCBDbGllbnQxJjAk
BgNVBAMTHUUtQ2VydGlmeSBSU0EgNTEyIEdvbGQgQ2xpZW50MB4XDTk4MTAxNjEz
MzQwOFoXDTAzMTAxNjEzMzQwOFowYzELMAkGA1UEBhMCQ0ExEjAQBgNVBAoTCUUt
Q2VydGlmeTEYMBYGA1UECxMPUlNBIEdvbGQgQ2xpZW50MSYwJAYDVQQDEx1FLUNl
cnRpZnkgUlNBIDUxMiBHb2xkIENsaWVudDBcMA0GCSqGSIb3DQEBAQUAA0sAMEgC
QQBwCcT1iYlNyKPywB/kffD8esiCzGYJxSnTXQjU6ej/XxnA+9yqjzAMPtqFd094
wM89Vsmz9YOWSO6Qn6wOAs45AgMBAAGjEzARMA8GA1UdEwEB/wQFMAMBAf8wDQYJ
KoZIhvcNAQEEBQADQQAdktdM5AzW+0o96eHCHwD3UfzxPvjKxPEjiI/QTn+njHt/
BEJb9yZatONRckglVc9v8P8Dy8HZGQD0+Pn0uxhW
-----END CERTIFICATE-----
-----BEGIN RSA PRIVATE KEY-----
MIIBOQIBAAJAcAnE9YmJTcij8sAf5H3w/HrIgsxmCcUp010I1Ono/18ZwPvcqo8w
DD7ahXdPeMDPPVbJs/WDlkjukJ+sDgLOOQIDAQABAkASXZeaxFPsm0I8zb+snfR9
/saVolnrqhVEH5EODdXy3nSm6fpdrsDwQDDg52biXjIUizQYdd3OourOn0/PyyiB
AiEAyW4gFFgM0dJ+Y//vrIyQutLeH/5c/Vq3Lbcxv7R908kCIQCOZAAv8OCG/2oH
yKaYj/EoxcFZ9csVh/kjicO/JIX+8QIhAMEzAkvhBDLALYAmvDCJBkxa8rhHFdPf
jbCodGwGZ2WZAiB//XmBnlZkYl/PoVfGmNRgHun+0AZ9UxzqCeJvBQiBMQIgHWlr
0Sh1a8K2pQP2ktgmL3RH5+1Qd2wLx/hhGWtwPvU=
-----END RSA PRIVATE KEY-----

As a bonus, Internet Explorer 3.02 shipped a code signing CA called OU=Test VeriSign Commercial Software Publisher CA. I’m not sure what that’s for, but it’s just as easily factored. There are a few other test-looking 512-bit RSA keys in the ancient roots repo, so you should try factoring some more of them, or seeing what they could be used for!

Steve Weis factored this one in about an hour using a GPU cluster.

L=Internet, O=VeriSign, Inc., OU=Test VeriSign Commercial Software Publisher CA
-----BEGIN CERTIFICATE-----
MIIByDCCAXKgAwIBAgIQIsTi2AgEp+1OkpqVLROnazANBgkqhkiG9w0BAQQFADBl
MREwDwYDVQQHEwhJbnRlcm5ldDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1
BgNVBAsTLlRlc3QgVmVyaVNpZ24gQ29tbWVyY2lhbCBTb2Z0d2FyZSBQdWJsaXNo
ZXIgQ0EwHhcNOTYwNTAyMTcwMTUyWhcNOTcwNTAyMTcwMTUyWjBlMREwDwYDVQQH
EwhJbnRlcm5ldDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLlRl
c3QgVmVyaVNpZ24gQ29tbWVyY2lhbCBTb2Z0d2FyZSBQdWJsaXNoZXIgQ0EwXDAN
BgkqhkiG9w0BAQEFAANLADBIAkEA1XqTpg1hQWq6IKvBXLor12GBTH6y4BHyOJjy
MJISn0ZWBqkbZiEfoWgaWXhEwrvxMWonLA2vYFHijofFG4YIjwIDAQABMA0GCSqG
SIb3DQEBBAUAA0EAKxuR/KPJPDNJgw0ORqqM7SlvIeqnVP71OEFytqPaZw/3TPEi
9oK6PzBvPdLBZlnjRd/hf58FW2+/PXxsFl78Mg==
-----END CERTIFICATE-----
-----BEGIN RSA PRIVATE KEY-----
MIIBOwIBAAJBANV6k6YNYUFquiCrwVy6K9dhgUx+suAR8jiY8jCSEp9GVgapG2Yh
H6FoGll4RMK78TFqJywNr2BR4o6HxRuGCI8CAwEAAQJAYM8tlegLarcToS1CiuKC
bzHwiNgMFkENL01sx0n21/MhmA6pBiSwVn3Pu6yvx6EMB1zbCsaBHs/VTyofMbRW
QQIhAOqdAX3bVZwAlZ5FDWyfGwgE0FXEIQ85kjcihrFeDs49AiEA6PBfC0YuNMSa
M135mH+MEY1GEmQe9xHcXpiYAPazCrsCIQDDtuw6oJEfDYHCwRn8xhGXs+RT18Q4
Xi9yXRP9vFgfhQIhAIYUTfD0XYZcIBIvJosj56D2u328iaJXcow0s1Hirp4fAiAG
bza0Qcc27d/0OzKOqep3JrDl/L5HidTj2XEqEXmnXw==
-----END RSA PRIVATE KEY-----

And finally, SSL Labs thinks my test site is great.

As a Certificate Authority, Let’s Encrypt needs to submit pre-certificates to CT logs to get SCTs for embedding in certificates. This adds an external dependency on our issuance process, which was historically one of the big concerns CAs have had about CT. In this talk, we’ll discuss how we’ve managed that availability risk through the different submission algorithms we’ve used, and what the real world impact CT has had on our certificate issuance process. Looking forward, our new Static CT logs provide different tradeoffs on latency and reliability, which will make the Let’s Encrypt CA more reliable overall, and how operating CT logs helps us keep our CA running.

A talk recording is on Youtube.

Ubiquitous HTTPS is an essential part of a secure and privacy-respecting Internet. To that end, the public benefit certificate authority Let’s Encrypt has been issuing TLS certificates free of cost in a reliable, automated, and trustworthy manner for ten years. In that time, we’ve grown to servicing over 500,000,000 websites.

In this talk we’ll dive into the history of Let’s Encrypt and share helpful context for those managing TLS certificates, as well as information about upcoming changes to Let’s Encrypt and guidance for the future. We’ll also cover how we have strived to make the working lives of SREs around the world easier, and how the SRE community has helped us in return.

Slides and recording are linked on https://www.usenix.org/conference/srecon25americas/presentation/mcpherrin

Let’s Encrypt operates one of the largest Certificate Authorities, along with Certificate Transparency logs. This talk discusses our experiences both as a submitter to CT as well as a log operator. We are excited about the new Sunlight log implementation, and will cover why we think Sunlight will be a good fit for us and for the larger CT ecosystem.

Slides and recording are linked on https://transparency.dev/summit2024/letsencrypt.html

This talk covers the history of the protocols used to communicate web PKI revocation, including CRLs and OCSP, and discusses why they have been ineffective. Then goes over future improvements that are ongoing now to make certificate lifetimes shorter, revive CRLs with new distribution and compression mechanisms. It discusses why new solutions might work where previous attempts like OCSP stapling failed.

The talk was given at the Cryptography and Privacy Village at DEFCON31, and then at BSides Toronto 2023.

The BSides recording is available on youtube and embedded below.

You can find the talk on the Infrastructure Club YouTube Channel and embedded below.

The slide deck is linked here and embedded below.

You can watch the talk on youtube and embedded below.

As well, I previously talked at a 2019 community day.

That talk is also on youtube

You can find that tool and associated code from this post on my github account in the sumcoll repository

Usage

Sum takes file(s) on the command line and prints a checksum value in decimal, along with a count of 1024-byte blocks.

$ echo abcdef > file
$ sum file
33901     1

Backstory

Some years ago I was asked to include the BSD sums of a homework assignment, to verify I had not modified the code after the assignment deadline. The sums of the files were included with a written portion submitted on paper in class, and the code was graded later.

Security

Using a non-cryptographically secure hash for this task is totally insecure, as a malicious student could find another file which has the same checksum as what was submitted on the paper handout. The property needed to prevent that is called Second Preimage Resistance. The malicious student gets to pick m1 before the assignment deadline, and then afterwards, if they can find m2 such that hash(m1) = hash(m2), they can submit m2, a second preimage, without detection. Whether m2 will get them more marks is left as an exercise to the student.

Even with no knowledge of the algorithm used, we can tell it’s not secure. We can observe the output of the sum utility is a 16-bit number (printed in decimal usually), along with a count of how many 1024 byte blocks are in the input. The output being only 16 bits is simply not large enough, and we can use brute force to find collisions: If we sum 2^16 + 1 files, we are guaranteed to find a collision. That’s not quite the 2nd preimage we want, but it’s illustrative of how a small checksum value cannot be cryptographically secure.

The Algorithm

There’s no need to blindly brute-force, as we can examine how sum works and be a bit more intelligent about how we attack it. The algorithm is very simple: Each byte is added into a 16 bit counter, and the counter is rotated right between each addition. Or, in Python:

def rotate_right_16bit(data: int) -> int:
  return (data >> 1) | ((data & 1) << 15)
for byte in data:
    sum = rotate_right_16bit(sum) + byte
    sum = sum & 0xffff # clamp to 16 bits

Going Backwards

From looking at this algorithm, the first thing to notice is that all the operations are reversible: We can subtract and rotate left to go backwards. That lets us add or change characters at any point in the file, and easily work backwards to find out what the intermediate value of the checksum we need to get our final goal value.

def rotate_left_16bit(data: int) -> int:
  return (0xffff & (data << 1)) | (data >> 15)
for byte in reversed(suffix):
  sum = rotate_left_16bit((sum - byte) & 0xffff)

Making Changes

The tool we’re writing is going to insert bytes at a particular offset into the file. We’ll put the extra inserted characters in a comment, string, or some location that can be modified. We’ll compute the sum over a prefix up to the insertion point, and use the backwards sum computation to approach that same point from the opposite direction.

Our task now is to find a set of characters that will, when inserted after the prefix, cause the sum to that point to equal the backwards sum. This is likely brute-forceable, but because we can go backwards, we can do a bit better.

Meet In The Middle

The strategy we’ll take for our tool is going to take advantage of the fact that the set of possible hashes is small, and that we can go backwards.

We’ll alternate extending prefix and suffix strings by an extra character and then checking if the resulting hash is in the opposite set. That is, we add to the end of the prefix and check if we’ve hit any of the suffix hashes, and then prepend to the suffix and check if we’ve hit any of the prefix hashes.

Because of the birthday paradox, and the fact that the set of hashes is only 2^16, the attack takes only a split second on my computer to run.

Character Sets

The code for generating collisions takes a bytestring as input, and will only use bytes from that. This means you can, say, only feed it printable characters, only ascii lowercase characters, or whatever you need to not break the file you’re trying to collide.

Typically that means you want printable characters without newline for many comment “to the end of the line” style comments, or you can avoid / if you are using something like CSS that only does /* */ style comments.

Block Size

Inserting a few bytes could change the number of blocks in the input. You’ll have to figure out what to do about that yourself. Try inserting the new bytes at a different location, or removing some other bytes first.

Conclusion

This isn’t exactly a hardened target, so there’s nothing really novel here, but I haven’t found any documentation of how to accomplish this elsewhere.

I doubt anyone will ever need this, but there is both an implementation of the sum tool and the attack tool here. If you have feedback on that tool or this blog post, feel free to post issues there, or to email me.

The first is that I want to store the website’s content in source control. As a software developer I’m very comfortable with the edit, run, CI and CD flow. I can write in the same editor I always use. I can make local changes offline, test pages, and deploy when ready. Or I can just open github.com and use the in-browser editor. Git is the tool of choice for me, hosted on github.com.

A statically generated website is easy to host anywhere. I’m using Github and Github Pages because it’s convenient and free, but I could easily switch to AWS CodePipeline publishing to S3, or a docker container with Nginx serving the static content.

Thus this setup is not tied to any particular vendor. In a few minutes I could completely abandon Github should the need ever arise. That’s important to me, as I want to be in control over my own content. Leaving a hosted blogging solution would potentially be much more complicated.

So the next question is what static site generator to use. Github pages supports Jekyll, so that makes it a great candidate. I’ve been testing it out and it seems to work well enough. Markdown is easy to write for posts, and the liquid templating system is straightforward. I’m not using too many advanced features, so switching shouldn’t be too hard if I don’t like Jekyll for some reason in the future.

Finally, I have decided to make my own design rather than using a template. I was able to make a basic blog template with no major issues in an evening, which is another reason that Jekyll is working well. I made a base page layout, an index page, and a post one. It’ll probably be pretty ugly, but it’ll be mine.