Happy third anniversaries @Nummer378!
Nice @Nummer378 ; excellent job :
I used the occasion to celebrate with a special certificate:
[Look closely at the PEM]
Yes, this is a real certificate and can be found on crt.sh: https://crt.sh/?id=9436008269
(I've always wanted to do this, so this was good excuse)
Wait a minute. You had that cert issued on Saturday? So you've been planning this for at least a couple days…
Dare I ask what field is being exploited in the cert to make the plaintext in the PEM? That's not the public key, is it? What fields besides SAN, Public Key, and Must-Staple do Let's Encrypt let the subscriber set?
Must be the public key, right?
Some fancy key specified, probably not that random and thus not that safe
Although, the process of going from base64 to an actual prime number..
Yeah, I feel like making a cert like that probably violates the LE Subscriber Agreement in some way, somehow, in principle at least if not in practice.
I wanted to make sure that the certificate showed up on crt.sh, and since it sometimes has a few days backlog I had to issue this one a bit early . I wanted to do something like this since I first saw the technique a few years ago (so this is not original in any way), but I never got to do this.
This is indeed the public key. What you see here is dubbed "RSA vanity key". The public key is engineered to have a predetermined set of bytes, which then encodes to deterministic base64. Essentially, we offset one of the random primes used in RSA to match our "target" public key.
The technique is explained in more detail here: Vanity RSA public key
My source code is here: GitHub - GermanCoding/vanity_rsa: Generate RSA keypairs containing an arbitrary string in the public key.
Even though I'm supposed to now the RSA stuff inside out (I hold a degree in this field...), I've always been bad at math and am more of an applied cryptographer. There are so many edge cases to consider that I'm only medium confident here about the security.
What we do is we take two fully random unbiased primes and then offset one of them. This should be fine as I can't think of a way to create a polynomial equation here, but much like the original author I may have very well missed something. I know that there are certain vanity generation strategies that are exploitable, but I haven't heard of this one being vulnerable. Vanity onion addresses (the old V2, not V3) used in Tor use a related variant of this method, though it involves partial hash collisions which we don't need here.
If anyone is able to factor this key or at least knows of a polynomial algorithm to do so, I would appretiate a writeup that explains the method. The certificate here is not used in production.
Seems not to be. It does not specify how the user should generate the key pair.
Well, it says that you need to request revocation in the case of "actual or suspected misuse or Key Compromise", where "Key Compromise" includes "if methods have been developed that can easily calculate it based on the Public Key or if there is clear evidence that the specific method used to generate the Private Key was flawed."
My prior statement was a bit tongue-in-cheek, that even if it wasn't illegal, maybe it ought to be.
Yeah, I certainly don't know of one, it's just the kind of thing that makes one go really? I did play around with some vanity Bitcoin addresses years ago, but that was along the lines of partial-hash-collision of just trying a bunch of random keys until the corresponding address had the prefix one was looking for. And having a string that long in an RSA public key seemed even weirder.
I got the invitaion:
But I can't find the address:
*** 22.214.171.124 can't find cake-day.nummer378.de: Non-existent domain
Happy 3 years!!!
I really do appreciate all that you do here.
[and all that you've yet to do]
Easier to read than your thesis!! For Sure!
Happy Cake Day @nummer378!
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
Happy Cake Day, Max! Sorry I'm a month late here.