 So I will actually ask for a little bit of patience today. My slides are actually being hosted in the cloud. And the data center apparently has had a massive disaster. The entire data center lost power. All systems are down. But at least they're very good at transparency. So they give us a live feed of them bringing up the system. And so we can actually see... Apparently all the servers are requiring passwords to boot because they have encrypted drives. And so we have guys quickly running around the data center trying to type in all these passwords to bring up these thousands of systems. And so this is obviously not scalable in the long term. And so we actually have... I want to give you a look of where we've sort of been in the past, where we are today, and where we are going in the future. In yesterday, we were working on standards. These are things like AES, things like in the United States PCI DSS. These make sure that everyone is using encryption at the right time and in the right way and making sure that when they do encryption that it's done in standards ways. So yesterday was mostly about developing standards. Today, however, we are actually moving beyond standardization process. Of course standardization will continue. But we are now starting to worry about the question of automation. How do we actually make decryption happen automatically? And then tomorrow we are going to be working on policy. And the reason for this is that right now we're just trying to work on a simple binary. So you can see the automation is just an on and off switch. Can I unlock automatically yes or no? And we're trying very desperately to make that a reality. But in fact what's going to happen once we've achieved that goal we're also going to quickly realize that we want to be able to automatically decrypt in a variety of circumstances and we want a variety of different policies to give us something that's a more structured scale. So you see the slider here for our policy. So the first question is how do we automate? Well we all start out with the secret. Of course this is the thing that we're trying to encrypt and then later decrypt. Then we wrap it in something called an encryption key. This is the symmetric key usually that actually encrypts the secret itself. And then the encryption key itself is encrypted in a key encryption key. So this is the pretty standard model you see everywhere if you are involved in decryption standards. If you've ever evaluated how Lux works for instance on Linux. This is a pretty standard model of how things work. And then what we do is we have this key encryption key be usually something like a password. So we see here from XKCD correct battery horse staple wonderful password. And then we share that password around with a bunch of people. Now obviously this is the system that we're trying to move away from. And we don't like the fact that we have to share this key encryption key with everyone. Because of course one of those people goes rogue. Then we've lost our data. So what we do instead is we create a much stronger key. Something that is cryptographically strong. And then we store it in an escrow remotely and when we want to be able to unlock our data we just simply fetch the key back from the escrow. Has everybody seen something like this? Raise your hand if you've seen a system like this. Am I done describing the architecture? Because it seems pretty simple right? Well unfortunately we have to encrypt this channel right? Because we can't just ship keys back and forth and so now we're usually doing TLS most commonly or GSS API in order to create an encrypted channel to be able to send the keys with. And then finally we're done. Now unfortunately we actually have to authenticate the escrow server because we can't just you know ship off keys to some remote entity and hope that it's the right person. So we have to authenticate the escrow and now we're done right? No, so we also have to authenticate the client to the escrow because we have to guarantee that when they fetch back a key that they can't just get any key that they want. They can only get the keys for instance that they pushed in or that the policy allows them to have. So at least finally we're done. Well unfortunately we actually need a chain of trust in order to do all of these authentications and the encryption layer. This is usually done through a certification authority with a route of trust there, perhaps many intermediary layers. Or this is done if you're using GSS API for instance this is done with a KDC. Well at least now we're done we have a very simple architecture oh I forgot about backups. So now we have to back up all of this state right? Because we've got all of these keys stored in the escrow and if we were to lose that data we are sunk right? Because all of our data is encrypted with these keys. So we've got to back up all of those keys but we also have to back up the entire route of trust on the left hand side as well. And then of course all of these backups have to be secure. So at least finally we have arrived at the standard escrow model and this is pretty much what you see. Tons of vendors are shipping products like this and if you've ever hacked together some kind of an automation for early boot unlocking your system most likely looks something like this. And it works really great we don't ever have any problems with this system at all. Oh wait so I guess Heartbleed would kind of throw a kink in this. We would be able to just read all of the keys off the wire as they were coming in. So we decided we want to do something but that's better. We've learned a few lessons from this architecture. First we learned that presuming that TLS will protect the key transfer is dangerous because all it takes is a single flaw in the entirety of TLS which is a pretty large specification in order to and a pretty large implementation as well. Any mistake there any flaw there can leak our keys. We also learned that the complexity increases our attack surface. So when we had all of these different entities doing these different things we realized that of course there's a lot of places to attack. We can attack the backup system we can attack the root of trust we can attack the TLS channel we can attack the escrow itself. And because of all of this we've also learned that escrows are difficult to deploy. Not only do you just deploy an escrow but you deploy everything that goes around it. Finally one of the things that we learned actually in user testing is that X509 is really hard to get right. So even if you've done everything correctly just the X509 part of it we've very often gotten you know malformed certificates we got certificates that were signed in properly all sorts of stuff that we've seen in the wild and so it's just very hard to get right. And our very simple system of just taking a key storing it remotely and fetching it back has suddenly become incredibly complex. So the question that we wanted to ask was can asymmetric crypto help us with this problem? So one of the things we realized in this process is that what we are actually doing is really a kind of a key exchange. Now I will ask you to brace yourself because math is coming on the next slide. So if you're allergic to math please stand up and leave the auditorium. So this is a standard Diffie-Helman key exchange. Is this readable by the way can you read it? No oh man I'm really sorry. So this is a standard Diffie-Helman key exchange. Each party generates a private key, uses a private key to calculate a public key, they exchange their public keys and then they can both calculate K. So is everybody pretty familiar or at least has heard about Diffie-Helman how it sort of works? Okay. So I don't want to go too far. Okay so we wanted to, we wondered if we could take ECVH, elliptic curve Diffie-Helman, and if we could just essentially make our unlocking process a key exchange. And so on the left hand side you see a Diffie-Helman but it's just sort of rearranged. Nothing on here is mathematically any different than Diffie-Helman. We're just doing the steps in a particular order. So nothing on this slide is different from Diffie-Helman. On the left hand side we have the provisioning step. The first thing that happens is a server generates a private key, uses the private key to calculate a public key, and then shares that key to whomever would ask for it. So now you can get, as the client you can get the public key. You can either get it by contacting the server, you can get it by passing it offline somehow, but the client is able to get the server's public key. Now the client does its bit when it wants to encrypt the data. So the provisioning is the encryption side. So the client then generates its own private key, generates a public key, uses the private key to calculate a public key, performs the Diffie-Helman exchange, and gets K. K is the key that's then used for encryption. Once encryption is done, we then discard K, and we also discard the client's private key. And what this means is that the client can no longer calculate K. It doesn't have K, and it can't calculate it. We do however retain the public keys, S and C. S is the server's public key, and C is the client's public key. And then when we want to do our decryption, we can take our public key and we can send it to the server. The server does its half of the Diffie-Helman and calculates K and sends K back to us. Now this is fantastic because this is a lot lighter than what we saw on the S-Pro model, and in fact the server notice has no state whatsoever. The server is just a key. That's all. Unfortunately this mode is completely insecure because if you share a key, C, excuse me, the client's public key on the network, then anyone can take that key and can calculate K by asking the server to do it. Similarly, the K, the key that we actually want to protect, is now coming back over the network in plain text, and of course we don't like that either. So we have some weaknesses. K is revealed to any passive attackers. With C, so if they store C, then they can later do a replay and they can get back K. And third, the server learns both C and therefore K. And what we want to do is we want to actually create a system now where C, the client's public key, is no longer a public key. It is a private key. And we can actually do this with an algorithm, a very slight modification to this algorithm that was invented by myself and Bob Rayleigh at Red Hat. And the way that this works, if I'm going to flip back and forth so you can see, on the left side provisioning, notice that nothing changes. So on the provisioning side we're just doing Diffie-Hellman. The only changes are on the right-hand side. So it's exactly the same as it was before. The client calculates K with the Diffie-Hellman encrypts data with K and it throws away K and C so it can't calculate K anymore on its own. But it retains S and C. And then, when we want to do decryption, the client generates a new key pair. This is an ephemeral key pair and it's generated every single time the client wants to do decryption. So it doesn't happen in an encryption time, it happens at decryption time. The client generates a new key pair. So we have a private key and a public key E. We add the key C and the key E together. We send the result, which we've called X here, to the server. The server performs its side of the Diffie-Hellman, sends back the result, and then we are able to subtract out the ephemeral key, essentially, from this calculation. And there's some very simple math down here. You can go online, by the way, and see these slides later if you want to look at the math closely. The end result, of course, is that C is now private because E is private. So the server gets something that just looks like a random public key every time it wants to perform its side of the Diffie-Hellman. It has no identifying information about the client at all. The server performs its very simple operation and returns the result, and since the result has the ephemeral key still mixed in, nobody on the wire can replay this, or rather they can replay it, but they can't ever get K out because they don't have the ephemeral key. So in order to... One thing that's important to note is that in order to keep C private, then both the public and private ephemeral keys must be private as well. So the end result of this is a system where instead of having an escrow, instead of storing data in a remote server, we just simply generate a key during our encryption. We generate a second key during our decryption step, mix them together, send them to the server, and get back the result. And the result of this is remarkably fast. So if you think about a TLS connection, the very first thing that TLS does is it negotiates what group it wants to use, and the very second thing it does is that it does a Diffie-Hellman exchange. This is as light as just the Diffie-Hellman exchange in TLS. No encryption is needed over the wire because it's just simply a public key exchange, and no state is required on the server, so we don't have to do fancy backups and all kinds of stuff. There is one other alternate way to deploy this, which is that you can actually stick the server's key inside crypto hardware. So you can burn it into a TPM. You can put it in an HSM. The server does not have to have any access to the material at all. And specifically, if you're storing the key in crypto hardware as a backing to the server, then a compromise of the server only leads to temporary access of the keys, but not permanent access of the keys. So they never learn what the private key is. The private key is always stored in hardware. An attacker who compromises the server can only just kind of use it temporarily for a little while, and then you kick them out again. So if we compare these two systems, on the left-hand side, we have our... the property we're talking about, then we have the escrow, and then we have the McCullum-Ralier exchange. So when using an escrow, server presence during provisioning is required because you actually have to have network access to push the key into the server. On the other hand, with the McCullum-Ralier exchange, it's actually optional. As long as you have that public key offline somehow, you can do the full provisioning, full encryption entirely offline, and then only... the server is only required when you want to do decryption, so during the recovery step. So that's the same for both the escrow and for the McCullum-Ralier exchange, which is exactly what we want. We want the data to only be automatically decrypted when the server is available. The escrow, however, also has to have knowledge of all of the keys, and so it becomes the essential point of attack. In the McCullum-Ralier exchange, the server doesn't know any keys and is not really a... it's not really a desirable place to attack. Similar with key transfer, that's required in an escrow because we have to actually send the key over the wire to the remote and then get it back. But with the McCullum-Ralier exchange, we require keys other than public keys. So the only thing that's on the network is public key data, which a passive attacker cannot get. When you have an escrow, you also require client authentication, which is not required in the McCullum-Ralier exchange. We require transport encryption for the escrow but not for the McCullum-Ralier exchange. And then finally, end-to-end encryption, which is another whole set of problems we didn't talk about earlier with an escrow, is very difficult to implement. On the other hand, for McCullum-Ralier exchange, it's just not needed at all. You do not need end-to-end encryption. So there's a server that implements this. The server is called Tang. And it's available at github.com slash latch set slash tang. It's a small server-side daemon. It's very simple, just HTTP and Jose, which we'll talk about in a minute. And it's very, very fast. We can do about 2,000 requests a second on medium hardware. And that's without any attempts to scale it up. That's just single-threaded, et cetera. So it's extremely small, minimal dependencies, and it's available on Fedora 23 and later. And of course it's open source, so you know, put it on whatever distro and we're happy to help you. So installing a Tang server is relatively easy, at least on Fedora for right now. DNF install Tang. That gets you the server. And then use systemd to enable two unit files and then generate two keys. And you're off to the races. Now you may want to scale this up, put it behind a patchy, you may want to think about your deployment model. So there are definitely some more complex scenarios. But if you want to get up and running very quickly for testing, it's just simply these five commands. We've only been talking about the server up until this point. And we have not been talking about the client, but we need to talk about the client as well. So we have an application called Clevis on the client. So it's also available github.com forward slash latch set forward slash clevis. This is a decryption, automation, and policy framework. It has minimal dependencies as well. It has early boot integration and gnome integration, and it's available in Fedora 24 and later. And here's an example of doing some encryption with Clevis and Tang. So DNF install clevis gets you the Clevis application. You can just echo some plain text into the clevis and crypt command. You specify you want Tang as your backing policy, and then you give it a configuration, which is just a little JSON object right now containing just the URL of the server. And in this case, since we did not pass in the public key, it fetches the public key from the server and asks you if you want to trust it, similar to what SSH would do. Finally, if we cat the output data, we actually see that it's a JSON web encryption, so this is a standard data format. And when we want to do decrypt, we just simply pass that same blob back in to the decrypt command and out comes our plain text. Notice that I did not actually type anything in, because the decryption was automatic. Now if I stop Tang and try to do the decryption step again, then we actually get failure and no plain text comes out. However, Clevis does not use only just Tang because as I said, it is a pluggable automated policy framework for decryption. So we can actually do it with an escrow as well. In this case, we are using the Custodia API. So if you don't know about Custodia, that's also interesting you can Google it. It's essentially a secret as a service API. So in this case, we are encrypting the same data. We are pushing a key into the escrow, pulling a key back out of the escrow for decryption. And if the server is not available, then we can't decrypt. But this does have the same downsides as the escrow model. But a lot of people already have an existing escrow and they may want to migrate from it, or they may have specific cases where they actually need to run an escrow. So then there's actually just another simple command to bind a lux disk. So if you have a block device that's encrypted with lux, this basically should look exactly the same as what we saw on the previous slides. The only difference is that now we're passing the device, the block device itself, to the clevis bind lux command. We fetch the public key from the server. We say, yes, we want to trust it. Then we enter one of the lux keys. And then internally what happens is we generate a cryptographically strong random key that's the same size as the master key so we don't lose any security properties. And then we encrypt that key using clevis and then at boot time when we want to recover that, unlock that disk automatically, we just simply decrypt the key, pass it to lux and we're off to the races. So there's a middle command in here, lux meta show, which actually will show us all of our lux slots and the meta data that we've stored in the lux header related to this. So this is a related project we'll talk about in a minute. So for root volume unlocking, we just install clevis dash draket and then run and draket dash f to rebuild your init ramfs and then reboot. You only have to do that once because we need to get our code inside the init ramfs. And we were actually talking about having that by default so that you don't even have to do that step. It'll be in the default init ramfs. And then for removable storage like USB keys where you would want to say have a gnome desktop and plug in your USB key and have it automatically unlocked, we have the clevis dash udisks to package which you can just install. No other configuration is needed. You just insert your drive and then it unlocks as long as the server is available. However, we've only covered automation up until this point. We still haven't actually talked about policy and policy is where things get very interesting with clevis. So we actually have a plug-in which we call a pin and this is the Shamir secret sharing pin and this actually allows us to take a key, divide it up into a variety of keys and then have a threshold to recover it. So in this case, we take our master key, we divide it up into five keys and then we have a threshold, maybe two. And as long as we have two of those fragments, we can unlock the data. Shamirs can also be nested as well. So you'll very quickly notice that we can actually use Shamirs to create a hierarchical unlocking policy. So let's look at how this might work in practice. On the case of a simple laptop, you may want to encrypt your disk using Shamirs with two passwords, one for the administrator of the laptop and one for the user of the laptop with a threshold of one. And in this case, either password will unlock the disk. Now we want to have an automated laptop, so we've kept the threshold the same. We've added an additional branch. Now we're talking to the Tang server. So as long as you can get to the Tang server, it'll unlock automatically. But if you're out at the coffee shop and you can't get to the Tang server, then you'll have to take your user password. But the administrator still has a password that they can use to unlock the system. And now everything we've talked about up until this point is doable today with Lux. But we're about to talk about stuff we can't do with Lux. So, for example, let's say we have a high-security system. And in this high-security system, we want to create a bunch of passwords. In this example, there's three. And we want to require two of them in order to unlock the volume. So this would be the sort of, you know, case where you have something that would be very, very dangerous and you want multiple people to authenticate before you can get to it. You can't do this today with Lux, but you can with Clevis. Well, not today, but very soon in the future you'll be able to do this with Clevis. So here's an example of a complex laptop policy. This is we have the administrator who has created a master code and printed it on a QR code and they lock it in a safe. And in the biggest disaster case, they can extract the hard drive out of the laptop, you know, plug it into some tool that they have, and they can use the QR code, scan it back in to recover the data. That's the master recovery scheme. But now we go down to a second branch and this branch further does Shamir's with a threshold of two. In this case, it means that both of our branches are required. So we have two branches. One is TPM and one is Shamir's secret sharing. So this means that if you're not using the QR code that's locked in the safe, the only way to unlock this system is that it must be in the chassis to be able to talk to the TPM. And then if that's the case, then we finally go to our last branch where we have a threshold of two. And here we have four authentication methods. We have password, we have YubiKey, we have Tang, we have Bluetooth. By the way, Bluetooth here is actually would just be the Tang protocol, the McCullum Relay Exchange over Bluetooth which we're working on. So in this case, you've got a Bluetooth beacon and you're on the corporate network so you have Tang available to you. You turn on your laptop, it goes completely automatically without any user intervention at all. On the other hand, let's say you go to visit your friend on another floor of your building and you're still on the corporate network but you're not near your desk. Well, in this case, you'll still be able to get to the Tang server but you won't be able to get to the Bluetooth. So we'll have to do one of the other options. Either you can press the button on your YubiKey or you can type in a password to get in. Now let's say that you actually take your laptop down to the coffee shop because you like coffee and you don't want to be in the office. So you're down in the coffee shop, you open up your laptop, it turns on. Now you're not near your desk so you don't have the Bluetooth. You're not on the corporate network so you don't have access to Tang. In this case, you have to enter both your password and press your YubiKey in order to get access to your desk. And the important thing here is that I as a software developer did not choose this policy for you. You got to choose what the best policy was for your scenario. So here's an example of just a basic Shamir's with Tang. In this case, we're using it to provide high availability to two different Tang servers. So we use Shamir's. We say the two pins we want are both Tang and we specify their configurations there. There's a threshold of one. In this case, we trust two advertisements because we're actually talking to two different Tang servers with two different public keys. And we can decrypt the data automatically. We can stop one of those servers and still decrypt our data but as soon as we stop the second server, we are unable to decrypt the data. So let's explore the ecosystem a bit. One of the dependencies that we have is a project called Jose. I'm actually giving a talk on Jose in the security track in like an hour or so. So if you're interested in learning more about Jose, come to that talk. Jose stands for a JSON object signing and encryption, which is a set of RFCs. So this is actually a standard data format. And it's a C library and a command line utility for doing all of the encryption and signing and key generation for that data type. And the bottom line is that it's just user-friendly standards compliant crypto. In this case, we wanted to use this because our protocol was over HTTP and what's better than JSON plus HTTP. We also have another dependency called LuxMeta, which is something we wrote as part of this project. LuxMeta is a utility to store metadata in the Lux version one header gap. And so the background of the story is that we wanted to support automatic unlocking of Lux1, but there was no place to store the metadata that we needed to actually do this, to do this restoration. And so there was actually a gap between the end of the Lux header and the start of the encrypted data. And so we wrote this utility called LuxMeta that commandeers that area and we stick metadata in there. This, we don't do any parsing of the Lux header ourselves. Everything is offloaded to the upstream LibCrypt setup utility. So there shouldn't be any problems with this and upstream is aware of this program. And so you can actually see an example of using this here. We want to store the metadata high in a slot with a given UUID, and then we load it back. And then if we try to load a different UUID from that slot, we get an error because that's not the type of data in that slot. So fairly straightforward, fairly simple, and this is where we actually store the encrypted data that comes out of Clevis. In the near future, these are things that are pretty high on our to-do list. So for the Jose project, we want to add PKCS11 support. This will actually allow us to do all of the stuff that we've already talked about, but using actual crypto hardware. So you can store private keys, burned in the hardware that can't be extracted. And we'd like to add some Python bindings for Jose or any other language that you might want to use Jose in. We would also like to support additional crypto back ends and maybe some additional algorithms, although we do support all of the algorithms that are specified by the RFC. There are a few others that are not specified that are in common use that might be interesting to implement. For Clevis, I'm at work right now adding a password pin, which is actually much more complicated than you might expect. And this will allow you to mix passwords in with your policy. Once we land PKCS11 support in Jose, then we will have a PKCS11 pin in Clevis so that you can actually bind your client-side data to hardware that's inserted, like a TPM, for instance. Support for... We would like to have support for non-root, non-removable volumes. The reason we don't support this right now... This is, by the way, volumes that are basically built-in that are there at boot time, but they are not your root volume. We don't support this right now because of a mismatch of expectations between us and SystemD, which we're actively working with the SystemD people about. So that will be coming in the near future. We'd like to add X4 encryption support. So X4 also allows you to do per-directory encryption. And we would like to basically do the same thing there, where we encrypt the key using Clevis and then store the metadata in an extended attribute on the directory. And for unlocking them, then we can just perform the same exact sort of steps that we do for Lux. And then finally for Tang, we would like to modify our algorithm slightly to support binding IDs. This would be optional, but it will also sacrifice anonymity. So it's a trade-off here, which allows you to do revocation, which is our second feature that we'd like to add. So in other words, if you want your clients just to be able to bind, you don't care about revoking their keys, then you can just use this protocol as is. But if you want to be able to actually revoke a specific binding, then we need to be able to have cryptographically sealed binding IDs as part of this process. And of course, patches are welcome. So if you'd like to contribute to our project, please do. And this is where we get the names from, by the way. We have Clevis and Tang. It's just a traditional joint. So the U-shaped bit is called a clevis, and the block-shaped bit is called Tang. And the thing that binds them together is called a clevis pin. So that's all I have. Thank you very much. Are there any questions? Are there any other questions while we're working out the microphone situation up there? All right. Hello. Hello. Thanks. Very interesting. Just two small questions. Do you see any limitations, situations where you wouldn't want to use this algorithm? And the second question is, do you see any other applications that might be interesting, like unlocking your house, for instance, things like that? So, yeah, those are two great questions. The one is, do we see any limitations with this? And the second question was, do we see any other applications of this? And so the case where you may not want to use Tang is if you're working in a heavily standardized environment and you're only allowed to use certain algorithms and our algorithm isn't on the list. The other case where you might not want to use Tang is where you need revocation of some kind. And that's because we don't implement it yet, but we are going to be implementing it in the near future. So that case will fall off of our list. We've also started to open some conversations with some different standards bodies about actually standardizing the algorithm and making sure that it's available in those cases. So, no, I think that once we sort of cross all of those hurdles, I don't think there's any reason not to use the application. The only other reason I can see that somebody would not want to use it is because it is new crypto and people are always rightly concerned about using new crypto. And so this is precisely why we're also pursuing a paper that goes through the formal methods to prove the actual algorithm itself. So once this is done and generally accepted in academia, we shouldn't have any other limitations. As far as the other applications for... I assume you're talking about the McCollum-Ralier exchange algorithm. It's actually very, very interesting because you can use it for any case where you want authentication in which the authenticating party gets a cryptographic key that they can decrypt data, which I'm not aware of any other system that currently does this. So one area where this would be very interesting, imagine, say, you have... your phone is doing the McCollum-Ralier exchange over Bluetooth. You walk up to your laptop and your laptop not only authenticates you, but now is able to decrypt, say, your key ring with all of your other keys, like your SSH key and all of that other kind of stuff. So there are some really interesting applications of it more broadly, but we're just trying to get this one out the door first and then we'll work on the other ones. So thank you. There's some questions down here in the front. Oh, up here. Yeah, go ahead. Hello. Thank you very much. Very interesting concept. Those more complex policies that you talked about that you can now implement, how do you configure them? Is there, like, a scripting language or the configuration file format that you configure them with? Yeah, so the question was, how do you configure the more complex policies? And the answer is that what essentially happens is when you do your encryption, you specify your root, the root of the tree, and then in the configuration that's passed in the JSON blob will be the entire hierarchy. So it's all defined at encryption time. And the thing that's really interesting about this is currently people who are thinking ahead of the game and thinking about policy, they're typically thinking about a secure process which has access to the symmetric encryption key and then which manages access to it based on some policy. Where Clevis is really different from this use case is that we actually validate that policy cryptographically. So there's no special privileged process anywhere that can do the decryption. As long as you can fulfill the policy, you can get the plain text back, but if you can't, you can't. Thank you very much. You spoke about the key exchange and that the ephemeral key is mixed in. So my question is, have you done any research into how many times you can send the same key across and basically looking at a whole series of these transmissions, be able to pick out which parts are static across all of them so that you can basically discard all the ephemeral keys and get the non-phemeral part? Yeah, so there's nothing leaked as part of this operation. The only thing that the server ever receives is random data. It's not like we're doing this in the... We're doing this actually inside of the elliptic curve realm. So it's just another point on the curve. So basically you have as many points as there are on the curve, which is a lot. So in the case of a 256-bit curve, it's 2 to the 256, which is considered secure by all current standards to my knowledge. Yep, somebody... I don't know who's next. I wanted to ask about those policies. By the way, it's tremendous progress over key escrow mechanisms, although one of the strengths of the key escrow mechanisms is that the policies are dynamic. So you can actually modify them after the key is encrypted. And so you can authorize, for example, more users than you anticipated. Yes. So how would you... As far as I understand, the Stanclever scheme doesn't currently support that. And I was wondering if you see a way to extend it with support for something like that. You have to have access to the client, and you have to essentially decrypt using the policy and then re-encrypt using a new policy. So there's no way to essentially manage it like there is in an escrow, but there's a lot of other security benefits. So it is sort of a trade-off. Yeah, thank you. Thanks for the talk. It was really interesting. So one interesting use case would obviously be to try and use this as the root of trust for a machine. As what? I'm sorry. To use this authentication method as the root of trust for a machine. Yes. Are you looking into building onto this policy mechanism, further policies to say, well, I've now decrypted the hard drive. Now I can authenticate the service or this device. Yes. How are you planning to implement it and how do you foresee that working? It's not currently on the roadmap. It's something that's theoretically possible, but I have a lot of other stuff on my plate right now. So when I get all of that other stuff off my plate, then I would like to think about that, yes. Daniel. Yeah, I thought I have two questions. One is it seems really easy to use. Is it just as easy? I hope so. If it's not file a bug or a patch, we're glad to take either. Yeah. And it's already used in production somewhere, or is it just being developed? So we just released this about two months ago in Fedora, and we are currently attempting to stabilize it. So I don't know anybody who's using it in production, but I know lots of people who are using it in pre-production environments. Looks great. Thanks. Up here somewhere, I think. Any more questions? Hi. Another question from me. Sure. How does that relate to attribute-based encryption schemes? Is there attribute-based encryption schemes? And do you think that those two approaches can be combined? I would really like to see them combined. I don't see any reason why they can't be combined. We don't really have any... To my knowledge, we don't have any usable implementations of attribute-based encryption. It's all currently theoretical. So somebody would have to write it, and then we can implement it. So if you'd like to write it, please do. Any more questions? Thank you very much.