 All right, good morning. I say good morning because I know by this point in DEF CON, we're better off using the same time zone as Tokyo, which makes this about 7 AM. So thank you for getting out of bed. The good news is we have an interesting topic ahead. We'll get to spend the next hour talking about boobies. Or more specifically, strategies designed to protect an execution environment for manipulation with a specific eye towards ensuring cryptographic keys can't be exfiltrated via physical access. Try three times fast. Hey, good morning. Oh, man. There we go. Yeah, I tried to change the slide over here. And Google was asking me for a question. Your presenters today are myself, Ladar Levison. And I'm Hanimbo. Hanimbo Tales. What we're going to be talking about are essential skills for life in the world of 1984, where the maids can't be trusted and your big brother is out to get you. For my part, I'm the operator of LavaBit and encrypted email service. I'm a technological warlock, a corporate kingpin, and some would say a team linchpin. My assistant, Hanimbo, is the proprietor of hacking and coffee. And he enjoys robbing banks under the cover of darkness. Assistant, come on, man. I'm your web host at this point. A little more than that. Let's talk about security. As an industry, I think we've come a long way. Speaking for myself, it's been a few years since I've seen anybody try to log into their box via telnet. One of the key factors pushing that security is encryption and its proliferation. Encryption is important because it provides a mathematical guarantee that the data can't be accessed without the corresponding key. Of course, the problem is that as we've evolved, so have the attacks. Unfortunately, as good as we are at architecting and building secure systems, we still need a reliable and friendly environment to run our bug-free, ultra-secure code. With encryption specifically, we've seen a new breed of attacks where all the security measures we put in place get simply via physical access. Now, there's a picture of an altair because that was probably the last computer you could look at and kind of understand how it worked on the inside. Before we go any further, we should talk about our assumptions. For our purposes, we're focused on targeted physical attacks, which means we're making the assumption there is no universal backdoor in x86 hardware. As always, when it comes to assumptions, your mileage may vary. Unfortunately, we don't have time to cover it today, but it makes sense that if your threat model requires you to install booby traps in your hardware, you probably want to do to your IME as well. For those of you who've spent some time in this building, what we're talking about will look familiar. Essentially, we're talking about taking commodity hardware and modifying it to afford you some of the security guarantees provided by FIPS Level 4. So we can run our common criteria EAL4 plus software in a secure environment. Unlike the actual FIPS Level 4, our recommendations don't come with certificates from the government though. If you aren't familiar with those standards, don't fret. It only means you haven't spent much time working for the man. For those folks, I'll summarize by saying FIPS Level 4 is what the State Department would use for a classified information terminal. They have located in the basement of the American Embassy in Taylor. Some place interesting like that, if a machine can stay secure in an environment like that, is that the same computer would be worthy of being placed in a co-located facility and be safe from legal, extra-legal, and illegal access, probably. There are plenty of commercial solutions available. And they'll work great if you don't mind paying too much for five-year-old technology. Personally, I have a problem trusting black box crypto modules, particularly when the vendor's largest customer happens to be the government that you may be trying to protect yourself from. There's some notable open projects, the most notable being Orwell as in 1984. And for those of you looking for a secure solution to place at home just to protect your Monero private key, that might be a good way to go. Unfortunately, running a service like LavaBit takes a few more MIPS than a sixth-gen mobile processor can give you. Unfortunately, even if that was enough, unfortunately, their rack solution leaves something to be desired. So I decided to go with commodity hardware. And while I have my concerns about Dell, it's easy to find warehouses that let you pay cash and carry away the equipment. It's always good to purchase your gear anonymously. As a tip, if you have trouble finding a local vendor, try searching eBay for sellers selling what you want in your local area. Odds are, if they have multiple listings, they're simply a vendor with a warehouse full of gear. More than happy to sell it to you. Whoa, am I? If you're a high-value target, I'd certainly recommend against ordering equipment online and having it shipped. You never know what can happen to it in route. In case you didn't catch the subtext in this note, Apple even has problems with their servers being intercepted and modified during shipping. If the largest company in the world can't do it, what chance do we have? Interesting factoid. If you look at the SEC filings for Intel, you'll find out the three of their biggest customers for custom x86 chips are the NSA, Google, and Facebook. Makes you wonder what customizations they're having done to their particular chips. If there are any FOIA fans in the audience, they may want to go after those details. Be sure to pick a commodity hardware vendor with a reasonably robust and competent security team. So you could probably meet a big portion of their security team here, and you can make your own judgments about whether or not they're competent. You also want to look for one that's going to use signed firmware updates and will continue to publish firmware updates for some time after you purchase the hardware. Unfortunately, when it comes to commodity hardware, most servers do ship with tamper detection circuits, but they tend to be rudimentary and thus easy to bypass. It doesn't help that their location is known in advance. That's one of the benefits to the do-it-yourself approach. You can randomize the location, even add a reverse switch. To demonstrate just how easy it is to bypass these tamper detection circuits, Honimbo is going to demonstrate on this R710. So we need some volunteers in the audience who can see the front LED and tell us if he manages to trip the circuit. The trick in this case is to take the shim and go through the regulatory label hole in the top of the case, find the tamper circuit, depress it. They said it would be fast. You may have had a malfunction earlier. You know that always helps. Who's got something? Hey, you try getting up in front of 1,000 people at 7 in the morning and doing this. Once you have the tamper circuit depressed, you can lift the top cover and remove the case, remove the lid, giving you access to all sorts of different ways of attacking the system. Most notably, being those exposed JTAG ports. Moving on, if you think about security as an absolute where something is either secure or it isn't, then you're going about it all wrong. I like to think about security in the same way physical safe manufacturers do. The first and most important job of a safe is to defend against spoofed access. If you can break into the safe without leading a trail, like by using this particular dialing spot that was demonstrated last year, the safe has failed. So our first mission in modifying our servers was to ensure that nobody could access them without us knowing. The second consideration is the degree of difficulty that an attacker would need in order to brute force their way past the locks. Presumably, with a physical safe, it's a blowtorch. With our approach, it's the same thing. And the goal is that the amount of force and heat required to remove our modifications are sufficient to destroy the machine, thus accomplishing our goal. To continue, I'm going to turn the mic over to Honimbo who's going to talk about how we made those modifications. So the first thing to know about all of these Dell systems is there's a very large debug headers, expansion modules, and available on these boards. Some of these are for legitimate things for businesses. You've got your iDRAC, you've got various OpenManage, you've got these that sometimes have additional heat. It's whatever hardware you end up with and you got to do a little bit of engineering in. In our case, we took the little bit messy approach for some of this. Some people may recognize this as a PC7 epoxy that we went through a lot of the board. So anything that can't be physically removed from the board, we basically are unable to remove it, so that they're not going to be able to practically do it while the sensors are still in place. So all over the other things that we also do the connectors. So these whole sides of the chassis, all for a very easy spots to pick probes through. And with those probes, there are various things like the front header of the USB bus on the underneath the front bezel. And part of this is not just the debug interfaces, but the ones that you're actually using to conduct operation you have. Because there's only so much that you can actually turn off and still have a working system. PCI risers, we just went ahead and go for that. And just wear some gloves to take skin off. I know this the hard way. One thing some people may notice, I have some very cruddy solder joints on here. There's a reason for this is if someone were to start physical damage, we would have the server fail off. So you may notice that we have a few different types of contacts here. For one, we have just a sample of a simple lever switch or the roller next to the original Dell chassis sensor. So we have a few different types. Again, solder joints, and this is really interesting. So we take advantage of the actual disassembly for these servers. In this case, assembly module inside of one of these Dell R710s. The fan module comes out as a big tray and we can pull out any of the fans. Oh, luckily for us, Dell has lots of alerts when it comes to fan failure. What we started doing is in the modules, we added a lot of our circuitry and sensors for some of the units. And part of this is that in order to get to the initial components, not only do you have to try and bypass our sensors, but at the same time, you've got the existing diagnostic sensors that weren't even tamper intrusion working for you. So all of these extra fans, the speed sensors, there are tons of diagnostic information that lets you know something's wrong with your environment. It's inside of a co-location facility, any decent quality data center, you know what the environment is and you take that data whether or not the airflow is starting to lessen that something's in the room with you, whether or not the temperature is really going up in a way that's not related to hardware. And it comes down to a lot of monitoring. Yeah, I'd just like to add that bearing the switch in the assembly here, you'll notice the lip, which protects an attacker against an attacker accessing it unless they go directly, which is because they can't get the shim past this little lip here. It's important to take advantage of the natural character of your particular server when deciding where to place it. So we take advantage of that from the top, but also we actually will modify the frame as well. One thing to drill to the top and risk that power supply are causing some kind of faults, which is nice enough to do this with various types of equipment from a drill on the server laser on the government side. But going through the actual motherboard on the bottom, you're getting into the SATA buses that run underneath the particular area that we chose and you're getting into a lot of other interfaces where if you started drilling through it's gonna be very, very difficult to get to those sensors. Take advantage of everything from your traces to your layout, just how tiny you can get these little microcontrollers in place. So we use the internal headers for connecting up our equipment rather than running it back out, obviously. And we just slathered everything on there and you may notice we explicitly did not use pin headers. Again, just very, very cruddy solder joints in this epoxy as a lot of people like my challenge here know is that it's very easy to make a mistake and cause something to slip. And we want to take advantage of that where a minor slip that normally wouldn't trigger will cause damage. As again, failing off is exactly what we want. And when you get to the code that we have available right now, it's currently in its older state. It's just a simple Arduino script that's currently up. We're uploading our new version of this talk. And we've since added tilt sensors. We've added other types of contact sensors besides shown. One of the ones that we're actually working on right now is a challenge response NFC tag inside of some of the components. And with that, you'll actually be able to authenticate not just a little magnetic read sensor, but the particular tag inside of the chassis being used. We're doing great on time, so keep talking. So when we get into these challenge response systems in the box village just next door, you will notice a lot of people just bring magnets and bypass the sensors directly. One of the unique things that you can get away with when you get into the DIY approach is you can have sensors that aren't documented outside of your own design. So we actually can have unique tags per contact point inside of this chassis. On top of the more traditional methods because in a certain environment, you may be able to get the NFC signal out reliably. For practical purposes, these servers might as well be Faraday cages, as well as they're well-grounded. If someone were to try and tamper with the power supply to try to damage that, you have another Dell sensor that has a potential to kick in. And with this environment, you also have some other interesting approaches you can take. So we actually also control the server cabinets as well. And with control of the server cabinets, you know whether or not someone's supposed to be doing maintenance or whether or not someone's opening your doors to try and get access to the fiber line that's running into it. And it actually, this is where you get to a little bit of the balance act that you have to do is that it is very easy to shoot yourself in the foot with these sensors. So- Test big pro tip, test your switches before you install them. Yes, test your switches before you install them. The hard drives that were originally going to come here succumb to that. The other thing to test is not just whether or not your own, the individual server sensors work, but whether or not what you're sensing for the environment as a whole is not going to just come back to bite you. So overall, any operation, any home lab, any rack in a data center, it's gonna need maintenance. So if I was servicing this box right now, I could easily just shut off the sensors from the servicing purpose, lock the data, do whatever is necessary. So what about the server above and below it? Well, contact sensors won't be an issue, but let's say you start adding in things like various motion, tilt, and one of the more interesting ones to play with is light sensors. You have to maintain good airflow through your server still. So such sensors become very effective at detecting anything in your environment that's changed, but at the same time, you have to make sure the servers are still functional and what you can actually block off. The tilt sensors are actually one of the ones that we found the most problematic. Those server racks in particular, if you're not fortunate enough to have the ones anchored to the ground, will vibrate quite a bit when unracking the server beneath it and promptly lock or erase everything. Yeah, I mean, I can take over. Yeah, the great thing about those ball bearing tilt sensors is that if somebody tries to pull the server out on its rails, the tilt sensor will get switched from the movement, the inertia. So try drilling a hole in the top of a case when you've got two other computers on top of it that are equally protected. Like I said, it's about taking advantage of your environment. I wanted to talk about briefly how you go about building these particular modifications. It's a pretty simple process, takes a little bit of practice, but it involves purchasing switches like this along with some ribbon cables. You solder it to the two pins, mount it in your chassis in various parts, and then wire everything back to the port on this little Arduino, which we protected with electrical tape to keep it from grounding. And then, of course, epoxy did in. You then connect that to your internal USB port and you can use the Python script, the rudimentary version of it, which is in this repo, to monitor that Arduino and detect when any of your switches or detection modules get tripped and then choose to take the appropriate action. Presumably, if you have a fully encrypted system, it would be to shut down. Once you get all your modifications in place, one of the things we like to do, oh, I didn't bring it, is use thread locker to ensure you can't even unscrew it. We didn't have the screw in this particular lid, but most of these servers have at least one optional screw that you can use. Another great tip is to cover your joints with something like varnish or my personal favorite, nail polish. The more glitter the better. Sprinkle that on, take a photo of the glitter pattern, and if anybody tries to remove the case, they won't be able to replicate the exact dispersion of the glitter. Poor man's holographic seals. Now, I'd like to talk a little bit about operational considerations when you're working in a high-thread environment and you have one of your sensors actually get tripped. One of the recommendations that I would make is to take advantage of the fact that Lux supports multiple key slots. I don't have a photo of it here, but you can see that it supports up to eight different passwords. All you need to do is write a little script that when somebody enters the password in one of those high-numbered key slots, it wipes the slot. That way, if you need to tell somebody the boot password, they can type it in, and if that password were intercepted, they wouldn't be able to use it again. We didn't talk about it earlier, but one of the reasons that we used PC7 epoxy is because it has the right thermal and electrical properties. You wanna pick something that isn't going to create a short circuit with your board or trap the heat and destroy the various chips that you're trying to protect. We also chose PC7 because it's incredibly difficult to remove, as he mentioned. Don't get it on your hands. There are also other advantages or things that you can take advantage of if you're not using enterprise-grade equipment. One of the things you wanna look for, for example, is ECC registered memory. The reason being, it's incredibly difficult to remove ECC memory and still read the information off the chip after the system is shut down because ECC memory, by default, cycles itself every time it powers on. You also wanna add things like this project, USB kill, which will detect if anybody inserts a USB drive into any of your ports and can take appropriate action in that situation as well. Anything else we should cover? Let me pull up my notes. I feel like I'm forgetting something important. So actually, that's a really good question. So there's a couple of options. Repeat the question. So he asked, how are we killing our hard drives? So the first method is simple. If you have LUX enabled, you're going to zero out your memory and shut down. The second is a little more aggressive and the reason that I had to drive out here. The hard drives that we use for some of the equipment actually has a two ounce thermite charge embedded inside of it, next to the platters. Yeah. I thought we weren't gonna mention that. Well, good luck dealing with it. Yeah, don't, nobody tell our colo. It's okay, just a little smoke. It won't throw much fire. So the big trick to using a thermite drive, however, is choosing the right composition. The most common alloy used is FE-304 based, I'm sorry, FE-203. And FE-304 is the variant that you want to use. It has a higher instantaneous heat output. And depending on how aggressive you really wanna get, there's various other types of compounds that can be added in with it. Using a hobby rocketry igniter with a potassium permainate mixture gives a reliable ignition at a low voltage that can be delivered by the computer's power supplies. In terms of actually building the drives, the big difficulty is doing it in a clean environment. So with the hard drives, they're so dense now that a single speck of dust can kill a lot of sectors. So either A, if you can finagle your local university to let you use your clean room for a little bit in exchange for some beer, which is what I did. Or you can instead do the improvised clean room method in which you actually raise the humidity very high inside of an enclosed space. But the problem is that when you do this, you have to have some very good method of drying out the drives air after the fact. I take some fresh desiccant and I make sure it's in every drive when I do this. So when the air has a high moisture content, the dust will actually sit to the ground and you have a safe working environment to modify your drives. Don't assume a single drive will have good sectors afterwards. They won't, but over a large array of drives like a sand, you'll end up with enough reliability that you can safely do it. Yeah, one of the things to consider is the fact that the old fashioned spinning magnetic disks are easy to destroy. All you need is to breach the case. And like he said, get a little dust in there and it'll be impossible to read the data. The problem with SSDs is they're a little bit more robust. And that's where the thermite patch or something of that nature might be required to physically destroy. Now we're not recommending you go that route because we like to think that encryption software still provides the mathematical guarantee that you need so that if you shut power off to the device, it's just as good as if you had destroyed it physically. In lieu of that, if you're using something like Opal to do your encryption, you can do an instant key erasure on the flash ROM and then nobody will ever be able to recover that data. The downside to Opal is that it's a black box module. It's implemented by the drive manufacturer. You're never gonna get a chance at looking any code for it. There's a free PBA available from the Drive Trust Alliance and the self-encrypting drive utilities. However, that just talks to the drive. The actual encryption is still done on the drive itself which if you choose to trust Samsung or Micron or one of the other manufacturers, it's a very fast and high performance encryption system that actually erases it instantaneously. The downside is it's not testing a black box again. Did we talk about the NFC switches? I guess we have time for questions. I wasn't expecting that. Any questions? How do we test it? So, I will tell you right now, do not test in prod. So, what we actually do is I'll have usually a couple friends of mine that are various involvements and levels of tamper evidence or bypassing and I will not tell them what I did to a particular system and I will let them have at it. Beer goes a long way to bribe hackers, pay your testers. Yeah, we intended to actually bring a system out here for the tamper evident village but travel disruptions got in the way. Yeah, but basically in terms of testing you have to think about the entirety of your state machine, what possible attacks that you're considering, what your switchers are designed to do and what exactly you're working on in the event of an intrusion. So, you may choose to say I have different ranks of intrusion that I'm going to switch to just simply raising an alert or actually shutting down or even erasing the data. So, for example, the internal contact sensors, when we test those, we'll have people using various types of shims, various types of cutting tools and various types of probes to try and bypass them. We actually use a randomized mixture per deployment on whether or not it's an openly contacted switch or normally closed switched. So, that way you actually don't know and except per device for the person who built it whether or not that switch is going to open or close if someone tried to short or bypass it. So, when testing, we'll load up some data and the goal is for whoever's looking at it can they get this data off whether they do it through a cold boot attack via USB, whether they do it through actually pulling out a drive and trying to keep power to it if you're using an OPAL method or whether or not they can simply get, if they can get the chassis off without triggering it that's considered a failed unit. You can just get the lid off regardless of whether or not they do any memory-based attacks yet. Yeah, one of the photos that we showed, Chromebooks having trouble keeping up with the, there it is, the 700 megabyte PDF is we actually epoxied the power cable from the PSU to the motherboard to ensure that somebody couldn't swap it out and remove the board that way while maintaining power to the system. And this is a photo that we took after just doing the connector. We actually slathered parts of the cables as well that are exposed. One of the attacks that actually is done for forensic purposes is they will actually slice the sheath of a power cable and apply power from a secondary source to try and keep the system running. Hot jacking. Yeah, hot jacking. And with that as a concern, we took kind of precautions in terms of epoxying over the existing power so that basically any attack that will remove the sheathing with it and cause a short. So we will accept the hard fail and data corruption as a path in that environment. Be sure to epoxy all of the places that an attacker could plug into and get direct memory access. As you can see here, we covered up the ports on the riser card so that nobody could insert anything into them and add something to the system. I didn't show it, but you want to look for the BIOS chip and we don't have a picture of it here, but the pins on the side of some of these integrated ports, you also want to cover those up so that nobody can add a lead to it and directly manipulate the integrated circuit. You also want to cover up the battery. So nobody can kill power to your BIOS, particularly if you're using hardware level protection methods like Opal. So most of the modern UEFI BIOS is for Opal. Well, actually, if it detects a warm reboot, it will send the lock commands to the drives. However, if you don't have the ability for the BIOS to actually process and update to the current system status that enables a possible hot jacking attack, this is again specific to Opal when you have the encryption on the drive itself rather than using a method such as lux where you're offloading it to memory. Also, be sure you don't overlook your integrated lights out management board. One of the problems we found with Dell equipment in particular is that it's possible to disable IPv4 access to the DRAC controller. What we ended up doing was, what, setting the IP address to... A slash 32. Yep. Make your subnet all 255s so that it can only talk to itself. And then you can sit there and wonder what it's saying. A non-existent broadcast domain is something that, in some of the Dell firmwares, you can actually set. So take that to your advantage since they don't allow you to actually turn the features off. You also want to cover up some of these unused ports in the back. You can swap out these default covers which have convenient little holes in them with ones that don't... You don't really have to worry about airflow because the rear air can still eject out the back of the power supply. And of course, it's a lot easier, or sorry, a lot harder to get into the machine by sticking a fiber optic camera through an active power supply. We tried this and it ended in a lot of fireworks. We were curious. We had an old system. Any more questions? Yeah, we do it at the rack level. One of the things you want to look for is a motion. Oh, so he is asking if we install webcams inside of the hardware so we can watch anyone trying to manipulate it. So we install the webcam at the rack level and then if you have a good one that can trigger on motion, you can see when anybody approaches the environment. And then presumably email the photo to you. Make sure that the photo actually gets transmitted. You don't want to have a situation where the only copy of the image happens to be in the device in the environment that the person is accessing. We actually also recommend that you have a secondary link going out besides your primary routers, especially in a Colo facility that provides every bit of internet access otherwise. We actually experimented with Cytomodules. Kalex actually has the sprint devices. And you can also, of course, for the various embedded hardware, various Arduino add-ons, etc., add GSM chipsets as well for Excel trading. Don't overlook hardening your routers as well. We use PF Sense Machines, which run on commodity hardware, so we can do the same modifications to that as we do to the machines that run the encrypted services. So the question was is that it seems this is geared around denying access in an undetected fashion to our data and whether or not the switches should just kill power to the system. So the reason that it doesn't just immediately kill power in every case is that first, some of the sensors are particularly sensitive. Regular maintenance in the racks around it will trigger them. So you first want an alert for that because you do have to balance what your actual operational goal is and what your security goal is. The contact sensors are designed to just kill things immediately because the contact sensor is not something that will go off via traditional rack maintenance like the tilt sensor might. Yeah, you'll find out through experimentation which sensors are more reliable than others. That's where the testing comes into play. And if you look at that Python script I posted a link to, all it does is monitor the sensors. The area of the script where you actually have to decide what happens is left blank. But presumably, as I mentioned earlier, our recommendation isn't physical destruction. It's to rely on the mathematical guarantee provided by the encryption when you cut power. That at least affords you the option of restoring. You do have to be careful about using the same hardware that may have actually been tripped. So if you have a confirmed breach situation, you may just want to remove the hard drives and place them in a new chassis. I actually have a funny story. At Hope a couple of years back, the guys from Rise Up had the server that the FBI had confiscated and held on to for a year. And they brought it back to the hacking conference. They lifted the top of the cover off and the challenge was to see if you could spot the modification. Any more questions? We're almost out of time. Not yet. We've had a few false alarms when a prior facility of ours would actually do maintenance in our racks without notice. And they generated zero audit logs when they did this. They didn't tell us, they told no one. They wouldn't tell us what they were doing at one point. And I had to pride that information out of them. And while they didn't open up any of the chassis, they were moving the racks around and at one point re-cabling some of the, we found out later with the PDUs when we looked at the camera. So while that wasn't a particular intrusion attempt from the hard drives perspective, the sensors did catch it and that's already a very suspicious thing just to be inside of someone's rack. Then re-cabling above the racks is very typical. Re-cabling the PDU inside of the rack is a very rare thing. The question is, what encryption do we recommend to guarantee the security of the drives? I use AES-256 for my symmetric cipher. I've traditionally, for all my pub key stuff, have been switching to elliptical curve. Although I heard yesterday at one of the talks that it's possible the National Security Agency might have a quantum computer in the very near future capable of breaking ECC and is now recommending that we use very large RSA keys. I don't know if I believe it yet because I'm not looking forward to switching back to 8K RSA keys. When it comes to the AES, you also have to choose what mode you want to use, whether you're using something as XTS or the CVC modes. Stick with an authenticated protocol if you can. If you have it and it supports it, you want to be operating in GCM block mode. Unfortunately, that won't work with a full-disk encryption because it's a chain cipher. In order to decrypt block, you have to know the previous block. It's stream cipher, sorry. You have to use a block mode like XTS. I do have pretty high hopes. I haven't implemented it yet in prod, but Chacha and Poly 1305 look like very promising replacements for AES. But when it comes to crypto, what I like to say is that speed kills. You move too fast and you're guaranteed to make a mistake and do something wrong, particularly when it comes to picking a new cipher or a new implementation. It's always good to go with the tried and true. The nice thing about symmetric ciphers is that they're much harder to break because of the mathematical principles behind them. They're essentially random number generators that are doing a one-time pat. So if nobody can break the random number generator, either by brute-forcing the key or by taking the stream and determining what comes next, the algorithm stays secure. It's the public key algorithms that you have to worry about. And on a related note, cryptographic hash algorithms are an interesting discussion because traditionally SHA-256 and 512 have been very secure alternatives. But what we're seeing is that with the emergence of Bitcoin and all of the investment in A6 is the speed at which they run reduces the security of those older algorithms. One more question if we have it. Well, if you think of something later, just come find me at the pool. I'll be at the 303 party tonight.