 So, welcome everyone, my name is Christine, and today I'll be talking about rapidly verifiable XMSS signatures. This is joint work with Joppa Boss, Andreas Hülsing and Jocelyn S. So as an introduction, let me first set the setting. So we have Alice, who wants to send a message to Bob, namely to meet for drinks at four, and to make sure that Bob can verify that this message actually comes from Alice, she signs it with some signature scheme. She then sends the result along a secure channel to Bob, and Bob can take this signature and verify it against Alice's certificate to make sure that the message really came from Alice and not some other person. So this is quite a simple setting, in reality it can be a bit more complicated. So for instance Alice can be a large company who wants to send a new firmware image to all their devices. To make sure these devices can verify that the firmware image actually came from company Alice, they sign it with some signature scheme and send it over a secure channel. But now in this case Bob is not one person, but actually many IoT devices. So this message is sent along many secure channels, but then all these devices do verify the same signature against the same public certificate to verify the authenticity. And this scenario, this setting is our use case. So we have one signature and many IoT devices verifying it. And beyond the firmware updates that were just sketched in the previous slide, another situation where this use case applies is that of secure boot. So it's a pretty relevant use case and used in many devices. And in this use case the signer actually has access to significant computational resources since a large company can use the cloud or a computation farm to set their signature. While on the other hand the verifier might be some constrained device and they might not have these computational resources and therefore it might be advantageous to if possible put more of the computational load on the signer and not the verifier. And in this work we specifically look at the case of XMSS. So can this trade-off be made possible for a standardized post quantum digital signature scheme like XMSS? We start with an executive summary that basically says yes we can. To add a little bit more detail here, in this work we actually present a faster XMSS signature verification with the aim at the use case I just sketched unembedded devices. And to achieve this faster verification we use a probabilistic method which was introduced by Perrin, Zambone, Martin's Custodio and Martina in 2018. But we extend their work by various avenues, namely we add a security proof that adding their technique to XMSS actually means it's still secure as well as we add a statistical analysis to show what the performance of the method is. Then along the way of creating this security proof our work actually also fills a previous gap in the XMSS proof which shows resistance against mitigating multi-target attacks against the scheme. And lastly in the paper we show that using a wrapper function around XMSS actually our scheme is still compatible with RSE. Then given these things we also implement our scheme and our paper shows that combining these things with further known optimizations it allows for trade-off of a signature generation of about a minute on an X86 in Le Corp can expect a speed-up factor of over two for the verifier if it's a small embedded device, an ARM Cortex M4. And of course we show other trade-offs are possible but just as an executive summary this is quite a nice achievement. Then what will I talk about in the remainder of this talk? First of all I'll talk a bit about what XMSS is, namely a stateful hash-based signature scheme. Then to show the techniques that are used I'll explain how one-time signatures work and how specifically Winton-Hitts one-time signatures work before diving into the contributions of our paper namely rapidly verifiable signatures where I'll first show how the algorithm works and how it incorporates the work of PZMCM then I'll give a brief outline of the security proof and go into some of the things we did to analyze the performance of the rapidly verifiable algorithm before I end with results and a conclusion. So then first stateful hash-based schemes. So XMSS or Extended Miracle Signature Scheme it works as follows. So we start from a one-time signature key pair depicted here down below where a signer creates one private key, computes the corresponding public key and can sign one message with it. Well this is fine but now if the signer has to do that many times and sign many messages they have to make many key pairs and publicizing all these public keys is of course not very convenient so in the 70s Ralph Merkle came with the idea of a Merkle tree and the Merkle tree sort of solves this problem by posing that you can take this one-time signature public key and hash it into a binary Merkle tree as a leaf node and then what you can do is pairwise hash all these nodes together until there is one top node the public key of the Merkle Signature Scheme which can then serve as a public key for all eight one-time signatures and this changes a bit what the signature looks like so for a one-time signature pair which we saw here on the left we just had OTS Signature 0 but the Merkle Scheme or XMSS in this case also adds the state as in the signature so that the verifier knows which leaf of the Merkle tree is being signed with as well as an authentication path and the goal of an authentication path is that it's a set of nodes in the Merkle tree here depicted in red such that if a verifier computes the one-time signature public key they can then in order hash the hash values with the authentication paths to recover a candidate for the public key which can then be checked against the public key of the Merkle Scheme so in summary a one-time signature scheme has one secret key one public key and can sign one signature which is for most applications pretty impractical and XMSS and other schemes like LMS or others combine these one-time signatures into a larger scheme using Merkle trees and as a result for Hyde H Merkle tree which is the number of layers in the Merkle tree and the parameter each one-time signature can sign one message but they can all verify against the same public key and the nice thing about these schemes is that they're already standardized by missed in a special publication that can be seen on the left here so after the Grand Scheme of Things we move to these one-time signatures so how do winternets one-time signatures actually work well if we have a m-bit message digest m of a certain message that needs to be signed the observation is you can actually write it rewrite it in a base w representation so we take the m-bits and split them up into l1 chunks of size w and then l1 would be equal to the the bit length of the message digest divided by the bit length of w so this is quite some notation but as an example if we want to write 37 in base 4 then what we do is we take the bit representation and simply split it up into chunks of 2 since that's four values being represented and then a simplified view on the key generation of winternets one-time signature scheme is that we have a hash function h we generate a secret key for each of these base w chunks that can be in the m-bit message digest and we simply apply the hash function to each of these secret keys and we do not do that once no we repeat that and we repeat that specifically w minus one times to get the public key of the winternets one-time signature so this seems pretty simple but once we have these secret keys and public keys we of course want to sign the message with them so how this works is as follows we have this message digest m here at the top and we also split that up into these w base bit chunks let's say and then i'm simplifying a little because for winternets one-time signature actually we chuck another few chunks behind that namely the checksum and the goal of the checksum is to prevent forgeries i won't give any details on that but just assume that it's a few more a few more chunks being put behind here and now we want to sign so we have our secret key which are these nodes in the beginning each one from one up till l and now if we want to sign sign the message we start at the the first base w value and we map this value to a place in the secret key one chain and specifically for instance this value is three then we would compute the the third node after the secret key with this value and we repeat this process for all chunks so p2 b3 up to bl which is also here the the eight value in the chain and this is then our signature so this looks pretty simple um then the question remains is how to verify this signature so this works as follows the verifier knows the message knows the winternets constant knows the signature public and the public key as well as the hash function and what they can do is then also chunk the message digest up in the same manner as the designer did map it to the the chains where the verifier does not know these previous versions where the signer did and then they can just start applying the hash function so for s1 they can apply h again and again and they apply w minus 1 minus the value of p1 times because applying the hash function this many times is supposed to lead to the public key one and this can again be repeated for all chunks so also for sigma l you go all the way to the end and then you verify against the public key quite simple so that was the details about what's plus that we need to know and now we can actually move to the contributions of our paper which are rapidly verifiable signatures and before showing you the algorithm the adapted xmss algorithm we present we first want to give the idea of of the underlying technique which is as follows namely the cost of verification of a what's plus signature is actually largely determined by the value of the l1 integers p1 up to b1 so here b1 was the fourth node in chain and the verifier actually has to compute 1 2 3 4 5 6 7 8 9 hash functions to have something to verify against the public key now for the verifier it would be much easier if this value was actually towards the end of the chain and they would only have to do a few hash functions well this is where winternet's tuning comes in so pzmc18 observed that these b1 up to bl1 values are determined by the base w representation of the message values and we cannot just change the output of a hash function but what we what we can do and what they show in pzmc18 is that by adding a counter in the message hash and not just one counter but t different counters you get a different output m by appending that counter and then choosing the the chain values that you like best so the ones that have the least verification time and therefore the ones that maximize the cumulative chain lengths if you choose this message and verification time goes down and this is quite a nice observation and in the work and what I'll talk to in about in the next slide we fill in some gaps of these papers namely the message line dependence which we show you don't need in our work we also provided thorough security analysis that show that applying this technique in specifically xms does not degrade security as well as we give a performance analysis so we analyze what kind of effect choosing different values for t has and lastly we also apply it to the xmss implementation so first the xmss adapted algorithm which is shown here in the middle and an algorithm one in the paper I won't go through this in detail but I will just highlight that this block in blue that's where in the algorithm we apply the core idea of pc mc 18 mc m 18 to xmss so we add these t counters to the ash and determine which of these counters results in the best values and the best time or the lowest time for a verifier which is what we want and this is also where we include this message length independence that we add so we show that this adding these counters can actually be done really fast even for large messages by only iterating over the last hash block so if we straightforwardly apply the technique of pc mc m 18 then for large messages and applying these many counters it would fast turn into a huge signature generation time for large values of t while we show that if we only iterate over the last hash block then with this pre computation then actually the signing time remains constant for for a different message size which is a huge progress then next contribution is answering the question is it still secure so the answer here is again straightforwardly yes it's still secure and as a high-level proof outline in the paper we first analyze what impact adding this counter has to the to the message hash construction for xmss type signatures and then after analyzing this we formulate the necessary security assumptions on this hash functions as a standard model property and given given these this pre-work we can then analyze the complexity of generic attacks against against the scheme and provide a bound for blackboard attacks against the random function yeah so i won't go in for the details for the proof details can be found in the paper but what might be nice to mention is that while constructing the proof for the meek we also fill a previous gap in the xmss proof that shows multi target attack resistance then on a performance analysis level so given this that the signature generation verification scheme for an implementer it might be a question on how to set t and what kind of performance can we expect them and we do this in two ways in the paper the first way is that we in a simplified model prove the number of hashes an implementer can expect for a given set t and again the the theorem here is on the top left and i won't go into the full proof but the idea is that we first buy the central limit theorem model the length of of the commutative l1 chain lengths and then given this distribution we use order statistics to determine the expectation of the maximum over t counter so if we have t times these average chain lengths what do we expect the maximum to be and then lastly we trade the the chain lengths for the checks on a bit differently since as you can read in the paper they behave in a kind of special way but then we show that all three of these are quite solid assumptions in the paper and yeah you can see that there then beyond averages since for an implementer it might also be useful what is the maximum and minimum performance they can accept we also give confidence intervals for the expectation so we see that here on the left so for instance what you can see here is that if an implementer were to add two to the power of 40 counters to their hash message then we expect with i think 95 percent confidence that the number of hashes for the verifier would lie between about 250 and 300 and a bit where previously it was around 500 then lastly we verified the performance of our rapidly verifiable XMSS version and these results come from an adaptation we made of the reference implementation which we ran on a freedom k64 board this is a cortex m4 development board which gave us the following results namely here on the left we see a table with the trade-off between the signature generation time and the verification time by adding the counters so for instance here on the left if a if a signer adds two to the power 32 counters which makes the signing time about an hour then they can expect to have a performance gain for the verifier between 40 and 50 percent which is quite good and then in cycles on this freedom board we see that compared to the reference implementation and also adding some pre-computation tricks from ckrs20 we can actually get given a signing time of about a minute we can get these turning point eight million cycles down to about six point five six million cycles which is a huge performance gain so that's what i wanted to show you about our paper and that leaves us with a conclusion so in conclusion we utilize the techniques of pc mcm18 to enable a rapidly verifiable version of XMSS and we thoroughly analyze both the security and performance of the new scheme then we also implement this rapid XMSS on a freedom k64 f board and as an example i mean i've mentioned before other trade-offs are possible that on a if we sign on a single core x86 machine then you can verify the signature two point 11 times faster than the reference implementation on a embedded device and this translates to about a verification time of 54 milliseconds which is actually quite practical and as mentioned before it's a standardized signature algorithm so that's quite nice and then lastly we'd like to mention that the results straightforwardly apply as well to the multi-tree version of XMSS as well as a variant or a similar hash-based construction LMS and it's multi-tree variant HSS that uh that that brings me to the end of the talk so if there are any questions you can contact us at this email address and other than that thank you very much for listening