 Swiss government, so that's theirs. And I was working on this as myself. None of this work was sponsored by any of my employers past or present. I had to say that. Oh, sound. Can we do it again? Yeah. OK, there we go. You do it one more time. Sorry about that. When I read the paper, I thought that the title should have been changed into Ron is wrong and Wit is right and the NSA is happy. It was about three years ago. I had a little contest where I asked Arjen if he did a GCD calculation, whether he would find anything. And he bet me if he found one, he would buy me dinner. So what we're going to talk about today is what we collected, what we didn't collect specifically, because there are two teams that did this and we collected different stuff. What was computed? What were the results? We want to discuss it because we focused very much on key generation, not the usage, the key generation, and the conclusions that we came to which we understand is a little controversial. So what we collected was openly accessible public keys that were in repositories. We did not do any sniffing, any crawling. We didn't do any of that because the Swiss don't do that. That's what I was told. And so we used the MIT PGP key server, the EFF SSL repository, and we didn't crawl the net. We ended up with 11.7 million public keys that contain 6.4 million distinct RSA moduli. How many people know how RSA works? Yeah, okay. 3.2 million Al-Gamal keys, 3.2 million DSA keys, and we didn't use SSL, we didn't do SSL, so we don't have the SSL, ECDC, but in the, actually in the MIT PGP database, there is one ECDSA key, only one. And we knew, obviously know about the Debian vulnerability. In the Debian vulnerability, there was a bad random number generator. We kept the factors from all of those keys, but we threw their existence out of the statistics, so those keys were all removed. Now, there are two major results. One was duplicates, the other one was GCDs. The duplicates, in a duplicate where two people, for some reason, share the same private key, also share the same, I'm sorry, two people that share the same public key obviously share the same private key. And in both Al-Gamal and DSA and RSA, we found those. We found a few duplicates with seemingly unrelated owners. You know, you don't know, you really don't know. And in RSA, we found 270,000 keys that share the same modules, duplicates. Now, the vast majority of these duplicates were resigning, where you would sign the same key over and over again, possibly for different purposes, like websites with different names. I'm a little miffed as to why that would be a smart thing to do. The keys that were reused, one of them was reused 16,000 times. That would be a bad day if that key needed to be revoked. And this was hard to do. How do you determine, you get two certificates. You can look at the certificates, they're different owners, but how do you know if they're unrelated or not? These people know each other. We did find one PGP key and we tried to contact the owner of both keys and we contacted one. And that person was not happy because they told us that these keys were not intended to be related and were not related. And we tried to find the software to do that so we could analyze the software ourselves. We were unable to recover the software. So we actually couldn't go any farther. And that was one of the biggest problems is how do you, in a conference like this, you wanna produce a result. Why did this happen? Well, it's gonna take an archeologist to find out why this happened because you can't find the stuff. So what we computed was the GCD of all the moduli, the distinct moduli. We threw out all the duplicates. We counted the duplicates but we didn't allow squares into the tree. Basically, you create a tree where you do a pairwise GCD and if there's nothing in there, if the GCD is one, you multiply the two numbers together and it go up to the next step. If you multiply them together and you recover a prime, how do you know if it's a prime? It's 512 bits long. All the numbers that went in were 1,000 bit keys. If a number that pops out that's 512 bits, it's a prime, it's a factor. You've recovered a factor. Normally, we get these. Sometimes, we got these and a very few times we got composites out of the GCD and when we got the composites out, we just backtracked. It occurred about a hundred times in the entire dataset. It wasn't a big deal. And we used the tools that we used with simple GNU multiprecision arithmetic library. It has low memory requirements and the effort was completely sub quadratic. The final integers, we were very lucky. The other team, Nadia Henninger's team, they went over two to the 32 bytes in length and ran into a software bug, we didn't. And the result for 10 million moduli, the final GCD took two to three hours on a MacBook. So it wasn't a really, no, it wasn't very hard. So let me explain how we did the tree. These A and B, C and D are factors. The GCD of that is one, right? Then we multiply them together and they go up. Notice that A is here, multiply that, the GCD is one, move them up. Now you do the GCD of these two numbers, out pops A. That's a good thing. Multiply it together, removing the extra A, so there's no A squared up here and now you have that number. On this side, you start with, oh, there's a duplicate. So A, B there, A, B there, we just throw it out. Okay, we throw it out of the tree, we count it as a duplicate. And then this is no collision, so it goes up. This is fine, goes up. This is fine, goes up. But now you notice that D, which is there, and E, which is there, and D, which is there, and E, which is there, they made it up into this top and now you get a composite and then you have to backtrack. Not hard. What happens is we take that result and turn it into a graph. The graph is this is a prime, this is a prime, this is a moduli. So P, Q happened once, okay? D and H and D created one public key. D and C created another public key. So the fact is is that because of this, this, the secrecy of this moduli was lost. And this down here was A, B happened twice. So the number on the line represents the number of keys that were found of a particular moduli. So we throw away the things that we can't recover the keys from and they ended up with what we called three clusters. These clusters, three clusters where this is one cluster. Now what I'm gonna explain is three samples of clusters and what happened and why. So we recovered 19,000 moduli. I'm sorry. The factors of 12,000, 13,000 public keys were recovered. And it turns out 5,000 of these public keys used SHA ones and were not expired. They were current keys. And one of the more stranger things, we recovered 10 different factors for 10, 2,000 bit RSA numbers, which was surprised. The early conclusion was there were clearly multiple vendors involved. We'll show you the graphs of three of the vendors and each cluster was the same vendor. There was no situation where two vendors were entangled with each other. And none of these keys were common e-commerce sites. So RSA is a great tool. And there are multiple causes. The first prime, the K9, which I love, and the chain. Let me move on here. So the most common failure, which was one vendor, we contacted the vendor and asked them if they would like some help solving this problem and they never took us up on it. So Nadia and her team actually came up with a very impressive result of probably why it happened. In my mind, 100% probable why it happened. And what happened was they went and got the first prime and then after they accumulated some entry, went and got the second prime. And so this is the case which is 5,321 X509 certificates that only used 4,000 primes, 4,600 primes. So this is the number of the prime in the database. This is the number of the prime in the database. And there was one at this combination, but this combination had 51. And you get the picture. The one that was just wonderful was the K9. 687 keys from nine primes. And nothing coming in and out, right? There isn't, it's not larger. It's been reported that this was IBM. We tried to contact IBM and failed. Nadia contacted IBM and succeeded. And they found it, it's a bug. So, hence the discussion coming up. Chains are really hard. Turns out these are 1,000 bit keys. These are 512 bit keys. So these 1,000 bit keys are fine. And they're valid and all of these wonderful things. This represents, let's say this is Alice and this is Bob. They're happy. They're just, life is great. Everything's going fine. And then this person comes along and ruins everything for both of them. All three of them. Okay, there's nothing you can do about it because you don't know that they're gonna come along and do that. And again, these chains were always one vendor. And they were always chains. They were never, some of these you would have duplicates in the middle here. And I don't know why the duplicates always occurred in the middle. Yeah, it's hard. Okay, I'll let you read that. The problem is randomness as you can never be sure. But bad random number generators always have always happened. This is not the first and this is not the last. This is going to be pretty much, if it's not the crypto community, the crypto community says the proof says the number has random. So if your number's not random, the proof doesn't hold, so go away, right? But in the real world, it's pretty bad. And the security people will be looking at this for a very long time. So basically, this is not the first or the last. And the conclusion out of the paper wasn't that RSA is broken or anything, was that generating keys. That's first. In the real world, where random number generators may or may not be good, and you really don't know, is significantly riskier than single secrets, such as El Gamal DSA, which is based on Diffie Hellman, hence the title. And the title was sensational and I, that's good. Duplicate keys occur in both, and I don't know why, but they do. And, but the fact is, they're only vulnerable to each other. RSA is the only algorithm with a feature that if you, half of your keys collide, both of you have lost your privacy completely to everybody. You're not pairwise vulnerable, you're completely vulnerable. So we came up with, of course, we wanted to, let's fix it, let's put a website up that says, let's do GCD testing. And then we thought we were gonna get in the same situation as with this unfortunate person in Germany that was not really happy. So let's assume Alice creates a key 10 years past. Underneath that key is all of her secrets. Okay, maybe they're time stamps of contracts and all kinds of wonderful things. Bob creates a key, testing detects a collision, and Alice was an innocent bystander. There's nothing you can do for Alice, she's toast. So, we thought about that, and notifying the person that creates the new key, that's easy. Notifying the innocent bystander, that's hard. What happens if they don't exist anymore? Their email address doesn't work anymore, et cetera, et cetera, et cetera. How do you let them know? So we didn't, we decided not to do the GCD testing. Another item that we'd been contacted about other people of doing GCD testing, and we found out that half of the public keys that are signed by a certificate authority are not public. Let me try to, there were too many publics in that sentence. If I get my public key signed certified, I might not put it on a website that's public. I may use it only behind my firewall. I may use this public key privately, and so you don't, you actually, this kind of system where you do all of the GCDs, you don't have all of the public keys, okay? And are you gonna trust giving all of your public keys to someone else so that one central authority has the entire world's public keys? That's a little scary. So, that's the challenge with GCD testing. So, again, discussion. Diffie-Hellman and RSA, duplicate keys are possible. They're detectable with a simple compare, right? Did I share the private keys? Yes, because I share the public keys. Simple compare, simple database, no problem, no calculation necessary, and the consequence is fairly small. It's pair-wise, smaller. If there's a shared factor, this does not happen in Diffie-Hellman. This happens in RSA, and so that's just the fact. But as a practitioner, if any of these three things happen, you should probably go and revoke all the keys ever generated by that random number generator. Now, that's gonna be a bitter pill for anybody, anybody to swallow, okay? So, in conclusion, we collected 11.7 million public keys. Most of them work as advertised, which is the abstract of the paper, recovered tens of, more than 10,000 private keys. Quality random number generators are critical, and the GCD vulnerability is unique for RSA, things like ECDSA are a safe alternative. Thank you.