 All right. Thank you. Good morning, everyone. So I create TLDR. We implemented a new, not a new, we implemented the symmetric encryption scheme called InterMAC. And this is why and how, and whether it's useful in practice. So this is our timeline for the next 25 minutes. I'll first go over some motivation. And then I will introduce you to InterMAC lib. And we will use InterMAC lib to implement a few InterMAC-based OpenSSH cyber modes and then measure the performance with respect to or compare the performance to existing OpenSSH cyber modes. So I use cyber modes, cyber modes as equivalent to a TLS cyber suit suite. All right. And then we're done. All right. So we all know that symmetric encryption is a hugely important tool for achieving, for example, confidentiality of data. But how do we model security of a symmetric encryption scheme? AE or authenticating encryption has emerged as the defective standard that symmetric encryption schemes should satisfy to be considered for practical deployment. But AE or other standard cryptographic security notions all have the same underlying assumption. They assume that the ciphertext, when it's sent to Bob, arrives in its entirety. And we also assume that the entire ciphertext is available when decrypting. But is this a good approximation? In 2002, Belay, Kona, and Pempe proved that CBC mode in SSH is secure. But then in 2009, Albrecht, Patterson, and Watson presented a plain six recovery attack against CBC mode. So this is kind of odd. So how did this happen? When data packets traverse networks or are being processed by applications, they're subject to fragmentation. So let's assume that Alice, there's a cloud here, but it's not shown. So let's assume that Alice sends the ciphertext to Bob. This ciphertext might arrive to Bob fragmented. It's then Bob's task to decrypt using the ciphertext fragments and somehow assemble the original plaintext. So we'll call this ciphertext fragmentation. Implementations must cater for this feature, and protocols like SSH contains a length field in a packet to assist the receiver in decrypting. And it's the presence of ciphertext fragmentation that allowed Albrecht, Patterson, and Watson to mount an attack against CBC mode. On the other hand, it was the lack of catering for ciphertext fragmentation in the model of Belay, Kona, and Pempe that made it possible for them to prove that CBC mode was secure. Luckily, there is an existing framework where you can study some major encryption schemes in the presence of ciphertext fragmentation. And this was first presented by Balduriva de Gabrieli Patterson and Stam in 2012. I won't go into the technical details about this framework, but instead I'll give you a short tour of the security notions you can define in it. So you all know the standard confidentiality and integrity notions as in CCA or in Ctext. This does not cater for ciphertext fragmentation. But in the framework of PDPS, you can define even stronger confidentiality and integrity notions. You can also define more elaborate notions. And I will talk about two here. The first one is boundary hiding. So let's assume that Alice encrypts two plaintexts and gets a ciphertext C and a ciphertext C prime. And she now sends these two ciphertexts to Balduriva. What Eve will see in the network is just a long string of bytes. The boundary hiding notion BHSFCSA formalizes Eve's ability to tell which part of this ciphertext of this long string of bytes is C and which part is C prime. Protocols such as SSH tries to achieve boundary hiding by, for example, encrypting a length field or having an option of adding a random amount of padding. The second notion is a notion that captures a class of denial of service attacks. And this is best explained by an example. So this diagram up here is the cryptographic processing of an open SSH packet using an encrypt then mic cipher mode. Using such a cipher mode, you cannot encrypt a length field. But this leaves an easy attack for Eve. Eve simply flips a bit, a certain bit in a packet length field, which indicates for the receiver that the packet is way larger than it actually is. This means that the receiver will wait or stall instead of received a lot of bytes, a kind of denial of service. So you can define a notion N does SFCFA that captures this kind of denial of service like attacks. The N, the notion is parameterized by an N that indicates the largest ciphertext that Eve can produce that is not detected as a denial of service. And to have a sensible security game, this N needs to be smaller than the maximum packet size often imposed by implementations. So it's these four notions that we want to consider in the BDPS framework. And it's these notions that we believe that the Mexican encryption schemes should satisfy but be considered for a practical deployment. So right-hand notions were defined by BDPS. They also defined the confidentiality notion, but a technical flaw was later fixed by Albreg de Gabelli, myself, and Panason in 2016. And we also introduced an integrity notion. So the question is now whether there exists a scheme that meets all these security notions simultaneously. And such a scheme exists, and it's called InterMAC. And it's constructed in the following way. So giving a message, first split the message into equal size chunks of size N minus 1, where we count in bytes. Then encode each chunk with a byte 0, except for the last chunk which is being encoded with a byte 1. Then encrypt each chunk that gives a ciphertext. And then compute a MAC over each ciphertext where we also include a chunk and a message counter. The chunk counter is incremented for each chunk, and it's being reset for each new message. And the message counter is incremented for each message. Then concatenate all the chunk ciphertext and MAC text to produce the final ciphertext. Decrypting is done chunk-wise and in an online manner. So when a receiver has received this first part, goes ahead checking the MAC, or verifying the MAC, then decrypting, and then inspecting the last byte. If the last byte is a 1, we have recovered the original plaintext. This was presented by BDPS, and as I said, it achieves all four security notions simultaneously. I won't bore you with the proof, but it sort of goes a bit of intuition. The intuition is pretty simple. For example, for boundary hiding, if the encryption scheme is $CPA, this means that it produces random looking ciphertext. And the MAC acts as a PRF. It should somehow be that these individual parts here look random, and then the whole thing also looks random. And we can also note that we have the knowledge of server security for each time we meet one of these MACs. All right, so the rest of the time, I will spend talking about how we implemented the scheme and we tested the security. Oh, sorry. And we measured its performance. But before implementing, we need to fix the limitation in the scheme. Because right now, the scheme only encrypts messages that are multiple of n minus 1. It's pretty simple to fix. We just add some padding. And the padding we apply is the following. If the last byte of the message is 0, we add 1s. If the last byte is not 0, we just add 0s. So pretty simple. To avoid having to add padding, even though the message is a multiple of n minus 1, we modify the encoding of the last chunk to indicate whether we need padding or not. We'd also do some kind of detective change and remove the encrypted MAC and introduce non-space-a-e schemes. When doing this change, you need to be conscious about correctly integrating or adding in the chunk and message counter, and also generating the nonce correctly. So given these modifications, we implemented InterMAC and created InterMAC Lib. So InterMAC Lib is a C implementation. And the overall aim was to make it safe to use. So safe to use is kind of a vague term. But we used it to mean that it should be very easy to use for a developer. And it should be hard for them to make any mistakes. So we have a very small API where you can just initialize an instance of InterMAC Lib, or you can encrypt or decrypt. And that's it. We also implemented complete nonce management. So a user cannot even input an nonce or cannot modify any nonces at all. We also have a feature of algorithm agility, which means that if you want to use a specific non-space-a-e scheme as the internal encryption function, you can implement that. And right now, we support ASTCM and Chachapulli as the internal A-e schemes. Let's look more closely at how we manage nonces. So when initializing an InterMAC Lib instance, the first thing I use in my stew, or one of the things you must do, is to choose a non-space-a-e scheme to use. This affects the way that nonces are handled. During initialization, we also initialize the chunk and message counters as zero. And we will use the chunk and message counters to generate a nonce. So the first part of the nonce is the 32 least significant bits of the chunk counter. And the second part is the 64 least significant bits of the message counter. And clearly, if the chunk counter and message counter are updated as I described earlier, the nonce will be different for every time we use it. Okay, so how do we do nonces when InterMAC is using Chachapulli? The Chachapulli A-e construction, close to follows, I would see 75, 39. And this construction needs a nonce that is 69, sorry, 96 bits long. Let's say the exact nonce we just created so we can directly use that. Also note that a block counter has nothing to do at all with InterMAC. It's something that is used internally in a Chachapulli. However, you must be very careful of updating it correctly, otherwise you lose all security. Okay, so how do we do nonces when InterMAC is using ASTCM? It's pretty simple, we just initialize ASTCM with the nonce for each chunk. This can maybe be pretty costly, but InterMAC uses OpenSSL to provide ASTCM support and we haven't really found a way to avoid this per chunk initialization. All right, so now we have a library that implements InterMAC. And we have a library that uses different internal nonce-based schemes. So we took the library and implemented InterMAC-based CypherModes in OpenSSH. And the reason for choosing OpenSSH is that we believe that by the design of the protocol actually wants the security notions I presented before. Well, currently none of the CypherModes actually satisfies them. At least not all of them simultaneously. So we implemented a song for them. And we implemented InterMAC-based CypherModes using both the AES, GCM internal AES scheme and the ChatterPoly internal AES scheme. So from now on, instead of saying InterMAC-based CypherModes I'll just refer to them as IMModes. And then here, the N indicates the chunk length and unfortunately, you cannot dynamically negotiate the internal nonce-based scheme or the chunk length when you do the handshake in SSH. So instead, you need to hard-code these into the code. There's two remarks I want to make about the implementation of these CypherModes. The first one is that when you use InterMAC actually the majority of the fields in the SSH packets becomes redundant. So maybe controversially, we removed these to save a bit of overhead. The second remark is that we implemented a standalone code path for InterMAC when it's being processed and it's doing this cryptographic processing. And the reason for that is that the packet processing in OpenSSH is quite complex and historically pretty buggy. And if you don't believe me, you can read this paper or this one or this one. That's probably so little more. Also, processing using InterMAC is quite a lot simpler than the normal CypherModes. All right, so now we have some InterMAC-based CypherModes. Now we want to see how they perform against existing modes. So we ran a test where we measured the throughput. We measured how many bytes, it's actually transmitted during the test. And we investigated how it is related to the chunk length parameter. And it's a bit of a methodology. So we wanted a somewhat realistic network setting. So we spun up an AWS instance in London and one in U.S. And we used SCP to transfer 100 megabyte file from London to U.S. And the first metric we looked at was how fast the CypherModes were to transfer this file or how much data that could send us again. The first thing I wanted to show you attention is the... Okay, you cannot see the rest of the one, but whatever. So the first CypherMode I wanted to show you attention is the bottom round here, which is AES encounter mode using HMAC and BeFi as the MAC. And this boots at a speed of approximately four and a half megabytes per second. And this compares pretty well to the best performing InterMAC IM CypherMode, which is using AES-TCM and then with a chunk length of 512. So the choice of this CypherMode might seem odd, but it's actually the most preferred CypherMode by OpenSSH servers on the Internet as we measured in 2016. And it's actually preferred by almost 60% of all OpenSSH servers. So our InterMAC CypherMode performs pretty well compared to this very popular CypherMode. The best performing CypherMode was the pure AES-TCM, which already existed in OpenSSH. But as you can see, the other IM CypherMode with AES-TCM actually performs somewhat okay compared to that. There's some different, there's a funny distribution in the performance though. If you look at the chunk length, or the mode with the chunk length 412.8 and 512 and maybe 4,096, it seems to relate to the chunk length. And this behavior is probably best described with the next chart, which shows how many bytes of CypherTakes is sent when we did this 100 megabyte transfer. So for the existing modes, there's quite a uniform amount of CypherTakes being sent. The story is very different for the IM modes. And the reason for this is the padding that we needed to apply and to make the scheme usable in practice or to allow arbitrary length encryptions. So the padding, the padding combined with the extra mag tags you need to include and the encoding actually means that we will send approximately between 10 and 35% more CypherTakes compared to the existing schemes. But the conclusion here is still that for this 100 megabyte file transfer, the IM mode still performed relatively well compared to the existing modes, but with a non-negligible expansion in the amount of CypherTakes. Even though there's the IM schemes actually used or had to apply more encryptions, I have to do more macking. All right, almost done. So I alluded you to the framework by BDPS, which provides a framework for starting to make some encryption schemes that cater for CypherTakes fragmentation. And we believe that this feature of CypherTakes fragmentation to be reflected in the security models. We then modified InterMag which satisfies all the desired security notions simultaneously and we implemented it and created InterMagLib. We then used our InterMagLib to implement IM-based CypherModes in OpenSSH, because we believe by its protocol design that it wants CypherModes that achieves the security notions. And our testing shows that you can achieve greater security by trading only a minor amount of performance. And furthermore, we believe that InterMag is the SSH packet protocol done right. Just to end with a bit of optimism, thank you for your attention. Questions? Thanks for your talk. So the 10 to 35% overhead is significant. I wonder how much of that is caused by the SCP application layer writing data not in the right multiple. And if you can fix that by having your library delay the actual encryption for a little bit to see if more data comes in. That's a good point. So the way you achieve the least amount of padding is when SCP, the data segment served by SCP to run online packet processing aligns well with the chunk length. That's right. But yeah, so this is a good example of when we design crypto, we should also consider what application is actually doing and maybe also what the network configurations are. Right. Yeah, thanks. Yeah, along those lines, did you measure the performance impact for interactive sessions where I'm just typing single byte characters? So I actually forgot to mention. These are only, we're a very small amount of tests and we plan to do more comprehensive tests and one of them is definitely to do the session based one where we hope to show that you can achieve greater security by an acceptable amount of performance sets that is not observable by user. Thanks. Any other questions? Okay, let's thank the speaker again. Thank you.