 So I didn't quite get the honor of being the last speaker, but I guess I can unlock that in cheap in some other way. Yeah, this is John Work with Martin Outbreak and Kenny Penison. Just a quick outline of the next 20 years minutes. Can you hear me here? I should have gone closer. I'm a bit torn for this. Here you go, maybe it's better. A quick outline of the next 20 years minutes. So first we'll go over some motivation. And then I will introduce to you the InterMAC, which is the library built. And then I will show how we use the InterMAC to implement new SSH encryption schemes. And I guess I have to start over, the InterMAC. There I go. So you all probably know and use SSH. It's a very widely deployed protocol that protects a large amount of traffic. The SSH transport layer protocol, which is called the binary packet protocol, defines the packet format. And the cryptographic processing you do on them. It provides the fundamental security guarantees of SSH, which is confidentiality and integrity of data. But SSH actually aims at going beyond those fundamentals. So RFC 4251, which defines the overall architecture of SSH, lists a number of other security guarantees that SSH wants to provide. And we wanna focus on two of these, denial of service and traffic analysis. And we're gonna consider these as properties of SSH encryption schemes. And by doing that, we can actually formally capture what it means to be secure against denial of service and traffic analysis. So the tool that we are going to use with this is a work by Baldriva, Degrabili, Patterson and Stam from 2012. So they introduced the notion of symmetric encryption schemes supporting CypherTex fragmentation. So how does this work? So let's say that Alice produces a CypherTex and sends it to Bob. So the normal assumption you're making is that Bob's received this CypherTex in its entirety. You can sometimes you also call this atomic delivery. But that completely neglects that when traffic or data traverses networks, there's a chance of arbitrary fragmentation. So the CypherTex-C might arrive at Bob in fragments, and you would call these CypherTex fragments. And it's then up to Bob to somehow encrypt these fragments but still arrive at underlying message. So it's this induced fragmentation that BDPS calls CypherTex fragmentation. And that's what we're gonna use to formally define these security properties. So BDPS together with Albrecht, Diabeli, myself and Patterson defined a number of different security notions in this setting. There are the fundamental ones of confidentiality and integrity, but also two more advanced ones that it's called boundary hiding and DOS. I will give you a flavor of how these works but I'm not gonna venture into the nitty-gritty details. So boundary hiding is going to capture security against traffic analysis. And it essentially says the following. So if the adversary is giving a sequence of CypherTex, then it's impossible for the adversary to delineate the CypherTex boundaries in this sequence. There are two versions of this. There's a passive version where the adversary only has access to the encryption oracle. And then there's an active version where the adversary also has access to the decryption oracle. The DOS notion is gonna capture security against denial of service. And it's parameterized by a parameter, a lambda. This notion is very, it's kind of technical, but it essentially says that no adversary can make Bob hang or wait by making him expect more than lambda amount of CypherTex. So this essentially says that the lower the lambda is, the better Bob is at detecting denial of service attacks and the faster he can respond to things. So SSH supports a number of different encryption schemes, all listed here. And ADPA, ADHP did a study where they analyzed these schemes with respect to the security notions we have just seen. And it turns out to be a pretty negative study, probably not as bad as Brexit, but close. So only Cha Cha and Cha Cha Puli and Encrypt and Mac meets the boundary hiding, the passive notion for boundary hiding. However, these two schemes has other noticeable drawbacks in the context of SSH. First of all, Encrypt and Mac is not generally secure, which was both proven by Albuq Patterson and Watson in 09, but also by ADHP. And I guess we can all agree that encrypting or decrypting on unverified data is probably not very good. All right, so even though Cha Cha Puli is a very great scheme, it can utilize AES in 26, which is pretty bad in some popular context where SSH is used. So we see that none of the current SSH encryption schemes adequately provides the desired security properties. So two natural questions to ask are then, can these security properties be realized simultaneously in SSH and at what cost? Oh no, you saw all of it. I guess I'm gonna finish now then. All right, so to answer this question is maybe not surprised that we're gonna start out with looking at the scheme called Intimate. So this scheme is pretty simple, I'm gonna explain how it works. So giving a message, this message, you first split it into equal sized chunks of length N counting in bytes. Then this N you call the chunk length. You then encode each chunk with a byte zero, except the last chunk which you encode with a byte one. You then encrypt each encoded chunk and you compute a Mac over it. But you see that to be able to prevent reordering attacks, you have to include two counters into the Mac computation. Okay, so to arrive at the final cyber take, you just concatenate everything together. And to decrypt, you just shift your gear into reverse, you verify the Mac, you decrypt, and then you inspect the encoding byte. And if this encoding byte is the one, you have recovered your plain text. All right, so this scheme was also proposed by BDPS and they proved that it achieves confidentiality, integrity, denial of service, and dos. So we wanna go ahead and implement this, but before we did that we realized that BDPS kinda cheated because this scheme only supports messages that is a multiple of N, which is not really good in practice. Luckily, there's an easy way to resolve this. We just apply some padding. Now the padding scheme we're gonna use is pretty simple. If the last byte of the message is zero, we just pad it once, and if it's not zero, you just pad for zeroes. Well, it's pretty simple. Now we did some other changes to the Intimac scheme. We also didn't want to add padding if the message was already a multiple of N. So we encode this information in the last encoding byte of the last chunk. We also replaced this encrypt and MAC construction with more modern, non-spaced, authenticating encryption schemes. By doing that, we somehow need to figure out a way to include the counters to prevent reordering. We do this by generating the nones from the counters. Oh, and then we proved that this modified Intimac scheme achieves all the same security notions, confidentiality, integrity, boundary hiding, and dos. All right, so we went ahead and implemented this and we called the implementation LibIntimac. It's a C implementation, and we kind of tried to make it a fun library to use. So we have a small API, which should also make it easier to use. We completely removed the responsibility of nonce management away from the user, and it handles all this internally. We also have a feature of algorithm agility with respect to the underlying non-spaced encryption scheme. Right now, we have code for ASTCM and CharterPully, and you should know that you shouldn't, you shouldn't, so I overload the naming here. You shouldn't confuse these two with the SSH encryption schemes of the same name. The SSH encryption schemes, the definition of those, and the naming use of those includes more. It also includes encoding and processing of packets. So another thing I would mention is that we tried to identify attack vectors that goes beyond the formal model and implement countermeasures against them. So I'll go into a bit more detail of one of these, and it kind of shows that, even though Intimac has a really, really simple description, you kind of have to keep track of a lot of things when you have to implement it. So one issue we identified was with the decryption algorithm. So let's rewind a bit and go back to the boundary hiding notion. So we call it, it says that the adversary cannot delineate cyber-text boundaries in a sequence of cyber-texts here. But I think the adversary can do is to measure the response time from the decryption algorithm of Bob. And this is not captured by the formal security model. So if this response time is somehow a cyber-texted boundary dependent, then Bob, sorry, the adversary might be able to delineate the cyber-text boundaries. So to combat this, we have to make sure that the execution time of the decryption algorithm is independent of cyber-text boundaries. So one source of non-uniform response times can come from padding removal. So remember you do this when you decrypt the last chunk and you inspect the encoding byte. And if this encoding byte tells you that there's padding, then you have to remove it somehow. The first thing you have to do is to figure out how much padding there is. And the most optimal way to do this is probably just to start from the end and then do a backtrace until you find a byte that is different and never reveal the amount of padding you have. However, obviously, this takes time proportional to the amount of padding, which kind of reveals the boundaries, the cyber-text boundaries. So, I'm moving this. So we implement a constant time padding removal function and what it does is that it searches through the whole chunk. So it visits each byte exactly once. And we also invoke this algorithm of all chunks of all messages, not to leak which chunk you're removing padding from. So obviously doing a linear search over all chunks of all messages kind of must add some overhead. So we did a study to show how much that is. So we decrypted an eight-kilobyte message for different chunk links. And where we implement a decryption algorithm with constant time padding removal and another one with non-constant time padding removal. And this simple study showed that using a constant time padding removal algorithm slows the decryption down with a factor between four to five, which is kind of significant. But we wanted to have maximal security so we still implemented the constant time version. Okay, so we identified additional timing channels of the same format and we implemented countermeasures against them. However, in the code, there are still some branches that depends on cyber-text boundaries. So we cannot really claim that we have a full constant time decryption. We think there are still some, a lot of other problems in this area. And I guess I can use that as a shameful plug to make you read the paper if you want to know more. So we also looked at how the performance is for lift-intermag. And kind of there's some extensive benchmarking. We did it for four different message lengths and this shows the decryption algorithm where we use ASTCM as the internal non-spaced encryption scheme. The y-axis denotes the chunk length and the x-axis denotes the performance measured in cycles per byte. And if you go through this chart, you will see that for each message length, the optimal performance you can achieve is between 1.4 and 2.5 cycles per byte. So it's not that bad. The story completely changes for decryption. So here you have a slowdown of a factor of 10. And much of that you can trace back to this constant time pattern removal. It slows even more down if you use chapter pulley, which slows it down with a factor between 25 and 35. So obviously these measurements are done on a machine that supports AES and 26. So I mean, that's why chapter is quite a lot slower. However, we didn't think a lot about speed, so we still think there's still a lot of room for improving these measurements. Okay, so now we have a solid scheme on implementation of intermag. And we want to see how it performs in SSH. So to do that, we implemented intermag-based encryption schemes in OpenSSH. So this required us to do a number of changes to OpenSSH. So this is the SSH packet format. It contains a length field, padding length field, admissions system on a padding and stuff. But most of these fields actually comes redundant when you use intermag. You don't really need them to process packets anymore. So we removed them. We also implemented standalone code path for intermag encryption and decryption. This first of all circumvents some really bad history of some of their OpenSSH code. We also needed that because intermag is kind of really different from some of the other encryption schemes that OpenSSH supports. And for that same reason, we had to implement some non-standard buffering of the output from the intermag decryption algorithm. So if you sum all this up, this kind of shows that if you wanna integrate intermag into your application, it can become quite complex, unfortunately. All right, so we did two studies to see how well intermag performed in SSH. So the first study, we transferred 50 megabyte using SCP and I know SCP is not really good, but that's what we have. And we wanna use SCP because it's an SSH-based transfer protocol. So we did this between two EC2 instances in two different availability zones in AWS. And by doing it between two availability zones means that the distance is really short or also the network is extremely fast. But the first optimization, the first observation you can make is that the intermag encryption schemes that we implemented performs kind of on the same level as ChatterPoly, the ChatterPoly scheme in OpenSSH. And ChatterPoly is currently the default that encryption scheme that OpenSSH use. A general observation you can make is that this performance seems to be computational dependent. This kind of changes in the second experiment we did. So here, instead of doing it between two availability zones, we did it between two different regions. So this means that the distance greatly increases but also the network becomes kind of not so good. And it's clear to see that performance is no longer computational dependent, but it's probably more network dependent. And it has a really great similarity with this other graph over here, which shows the cybertext expansion for each encryption scheme in OpenSSH. So for the existing schemes, this is just some of them, there are many more. Those, it's quite uniform. It's not much difference between the schemes. This changes completely for the intermax schemes where we have a great variety of different cybertext expansion amounts. And the reason for that is because of the padding and how this padding or how the messages fed from this SCP application down to the transport layer interacts with the chunk length from this padding, which creates this really weird distribution. But we observed the cybertext expansion between 10 to 35% for the intermax schemes which is quite a lot. It's also creates this funny thing there. Anyway, to conclude. So the answer to the first question is yes. We implemented Intermax. We also tried to identify issues that goes beyond the formal security model. We think that our Intermax based encryption schemes in OpenSSH kind of captures the desired security that SSH wants to provide a bit better than the existing ones. Using Intermax also adds some cost or overhead. So we observed increased complexity in integration and implementation. This affects performance to some extent, but depending on your use case, this might or might not be tolerable. You can find our code on GitHub or you can hit us up on Twitter. Thank you. Questioned. Don't you think that having this new library could also be a good opportunity to implement some of the CIS algorithms and do you have plans for that? That would be a no. No to which question. A plan or isn't it a good opportunity? None of them. Maybe. I mean, everyone can implement it. It's pretty easy to implement new schemes for, let's go all the way back. There we go. It's pretty easy to do this in the Intermax. So I made it easy for other users to actually implement schemes. You just have to program against an interface and then you can quickly use it. So I mean, anyone is invited. Thanks. If there are no further questions, then thank the speaker again.