This is Identity at the Center. If it has anything to do with IAM, this is the GoToPodcast. Now your host, Jim McDonald, and Jeff Steadman. Welcome to the Identity at the Center podcast. I am Jeff and that's Jim. Hey Jim. Hey Jeff, how are you? Oh, not so bad yourself. Good. I've been thinking a lot about, remember how we used to do the YouTube streaming? We did that for a little while. It's still out there. It's still out there. It's on YouTube a little forever. Yeah, exactly.
Well, I feel like one of the things I was thinking about is like, okay, how do I wind up wasting time? Not a bad way. I think I had a friend, Patrick Gibbons, who used to say, everybody's got to waste a little time. And it's kind of profound on a way because it's kind of true. One of my ways is I go down these rabbit holes on YouTube. And if there's all different kind of stuff, there's like these reaction videos, which I would say are more amateurish, but they're still pretty interesting.
I watch a lot of history documentaries, which most of those are like professionally made TV shows, which then end up on YouTube. And then there's kind of the influencer videos. And I was watching one of the influencer videos and the person was at a conference. It wasn't an IAM conference, but gave me an idea like, we could do that. What do you think? Do what exactly? Do you like the video?
Like, kind of like walk through the conference with video cameras, talk to people, give people like a sense of what it was like to be there. Maybe some clips from the different presentations that we sat through. Obviously for podcasting, we could just set up a camera to kind of like shoot it. And then through that on YouTube, there's like a 10, 15 minute video of like, hey, here was Octane or Identiverse in the year 2023. Yeah, it would be interesting.
Sounds to me like you're giving me more work to do. Additing and more equipment to buy and things like that. And we could do it like an iPhone maybe. We can put the iPhone cameras to test and video and stuff like that. iPhone cameras are pretty good. Yeah, I'm sure it'll be good enough for that kind of thing. It's an interesting idea. Let's talk about it and figure out how we can, I don't know, people who want to see that. I feel like we did that live streaming for a while. I liked doing it.
It was actually easier for me once I had it all set up and running because I felt like, hey, it was streamed and here's what happened. No takebacks. It's if you were there, you can see it. If you watch the replays, that sort of thing, there really wasn't any editing going on when you do live stream. It's pretty much, or it's an all or whatever happened is there.
Obviously when we do audio podcasts, we try to keep it less meandering as we can, but also trying to put a little bit of polish on it just to make sure that the product is good. I think it would be interesting to do like a person on the street type thing where you've got a microphone, you're kind of interviewing people. We see that all the time that most conferences go to, there's usually some crew that does that. Mike conflict with that might not, but I'm game.
I don't know if people are interested in seeing that on a YouTube channel, but there would be literally two to three of them per year that we could do. Right. That's all it would be, but that was kind of why I brought the question up here in this forum was, you know, I wasn't sure how you're going to think about it, but hey, our listeners can now provide feedback.
Maybe I'll put a pull out there on LinkedIn or some kind of message and see if we can get some comments of people who think it's a good idea. So look for that. All right. I'm curious to see what comes out of that. Speaking of conferences, we got a whole bunch of stuff coming up that you and I are going to be at together separately and everything in between. We're going coast to coast.
I'm going to be at the Cybersecurity Midwest Summit 2023 since Cincinnati, Ohio on September 14th, something put on by Comspark and CDO Magazine. I'm going to be part of a panel there talking about identity and access management. So if you're in the Cincinnati area, come on by. It's at a Marriott property, I think, some are in that area.
So we'll have a good old conversation as part of like a whole day of a different Cybersecurity sort of conversations then in October, which is going to be a very busy month for you and I. I'm going to identity week America. That's October 3rd and 4th in Washington, DC. I'm going to be hosting a panel discussion on past keys, starting to line up who's going to be part of that panel.
I think of kind of tease folks like Andrew Schickiar, maybe folks like Tom Schuffield over at Target, maybe others that we can pull in to kind of talk about that. And we've actually got a discount code for our listeners, if you use the code IDAC30, that gets you 30% off of your conference pass, which is very cool. That code works for both the identity week America and the identity week Asia conferences.
So if you are on the other side of the world, literally for Jim and I, they have a conference out there in Asia as well. You can use that same code for 30% off. We'll have a link in the show notes for that kind of information. All I am in identity week America that week in Washington, DC, October 3rd and 4th, Jim, you're going to be at Octane, right? I'll be at Octane. All the details aren't nailed down, but we do have a discount code for 30% off on your registration. It's OK. TN IDAC30.
And then later in the month, you and I will be at the authentic conference. It will be on the stage as part of the keynote, which is pretty something I'm pretty stoked about. And then on day two, we're going to have a room with seating for a live studio audience. And we're going to have six guests. We'll do a preview show right before that conference kicks off. So everybody will know, OK, here's the different guests that we're planning on talking to.
And yeah, I'm really looking forward to that one. Yeah, that's going to be kind of cool. I'm interested how we pulled this keynote together and kind of pull off this idea of a live streamed in front of a live studio and internet audience show as part of the keynote. And we have a discount code for that as well. IDAC15 podcast. You get 15% off. So come see us out at Authenticate. That's October 16 to 18th. It's in Carlsbad, California.
Picture-Hesk, little golf course, resorts, the beaches nearby. It's a little bit north of San Diego. So it means the weather should be fantastic. And that'll be a good time. So hopefully people come out and attend our keynote and the rest of the conference. And then hopefully we can fill a chair or two as we're watching as you watch us kind of put together our shows on site. Jim, what are we going to talk about today?
Because this was kind of a, I see this almost as like a two-parter from a topic perspective. Or can I kind of set the ground level and then we're going to follow up this episode with another conversation in the future. But where are we going today? Right. So today's episode is Cryptography 101. The following episode is going to be around quantum computing and how it's going to affect the future. And I think the basis for that is cryptography. Well, I've been in this space for over 20 years.
I've been in IT for even longer than that. And cryptography has kind of been one of these things that have been afraid to dive into. I'm not afraid to dive into much, right? Like I learned TCP-IP on my own. And that's a bit of a math problem. But when I started to look at cryptography back in the day, you know, it was something that was a bit intimidating. Funny thing is going back to the YouTube conversation, I've tried to watch several YouTube videos on cryptography.
And the people talk so fast and I kind of feel like, okay, I learn two or three bits that I'm going to forget here pretty soon. And so I said, all right, well, let's have an episode, like cryptography 101 for IEM practitioners. And I put a post out there on LinkedIn and our friend and our guest today, Andrew, volunteered to come on in. He said, I can explain cryptography at a fifth grade level. And I can go into deep into the pool, which happens to be 30,000 leagues deep.
The deep end of this pool. We don't want to go all the way that deep. But he was the only one who even volunteered. So I was like, all right, you win, man. So it's going to be very brave. Very brave, very brave. Yeah, so let's go ahead and introduce our guest instructor for the day. We're going to kind of go to school. He is Dr. Andrew Stern. He's the founder and CEO at Revive Labs. Welcome to Identity Posthinner Andrew. Yeah, thanks so much for having me.
Yeah, so Brave Man jumping into the fire here, cryptography can be pretty deep. It's a lot of math, as I understand it, definitely not my strong suit. So I'm going to be learning here alongside everyone else. The idea here is to kind of come up with the base level of cryptography, kind of the 101 for, especially for IEM people. And then what happens when quantum comes along and wrecks everything. But before we get to that, we were kind of talking before.
We hit the record button here and I asked you questions like, well, how did you feel like you're an identity and or, you know, cryptography or maybe a little bit of both. But how did you get into identity and cryptography? Yeah, so it's a bit of a weird story. So I did finish a PhD and zero trust cybersecurity about two years ago. And after that, I started a company Revive Labs, which during that time, the crypto currency craze was actually going pretty hard.
So I kind of fell in love with the idea of a passwordless authentication system that really had no fallback of, you know, these really weak things that people need to remember and store and all this garbage. So for me, I really dove deep into how those credentials were managed and how people actually could recover those things in case of massive failure.
So it's interesting that you say passwordless without anything to fall back onto because I think this is a key differentiation for a lot of passwordless products. You've got passwordless and you've got password dashless.
The difference between they think I too sometimes gets lost in translation where one of them doesn't actually have a password in the equation, whereas the other one does, but maybe it's obfuscated or hidden by other mechanisms, like biometrics or other things, there's still something back there that's kind of a fallback. It's interesting to kind of bring that up. I also want to ask you a little bit about your doctorate.
So it's very rare that someone as smart as yourself is willing to come on on our show. So talk to us about your doctorate degree. What was that process like? You know, first of all, what's it in? And just walk us through for people who aren't familiar with what it takes to get a doctorate. Absolutely. I'll just start by saying it takes a little bit of stupidity to do a doctorate. Just to throw that out there, don't be scared of doing it.
Just be scared of the actual ramifications of spending five to seven years of your life on it. But other than that, I got it in electrical and computer engineering, so not specifically computer science.
But I specifically worked in hardware-based cybersecurity, which means going down to the silicon level, the chips that actually operate every device in the planet, figuring out how these keys are stored, how you can actually extract them out, how you can use the implementation of some of the cryptography that we're going to talk about today to extract secrets in ways that the algorithms are secure against. So it's a pretty cool field.
Going into a little bit about how that process works, I think it's important to know for people that haven't done a PhD or haven't looked into it. Doing a PhD is often free in two-ish in perspective. So if you just do a master's, you might have to pay extra money to do that extra year or two. But if you go all into the PhD, you often do a research assistantship or a teaching assistantship along with that.
So there's coursework, but the main point of all of this is just to do the baseline research that pushes humanity's knowledge forward. That's kind of the goal. That's pretty cool. Speaking of, I don't know, maybe research, but I was looking at your LinkedIn profile and there's a reference of being a part of activates DARPA and being an activate DARPA fellow.
For people who aren't familiar with DARPA, that's, I assume, the US Defense Advanced Research Projects Agency, kind of where Tony Stark and others might be creating all the cool stuff that might be out there. Can you talk a little bit about what is, first of all, what does activate and then what does it mean to be an activate DARPA fellow? What is it? Yeah, so it'll probably be helpful to start with activate.
There are actually a nonprofit organization that helps PhD level scientists start companies because one of the biggest problems that they saw were PhDs coming out, getting swept up by Intel, Google, Apple, all these big companies, and effectively their research was dead on arrival. The only person in the world who knew how to push this research forward has now been acquired by these companies who really don't want that to get out, normally to pay a lot of money for it.
It's actually a two-year program. Mine specifically was funded by DARPA. They have others that are funded within the Clean Tech sector by the Bill and the London Gates Foundation or NSF actually just put out a massive award for them as well to support this initiative. It's really an honor to be a part of this super selective group of individuals that are trying to do crazy stuff to help the world. Sounds like a bunch of geniuses figuring stuff out, which is kind of cool.
Now you founded a company called Revive Labs. What is that? Yeah, so Revive Labs, our goal is to get rid of the phone number as the baseline fallback for everything in your life. If you can imagine fishing attacks are very much a day-to-day occurrence within the identity space. We are working to make a cryptographically secure back-end that credential managers and other passwordless focus systems can help to get these keys back in case of failure.
Like I said, we originally started out in the cryptocurrency space where there was I think $4 billion lost last year and there's something like 20 plus percent of the total Bitcoin supplies just gone forever because people just can't access anymore. That's a very real reality that's starting to come up in other situations. Andrew, I thought we could maybe start with a bit of a history lesson.
I mentioned I was watching these history documentaries, I was watching one on the Enigma, which is a cipher and I thought it would be an interesting context to get into cryptography and the need, the way it was in the past and how that's transitioned to where we are today in the world of computing. Yeah, absolutely. Enigma was obviously a very substantial development in the course of cryptography.
Prior to that, a lot of cryptographic systems required people to meet up in person to transfer information in a encrypted way. So let's say I want to send Jim a message that I don't want Jeff to be able to read. Jim and I would need to come together. I don't know, we'd meet at some bar.
We'd exchange these super secret one-time pass codes and say, this is what I'm going to encrypt this with, we'd jumble the letters in a certain way and then effectively we can communicate and secret even if Jeff gets our letters, he can't figure out what that we're saying. The Enigma machine was very interesting because they actually had a physical machine. So this wasn't handwritten, you didn't need to do this math by hand. It's like a calculator just for encrypting things.
And they used these mechanical parts to actually shift, rotate, swap characters to the whole new words phrases, jumble this information. And it started this race for kind of how secure really are these algorithms that are used to actually communicate. And can you do these things without having to directly meet up in person and distribute them widely to, for example, your entire military force?
Yeah. And so my understanding of a ciphers, one of the, I think great examples would be the movie of the Christmas story where Ralph gets that secret decoder ring. Basically it just shifts some interlocking circles of A is E and then B is F, et cetera, et cetera. My understanding with the Enigma was that it was multi-stage encrypted, right? So it shifted and then it was shifted and it was shifted again. And this was a tool that the Nazis had was the Senigma.
And somehow the Britain was able to get actually one of the machines so they were able to decode all these messages by retyping them into the machine on the decode, which I think is just an amazing part of history because you think about this war happening. They think the Nazis think they are sending encoded messages or encrypted messages and they could all be decrypted. Absolutely. And then intelligence was critical to ending that war, right?
And it's super interesting to see how they were able to go through and actually reverse engineer the entire machine so they could figure out what the key was that they needed to actually set up inside of the Enigma machine. So for those that are unfamiliar, they have different settings with knobs and plugs that basically you can configure the machine to act in a certain way.
And that's really equivalent to some of the private keys that are based on all of this cryptographic stuff that we have today. I think that gives us kind of a couple of the major concepts, right? And so now we still have these problems, but now they're on a much grander scale in terms of the computing power and the need to encrypt it a much greater level.
And so I want to start off with kind of some basics and the word encryption, kind of what is encryption and also I heard the term encoding a lot. And I wonder if you could explain the difference between encryption and encoding. Yep, absolutely. There are a lot of words in the space that sound very similar and they're very different.
But encryption is effectively that process of taking a piece of information, can be a message to document whatever that you want to send to someone else or store in a secure manner and effectively jumble up the pieces of information so that somebody that just comes across it, whether it's a man in the middle attack or you just leave it sitting on a table if it's a piece of paper, nobody can actually get that piece of information out without a specific key that will be able to decrypt it.
So encryption has two parts, right? Encryption and decryption. So encryption takes your plain text thing in, makes this what they call a cipher text, which is this jumbled up piece of information. And decryption is the process of using that key that you have for decryption process to get your plain text back. And the other hand in coding is really just a way for people to place information in ways that are helping out the specific system that it needs to interface with.
So something like a, in the identity space, right, you have these things like a pm file, right? You'll see keys are often stored in these things and you need to upload them into different portals on the internet. That's just one specific encoding scheme.
There are ways to change the encoding scheme because all of the information is just sitting in plain text, but maybe one system wants to read it in this pm file, one wants you to just copy and paste this text into the weird fields that the system needs. Maybe it can work with the CSV file. So just separate it by commas instead of with this specific metadata in front of it. So the encoding is not really, the intent behind encoding is not to make it hard to read.
It's more to make it more easy for the machine to process. Exactly. Wow. Okay, I actually didn't know that. So when we hear about encryption, we hear symmetric encryption, asymmetric, and I think you made a good point, it's encryption and decryption, right? But for the sake of making it simple, just symmetric and asymmetric encryption, can you explain the difference between those or what those two things are? Yeah, absolutely.
The encryption and decryption part is actually very important for this point. So for symmetric encryption algorithms, you have one key that is able to both encrypt and decrypt that piece of information. So if you have whatever bits long key, you shove it into the system, there's one way that that key will encrypt it and the same key will be used during the decryption process. Asymmetric, though, has two separate keys.
One is used for that encryption process and the other one is used for the decryption process. And having two separate keys seems kind of odd from a baseline standpoint. But when you're talking about making systems that can communicate without needing full trust in the entire system, right? This whole, I don't want to meet up with Jim and person thing. I want to send this over the internet. I want a key that I can have anybody in the world know.
And then I want the secret one that I can only get information back from Jim. So it's kind of like I can set up a post office mailbox outside of my house. And then the person with the right key can, you know, do things with it. Use an interesting term there. And this is our fifth grader opportunity. Talked about keys. Is it like the key that opens the door to your front house? I mean, or front door. How do you explain these keys to the fifth grader?
Yep. So the fifth grade explanation often it is good to yell at like relative examples to how you get into a house, right? We'll say exploring different opportunities within the digital space. Every key is just a bit, a number of bits. So just zeros and ones. You'll often see encryption algorithms listed like SHA 256 or AES 256, RSA 248, these kinds of things. That big number at the end is often just the key length. So how many bits do I need as my key to actually operate this function?
So is key as an in for certificate? I know we're going to talk about certificates in a little bit, but I just, it sounds to me that it's kind of the same thing. Keys are definitely related to certificates, but they're not the same thing. One thing that's good to know about certificates is that they have a lot of different fields, right? And there are certain ways to have information laid out, right?
And a certificate often has a standardized way of looking so that your browser, for example, can read it. And one of the things if you click into your browser and look at what the certificate is, it'll actually give you some of that information. So it'll have a public key for a specific provider directly in that certificate.
Likewise, if you have a certificate on a user's device that authenticates them within your corporate network, that's going to have different information, but still a similar format. So it'll provide a way and context for that specific piece of information as to how all this should link up within this larger infrastructure that's built around it. It sounds a little bit like certificate, sort of like combination of encoding and encryption to some degree, right? Is it, am I getting that correct?
Yeah, certificates definitely have encoding. They definitely have keys for encryption, and they also have hashing in there as well, which I'm sure we can get into. The encryption itself is, as I understand it, is basically just a math problem, right? There are different types of encryptions, or different types of math problems. And you mentioned at the end, the bit length being how strong, I guess, how strong is that math problem that needs to be calculated and figured out? So is that correct?
And then was it mean to break an encryption? Yeah, all those are loaded questions. I'll start with the, like I said, the numbers at the end of the algorithm often are just the key length that's required for that algorithm. The massive caveat, I want them about to say, is that key length is not necessarily indicative of how strong your encryption is. So for example, if you take something like AES, which is a symmetric key cipher, and then you compare it to RSA, which is an asymmetric key cipher.
128 bit AES is roughly equivalent to 248 bits of RSA. So 20 times the key length in RSA is about the same as 1x and AES. Okay. So when we say the different types of encryption, sorry, I want to make sure I understand it. I feel like I'm in class, I'm asking questions. So when we talk about encryption, it's not so much the bit length, like you mentioned, but the type of encryption influences how complex that bit length needs to be.
So the way I'm kind of thinking about it, I was like, okay, well, you can have a very long bit length. But if all the answers are either yes or no, eventually you can think of that pretty quickly compared to maybe something that's like hexadecimal or binary or other things like that, right? They have more values for each bit. Is that, am I thinking about that right? Yeah, absolutely. There's a few different places that you're combining a lot of ideas and they're all going in the right direction.
I love it. So effectively, the algorithm itself can be vulnerable to different pieces of the key space discussion. So maybe there are easier things to figure out within that key space. Maybe there's not just only one right answer for every one key that goes in, which is something that you really, really don't want to do, right? You might have two to the power of 2048 bits combinations for this output, but maybe it's just, oh, okay, half of them have the same output. That's just a bad cipher.
It doesn't necessarily mean that your key is providing extra security. That being said, the actual algorithms that you use of the newer ones that have come out. So AES, for example, is very common. But today, you'll often see AES 256 being the bare minimum that people use. And that's specifically because computers are constantly getting better at breaking these things.
So when you're talking about breaking, the most common way that people explain this is just how hard is it to brute force break this combination? So if I run a brand new GPU, load up all those cores, and try to track your password, how long is it going to take? Or if I iterate through all, if you're only using 64-bit encryption, I can do that in a few days or even sooner, depending on how good your hacking tools are.
But once you move into some of these crazy things, like elliptic curves and all this cool stuff that's coming out, there's some wildly difficult challenges for these computational devices to solve. Yeah, on both hands, right? You have to wildly compute the encryption and wildly decryption. I wanted to run through a couple of real-world use cases for where you'd use symmetric or asymmetric. And let me throw out the ones I think I'm going to use.
So something like for asymmetric would be like, or you have a public key that's shared between both ends of the communication. So something like the internet, something like an encrypted website. And a symmetric might be where you're like encrypting your hard drive or using something like a zip or something like that. So am I right? And what are some other really good examples? Yeah, all those examples were spot on.
So if you try to log into your bank, for example, online, they have a private key that only they know and you will authenticate into their system using the public key that they distribute to everybody. Everybody should be able to come to the website, but only they should know the answers to the questions that you're putting in or be able to start that communication back and forth. One of the interesting things is actually how asymmetric cryptography is usually more computationally expensive.
So it takes longer to run these things. So when you're working over the internet, you're actually using both asymmetric and symmetric. So you use asymmetric to get that initial session started. But once you have a session going, you can use something like RSA or something that faster to transfer all of the secure data you need to push back and forth through that pipe.
And that computation limitation is something that's constantly on the minds of some of these larger organizations that have to push a lot of data through to their customers. Do we want to upgrade it and double or triple or 10X or CPU usage or do we want to run things faster cheaper? Get things going. Well, the other thing is like I would assume the user experience would get a lot worse if people were having to wait for the output of the encryption. Yep. 100%.
So you mentioned a few different levels of encryption. One that I hear about a lot is like Shaw. So how important is it for IAM practitioners to understand them? What are some of the big ones out there and kind of what are some of the main guidelines like these ones are good, these ones have been shown to be broken, things like that? I think that Shaw is a good lead into what hashing is since there is a difference between encrypting something and hashing something.
So like we were saying about encryption, you want to pass a message and you want to be able to decrypt it later. Hashing gives you that same looking random, jarvaled nonsense. So you can't see what you put into the system. But has no way of getting it back. They call it a one way function. So I put some nonsense in. It makes the super crazy, unreadable thing. And oftentimes they'll use that for in the password kind of identity space. So I want to put my password in.
I want you to know that I had to type the right password in, but I don't want you to store my password on your server because that would be really stupid as we've seen from a lot of packs that have happened over the past few years. So getting into Shaw, right? Like, Shaw won supplanted this thing called MD5, which was a prior hashing algorithm. And Shaw won is also now compromised and you're going to go to Shaw 2 and Shaw 2 uses at least 256 bits of key space for their implementation.
So within these hashing algorithms, you want to make sure you don't have these things called hash collisions. And that is when you can put two separate inputs in and get the same output. So thinking about that, I put in my password and then Jim puts in some other password and they happen to be the same. I don't want both of those answers to give me the same output because I want to let both of us in with two different passwords.
So it takes something like Shaw 3 and then it's usually followed by a number like 256. So break that down for us, is it, am I getting this right? Shaw 3 is the algorithm 256 is the length of the key that you used to do the the encryption of the hashing. Yep, absolutely. So why not just do Shaw 3 1 million? Most of that limitation comes from how long do you want to wait for your website to load kind of a deal, right? I don't want to sit around for 10 minutes to start listening to this podcast.
I'm sure it'd be great, but that key key needs to go real fast or I need to be able to log in really fast. So a lot of providers are very aware of that, even though there might be security benefits, it totally depends on the system that you're building. Because the way it works is like you are, you type your password in. It's been hashed in some kind of data store, right?
So it's a block of characters that look nothing like your actual password and it's got to run it through the same hashing algorithm. It would run it through to write it to that data store in order to verify it's correct. Yep, and if it's not correct, it just says incorrect. Does it work the same way with any kind of biometric? Where it basically turns, does it turn your face into a number or your thumbprint into a number and then hash it and put it into a data store?
Yeah, the concept is very similar. And you'll actually, if you think about when you set up a new phone or a new device that has these biometrics, they always ask you to set it up again, right? They won't carry over your fingerprint or carry over your face or whatever you're using to authenticate. So each system has their unique way of processing this and make sure not to transmit, let's say your face to Apple so that they can identify you anywhere in the world.
Biometrics is a slippery slope, but effectively, yeah, it transfers your face into a key and they have some process of having certain amount of confidence that you are in fact you. So I'd like to bring this into, I think, maybe fundamental, but it's more of the architecture of how this works. But let's start. What are certificates? What's a certificate authority and what's a public key infrastructure? Yep, certificates.
I'm sure all of your listeners use certificates on a regular basis, whether they need to update them and insert them for single sign on their websites or whatever. So the certificate's actually a approved document that is issued by a certificate authority. And these certificate authorities, as you mentioned, play a role in this larger public key infrastructure or PKI.
So these certificate authorities are trusted entities within the network, whether it's Microsoft, they're using like, Entra or Azure AD or one of the other providers or if you're on the internet scale, right, you can find these different providers just by looking into the certificate that's loaded in your browser right now. And what happens is they go through and act as a trusted third party for whatever communication is going to happen over the network.
So they do the legwork of saying, okay, I know Jim's organization is real. I have validated that and I'm going to put my money where my mouth is and issue the certificate that proves that this was issued by me. This is approving this specific individual or organization for use of this product and this is how you can communicate with them securely.
So part of what's included in the actual certificate is a public key that people can verify using the certificate authority that will help you establish secure communication to that entity. And the other half is actually a hash of the full certificate to make sure that nothing has been tampered with.
And just like we talked about in the past for an example, you want to make sure that the certificate has the right information in it and that it's been signed by the certificate authority that it is authentic. So I want to throw a few things out there and you tell me what they are. If it's CAs, PKI or something else, so in iOS land or Apple land, we have keychain. Keychain is a password manager at the highest level. So it doesn't have, it's not a certificate authority.
No, no, it just stores credentials. What about GoDaddy? GoDaddy is in between, between you and the internet, right? I want to go buy a domain. They work with certificate authorities. I don't believe they are a certificate authority, but I know that a lot of the larger organizations, like if you go to Microsoft or Google, they often are their own certificate authority.
And there's processes for doing that and there might be reasons that you would want to do that for controlling your own infrastructure. But GoDaddy, for example, provides access to the domain naming service, which DNS, right? You want to type in a web address and resolve it to something, as well as often providing integrations with people that can install SSL, TLS, licenses or certificates, should I say?
So the next one we wanted to throw out there because it's been seen this notation or naming X509, like how did that, that's such an odd name to me, but what are X509 certificates and how did they get that name? X509, I'll just say all of these things have super complex names for seemingly no reason, just because they're built by a bunch of nerds that can only think in numbers, right? So X is a cool letter and then you got this family of certificates or standards that you have to use to.
So X500 is a series, right? And then you have X509, which is the ninth thing that they did. So there's actually like an international standards body that came up with this thing. And yeah, asking for rationales to why things are that specific way gets a little bit more complicated. So certificates have an expiration date built in them, right?
And I understand that I think the purpose of the expiration date is if they get fumbled, they get somebody gets a hold of them who shouldn't have them, eventually they'll expire or so. They can run with them for so long, is that correct? Yes, most operating certificates for like websites are about a year right now. And so that was my lead into a listener question. So Mike Woodburn submitted a question. What are your thoughts on Google's 90 day certificate expiration plan?
That's a great question. I think there are a lot of different ramifications for what that means. I'll just say baseline security improvement, having faster removal of expired certificates will be better, right? So if there is something that is exposed for a certain amount of time, the remaining time that you have left in a year versus the remaining time left in 90 days is significantly improved.
Similarly when you're thinking of quantum coming in, you'll want to actually be able to upgrade the system a lot faster. So some certificates out there are still supporting older protocols that can't actually be used securely. And you'll start seeing these like red, lock logos that they're kind of okay, but they're like getting depreciated. So I think Google is really interested in moving that forward.
But looking a bit broader at what this is going to do, it's going to force a lot of the manual processes that are in place at a lot of organizations to get upgraded to automated operations. So if you can do something once a year, like it's still a giant pan if you have like hundreds or thousands of these things, but personally I can manage upgrading my own certificate once a year, right? I put a calendar thing in and it's good. I'll say there's also downside to that Microsoft.
I think recently had two different occurrences where they had outages caused by an engineer not changing this. Like literally if you forget to see this calendar notification, you're going to have, you know, Azure go down or something. Sounds bad. So moving to a 90 day schedule is going to get really unsustainable for that model.
So you need to automate a lot of these systems to upgrade automatically, stay current, pipeline in whatever upgrades we'll need to get pushed in, which is not kind of a small effort, but I think long term when you look at how fast things have evolved since the enigma days, things are about to get crazy.
I immediately thought when you started to answer the question around the overhead for administrators and say, okay, yeah, once a year, get it, even still with once a year, people forget to forget to extend or replace the certificate. And now we're talking about doing it four times a year, which that is administrative overhead for sure and keeping track of that. So definitely trying to automate, I think, the certificate lifecycle is probably a good pick.
You talked about quantum and I think that's how we want to wrap up this discussion because well, first of all, I've learned a lot. Second of all, am I going to have to unlearn all this when quantum comes along? Because if you listen to what people are saying out there and like headlines, which are probably clickbait to begin with, anyway, quantum is going to break all of this.
And we have to come up with new novel, whatever word you want to use, right ways to get into the quantum encryption space. Because I understand it right now, it's very expensive to do anything in quantum right now, but it is starting to take root. You've got large organizations and probably nation states that are looking at quantum is sort of the next level for that.
Can you talk a little bit about how does this conversation we're having around encryption really get affected by the quantum space? It's a very, very good question. Quantum, the threat of quantum has a lot of people scared in the cryptography community, namely because when you talk about key spaces or like how hard these algorithms are to break today, when you look at 256 bit AES, the key space is 2 to the 256, which is insanely large, right?
Like we're talking numbers of atoms in the universe or number of stars and multiple galaxies, right? It's a huge, huge number. The quantum threat is really what if we could have a superposition of 1 and 0 at the same time and we're going to check all the numbers at the same time. So instead of breaking the whole thing, I only need to break one bit of your encryption.
I'm going to do it 256 times, which with most of the algorithms data transmission protocols we're using today, that's going to be a real bad thing. Yes, the headlines are a little bit wacky. These systems are still super unstable and very, very expensive. So like Google has one and it needs to work at like cryogenic temperatures. It's not like walking around in your pocket.
But for me, the real scary thing about quantum is that people are already starting to store information now that they want to break later. So you'll see nation states actually harvesting this information and say, I want to know the secret information that Microsoft's passing over the secure channel. What if I could reverse engineer that key? That would be great for them.
But in terms of what your listeners need to know with cryptography, what we've talked about today, nothing is really going to change except for the exact algorithms that you should be using. And a lot of times those things are already described in documentation or like Microsoft will have a list or Octo will have a list. Say please change these settings from shall one to shall three, right? It's just a configuration change.
So especially when you add in some of these automation things, it should be fairly painless to upgrade the knowledge in that space. Are there certain encryptions that are more resistant to quantum or because the way quantum works it just is not going to matter? Now the algorithm actually dictates kind of how susceptible they are.
So some algorithms are dependent on like factoring super, super large numbers, which is really, really hard for computers today, but for quantum computers might be really, really easy. And some so elliptic curve cryptography, you can look into that buzz word. We'll see a lot of blockchain stuff there. They use some of those algorithms. But basically they were put there to try to avoid a lot of the headache that's going to come with quantum. And obviously things improve over time.
Like these will not be secure forever, but they are in fact stronger against these kind of quantum systems that will be coming online. So what should I be doing as an IAM person to prepare for this? To prepare for quantum, I think it depends on what your role is within the organization.
If you have the ability to dictate what your stance looks like for your organization and kind of push for why we want to try to push towards automated systems, try to have upgrade paths within like version controls to get things moving a little bit faster. I think it's really important to be flexible and not lay around too long on legacy infrastructure that a lot of people have been doing thus far. It's not so much in terms of what you need to learn.
It's just that you can be agile enough to survive the next wave. And start automating some of the manual stuff going inside. Yeah, it seems to me, Jeff, that with the point that Andrew was making earlier that some nation states are really anybody could be capturing packets and storing them until they could break them later.
You could be capturing packets where people are sending their password over an encrypted channel, maybe one of the things, not just passwords, but authentication, secrets, overall, making sure that those are getting changed. I know we've been arguing against changing them on a two-freak basis because that's the nist recommendation.
But if you have that and the quantum computing capability comes along within the next decade and it's commercially available, now your potential in trouble if you still have authentication data that is 10 years old and someone captured it. It probably depends on what industry you're in. But if you're in the industry of nuclear power generation or defense department or government period versus if you make donuts, you're probably in two different scenarios. It could.
Yeah, I mean, when we all love to be able to make donuts at home, yeah, I'd be even more around than I already am. Maybe that's not a good idea. Maybe not a good idea. Angie, bring up a really important thing that I think maybe not everyone thinks about is that collection of data. Even if you can't break it today, well, I'm just going to tuck it away here in this folder and someday, maybe I will be able to. Is there anything you can do about that?
If the data's already gone and it was encrypted in a certain format, short of changing every piece of data that might have been associated with that stolen data set, I'm not sure if there is a defense for that. Yeah, it's a little doom and gloom in terms of that data being out in the open. I think what's me sleep pretty easily at night is just knowing that what I'm doing now and what I will be doing in 10 years from now will probably be totally different.
The pieces of code, even if it's proprietary information that's fed over a network, unless it is at what you're saying, a government level, and that's why you have some of these more extreme standards that are pushing for higher security tolerances today. It really shouldn't matter to you that much. By the time we get there, if we can succeed with a lot of these automations, I think we'll have enough of a flow to kind of keep the system moving.
It's a constant struggle between the attackers and the founders, but as an individual, I'm not too concerned. I think the only government agency that should be concerned was probably the one called Kentucky Fried Chicken and their kernel sanders with their secret blend of herbs and spices. Hopefully, they're on top of this. That has changed in 100 years or something, right? It's secret or the Coca-Cola recipe or something like that, right? I think those are things that are interesting.
All right, let's wrap things up here for the conversation. Andrew, you've been extremely informative. I know this is such a difficult concept to try and crack within the span of 45 minutes to an hour, but I feel like we've got a pretty good start on it. I do want to end on a lighter note and I find it interesting. We were kind of talking before. I was like, oh, Andrew, what are you doing in your spare time?
You're having a fun, you mentioned pickleball, and then you mentioned something that, of course, that peaked my interest, which was playing competitive games. You mentioned a game called Splatoon that I know of. I am almost positive that Jim has no idea what Splatoon is. Can you talk a little bit about, first of all, what is Splatoon? Then when you say competitive, define competitive in that context.
Yeah, so I've actually had the pleasure of trying to describe Splatoon to a lot of people because it is not a normal game. At its core, it's a third person shooter. It's a shooter game. You just don't have their perspective. You look over their shoulder. It's basically paintball. Your objective is to often cover more of the map and your color of paint than your opposing side. There's also you can blow people off, right? There's the whole shooter aspect of it.
The wild part and a lot of people just turn the game off as soon as they figure out, it's a game. It's based on human, squid, hybrid people. You can climb walls, sink into the, they call it ank instead of paint, and swim through your own color. It's a pretty cool, like, z-axis breaking game.
In terms of why I say I played competitive Splatoon, I actually joined a team back in 2015, ran with that team for about a year and spun out my own team from the top tier players on that one and formed a new team that was based in the US and Europe. To try to play this at a really, really high level while doing a PhD because I'm crazy. I only say competitive, and I don't like saying professional because nobody that plays Splatoon is a professional, right?
You cannot make enough money to actually do this as your career without massive YouTube sponsors or Twitch sponsors. It was a good time. I still play casually now, but definitely not the same time commitment that I had before. I fall into that category of, I picked it up, I played a little bit, and I was like, oh, boy, either, I felt like okay, I used to be good at those kinds of games. Back in my day, it was things like Golden Eye. I ruled at Golden Eye. That was my jam, and it was amazing.
Halo is also pretty good at, but I found as I get older, I just suck at those games now. I'm just not as good as it used to be, and I got really frustrated with that whole Z-axis. There's the guy in front of you. Great. I've got a shot, and then what happens is they duck basically, right? I was like, okay, ducking is fine. It's not that they just duck, though. They disappear, Jim. They go into the ground, into the ink that is kind of spread all over, which is a very cool concept.
I think it's fascinating. I stink at it, but I do enjoy watching that kind of stuff. Jim, you've kind of heard the definition, or at least the description of a Splatoon. What's going through your head right now? Are you trying to decrypt the answer from Andrew and re-encrypt it? No, I was sitting here feeling kind of anxious. Like, okay, what question is Jeff going to ask me about my favorite video games? I don't think you're... You're not okay.
Well, I used to like, I worked in an arcade in high school. It was like... Yeah, but the games that I remember that I love the most for games like Spy Hunter and Frogger, Burger Time, Centipede. Yeah, yeah, yeah. Now you're on to it. We had the axoring competition. Part of the place was they had old-school video games that were broken. I was like, oh, I love this game. Oh, it doesn't work. And just like in the olden days, the joystick might work up and down into the right and not to the left.
So you just fully move to the right. And what you got to the right of the screen, the game was over. The first game I walked over to was the original Street Fighter, which is a fighting game. And I was like, all right, I'm going to pull Ken or Raiya out here and start doing my fireballs and dragon punches. And the bottom right did not work. So you can't do any of his moves without that combination. So I went back to axoring instead.
But yeah, for those of people who are interested, there is a really cool pinball museum here in Asheville, which is the area that I live in. And they have a bunch of old-school pinball things. And Jim, you'd probably like it a lot because you're an old man and you like that kind of thing. But yeah, it's a cool spot. And they've got some of those classic games in the back as well.
I am currently, as of my last check, the top-ranked time pilot arcade cabinets scoreholder right now, which is not saying a lot because I played it once. And they must reset it very often. But when I left, I was the number one high score on time pilot. I feel like when I was really into pinball, usually there'd be an ashtray on the pinball machine and so on. And some of these pinball machines do have that. I mean, these are some really old and interesting ones.
It's a museum and they've got maybe 30 to 50 different machines of different ages and stuff like that. So I just kind of could we'll see that. There's one old one that is a baseball one, which is two-player. One player basically pitches the pinball down and the other player is the batter and has to hit it out somewhere. And it's basically like an outfield, but the outfield changes every pitch.
So you can't just keep hitting home runs because you're getting the timing down is you actually have to aim and get your timing down of your flipper to get the ball out to the appropriate spot. I like it. Yeah, it's very it's it's old. I don't know how old I want to say it. It seems like it's like 50s, maybe 40s, but it's kind of a cool. It combines two things that are like baseball and old and old.
Andrew tell me about so this team that you created while you're going through a PhD, which is absolutely not stupid. What do you do, man? You took the best players from the one team and kind of created your own kind of super team out of that. Sounds like. And this game is on Switch, right? The Nintendo Switch? Yeah, the prior, well, the game I started on was actually Splatoon 1. Now they're on Splatoon 3. So I played all three of them.
The first one was on this thing called the Wii U, which was probably the worst selling console of all time. Nobody understood it. Like it just didn't make any sense. It just like looked like an add-on for your Wii and nobody got that it was a whole new console. But anyways. Yeah, effectively, once we move to the second generation, I was like, I want to try to win. I don't want to work in this middle-to-low class, be happy we played somebody cool, right?
I want to go to those people and just shove them in the dirt. I don't want to get going. I'm trying to win in paint. Yeah, it's the competitive side. And part of my academia wasn't for me long-term, right? Part of this is more fun. But yeah, it was a wild experience to try to find people virtually over the internet and build relationships with them. So I played with them for multiple years before meeting any of them in person.
So the whole ecosystem was a very interesting introduction as to what the decentralized virtual, only future thing was going to look like. And I'm really appreciative that I spent the time to do that, even though at the time really counterproductive for what I was trying to get accomplished. It makes a pretty cool relationship, though, right? I'm not ashamed to admit that I played World of Warcraft for almost 20 years, I think, at this point, since beta.
And I've had some, you know, been part of guilds, been part of rating guilds, and then not the professional level that you kind of see today, but certainly in a competitive server-based approach, like, you know, who's going to get the server first on killing at this time? It would have been the burning crusade. So, you know, who could take down Illidan first, right? Those sorts of things, sort of like when I was primed in it. And my wife and I actually both played.
And we were both in this rating guild and had a good time with it. And we had guildies that we, you know, talked to pretty much all the time. And at one point, we actually did meet in real life a couple of them. And it was very awkward because I was, I think at the time, I probably would have been in my 30s. And then, you know, here comes Ben, if it was his name, and I can't remember his brother's name. So, I'm sure they're not listening to this, it doesn't matter.
But, you know, they walk in and ones like 16, and the other ones like 23. And, you know, we went and got Mexican food, had a great time, just kind of talked and, you know, stuff like that. And then that was kind of it, kind of worked through it. So, it is kind of a cool community, especially if you can kind of build those relationships.
And it's not just, you know, it's not just 10-year-olds telling you about your mother, as what you see, typically on sort of like commercials and stuff like that. Let's go ahead and wrap it up for this week. Our next conversation is really going to get more into that quantum. But we felt like, and Jim had this idea of like, okay, let's, we need to like set the stage or get the quantum. Like, what the heck are we even talking about?
And it really starts with that cryptography discussion we had today. I know there's so much more and maybe Andrew at some point and kind of come back and continue the education and conversations as things go on. But I thought this was really helpful. Hopefully, people out there have enough knowledge to keep up with the next conversation we'll have around quantum. We're going to have a whole bunch of links in our show notes. So Andrew, it'll be your LinkedIn profile, a link to revivebackup.com.
So you can learn more about what Andrew is actually doing with all his smarts. And as well as all of our links to the different conferences and discount codes that we've got for things like a Denny Week America and the Fennelkate and Octane and kind of things like that. So with that, we'll go ahead and leave it for this week. You can find us on the web idacpodcast.com, on Twitter at idacpodcast, on mastodon at idacpodcast at infosec.exchange.
And definitely you can connect with Jim and I. Send in those questions and those comments. And if you don't forget to hit that subscribe button, that's the best way and really the only way you can kind of help us, other than just being a listener, to help us put out great content and help us get people like Andrew who answered the call of cryptography. Who can help us out with this? Thanks everybody for listening and we'll talk with everyone in the next one.
You've been listening to Identity at the Center. We hope you've enjoyed the show. Make sure to like, rate and review and we'll be back soon. But in the meantime, hit the website at identityatthecenter.com and find us on Twitter at idacpodcast. See you next time on Identity at the Center.