 So the next speaker, the last speaker of the session is Jeremiah Blockey from Purdue. Do I need to share the screen? Okay. Yeah. Okay. All right. Thanks. So excited to talk to you today about the multi-user security of short snore signatures with and without pre-processing. This is joint worth with Sunghoon Lee also at Purdue University. Okay. So digital signatures are ubiquitous in cryptography. They have many applications and use cases, message, document authentication, authenticating blockchain transactions, use for certificate authorities, electronic signatures, so on and so forth. And there's a lot of properties that we'd like to have for an efficient digital signature scheme. We'd like them to be short. We'd like to have efficient signing and verification algorithms. And we'd also like them to achieve K-bit security, which means informally, an attacker running in time T wins the signature forgery game with probability at most T over 2 to the K. Finally, we'd like to ensure that the digital signature scheme is even secure if the attacker can run a pre-processing attack in which they perform some pre-processing attack in hopes to decrease the online attack time. All right. So let's look at some options for signature schemes. We have RSA full domain hash. The signature link for RSA full domain hash is Omega K. So it's super linear. Elliptic curve DSA and Schnorr signatures get that down to 4K bits. And interestingly, in Schnorr's original paper, there was a proposal for shortening the length of the signature to 3K bits. The key question, though, is by shortening the signatures, does this adversely impact security? So are short Snorr signatures still secure? Do they remain secure even against a pre-processing attacker? Finally, there's also BLS signatures. These are 2K bit signatures. So even shorter than short Snorr signatures. The disadvantage, though, is that they require bilinear pairings. So shorter signatures, but higher computational overhead. And then finally, just for the sake of completeness, we can also go to IO-based signature constructions. We can get K-bit signatures. But I stress that this is purely theoretical construction. We don't have practical instantiations of IO. So we're not going to consider that for our purposes. OK. So to briefly summarize our results, a key question. Are short Snorr signatures still secure? Short answer, yes. Short Snorr signatures still provide K-bit of multi-user security. So no concrete security loss for truncating the hash output. Our proof is in the random oracle model and generic group model. So we do make every possible idealized assumption. But finding a tight security proof in a non-ideal setting will leave that as an open question. So another key question, are short Snorr signatures secure against preprocessing attackers? So here we consider the problem and we give two different answers. So the first answer is no. Short Snorr signature schemes are not secure against preprocessing attacks. In fact, regular Snorr signature schemes are not secure against preprocessing attacks. However, if we modify the Snorr signature scheme a little bit by key prefixing, we obtain a signature scheme that's actually secure against preprocessing attacks. With a slight caveat that we need to increase the size of our group just a little bit to achieve K-bit security. OK. So let's look at the standard Snorr signature scheme. So here our secret key is just a random integer between 1 and P. Here P is the size of our group. Our public key is just G, our generator of the cyclic group raised to the power sk. And to sign, all we're going to do is we're going to pick a random nonce R. We're going to compute G to the R. And we're going to compute an integer E by hashing I and the message M that we want to sign. Then finally, we're going to compute S by taking R and adding our secret key multiplied by this value E. And our signature will just be S and E. Now notice that S and E are both 2K bit integers. So our total signature length here is 4K bits. Verification works in the opposite direction given our message M, S and E. We can compute G to the S times PK to the minus E. If the signature was generated honestly, then what we're going to get back is just G to the R. And in this case, we expect that hash of R concatenated with M is going to give us back E. So that'll just be the check that we performed during verification. Okay, so public parameters here. We've got a group and a hash function which maps messages to elements in ZP. So the short snore signature scheme is essentially the same thing with a very small modification. Here we're just going to change the hash function so that it outputs a random integer between 1 and 2 to the K. So we've shrunk it from 2K bits to K bits. That's the only change. And making this change, we obtain the short snore signature scheme. Okay, so we're going to analyze the short snore signature scheme in the generic group model. The generic group model was introduced by Shoop in 97 to model generic attacks on discrete log type problems. Here we're modeling any attack which doesn't exploit specific structure of our cyclic group. So with lots of generality, we're just going to assume our group is ZP. And we're going to assume that the attacker accesses this group through specific oracles. So we're going to assume that we have a function tau. This is a random injective function which maps group elements to binary strings or their handles. And then we have a multiplication oracle which takes as input the handles for two group elements X and Y and outputs the handle for the new group element X plus Y. So yeah, input handle for group elements X and Y, output handle for X plus Y. We'll also consider a couple other oracles. Inverse computes the inverse of an item X or power computes X to the power N. So input here is the handle for a group element X and an integer N. Output is the handle for the group element N times X mod P. Okay, so sample result in the generic group model. We can show that any attacker making T queries to the generic group oracles solves a discrete log problem with probability at most T squared over 2 to the 2K. Just a simple bound to prove in the generic group model. Now in our setting, we're also interested in looking at pre-processing attackers. So here the attacker can be divided into two parts. There's the offline attacker who takes as input the secret random encoding function tau which maps group elements to their binary strings or handles and outputs an S bit hint, sigma. So in this case, there's no bound on the running time of the offline attacker. He can run as long as he wants. The only constraint is the size of the hint that the offline attacker outputs. Then we have an online attacker that can use this hint during its attack. Of course, the online attacker has a bounded running time, so it's bounded in the total amount of computation it can perform, total number of oracle queries it can make, et cetera. So motivation for looking at pre-processing attackers here. Well, in real world crypto systems, there's a handful of groups that tend to be used. So an attacker would be highly motivated to perform a offline phase attack where they do some pre-processing on one of these groups in the hope of speeding up their online attack. So here's an example result in the generic group with pre-processing setting. So Corrigan Gibbs and Dimitri Kogan prove that any pre-processing attacker making, I guess, running in time t using an S bit hint solves the discrete log problem with probability at most s times t squared over 2 to the 2k. So that's a bound but that's known for the pre-processing setting. Okay, and in our setting, we're interested in looking at the generic group model and random oracle model with pre-processing. So here the offline attacker is given the encoding of the generic group. They're also given oracle access to our random oracle h and they can run for a while in output in S bit hint. Now I should stress here that for technical reasons we're going to assume that the offline attacker is bounded in the number of queries that it can make to the random oracle but the bound will typically be a very large bound. So for example, the offline attacker can make, let's say, 2 to the 3k queries to the random oracle before outputting the hint. Okay, and then of course the online attacker can use this hint but has bounded running time in terms of number of queries to the generic group oracle or generic group oracles or random oracle. Okay, so now we're interested in analyzing the multi-user security of Schnorr signatures. So in the multi-user security game the challenger generates our public keys, sends them to the attacker. The attacker can submit queries to the challenger and basically each query is a request to sign a message M with the key of the ith user and the challenger will respond with the corresponding signature. We can continue querying the assigning oracle and eventually the attacker has to output a forgery for one of the user's signatures for some message M' of the attacker's choosing. The attacker wins if the signature is valid, if it verifies and if the value I' M' is rushed. So in other words, we haven't submitted this query to the challenger to get a signature in the past. Okay, now in the preprocessing setting the game is exactly the same except now the online attacker is additionally given this S-bit hint which was generated by the preprocessing attacker. Okay, so our results. Informally we prove that any attacker making at most queue oracle queries in the random oracle and generic group model wins the multi-user signature forgery game against the short snore signature scheme with probability at most q plus n over 2 to the k. So I wanna pause here to stress that this is stronger than the naive bound which would be q times n over 2 to the k. So just as an example, if k was 112, n was 2 to the 32, q was 2 to the 80, the naive bound would actually give us nothing. It would just tell us that the attacker's probability of forging a signature is one. Whereas our bound would give us, you know, the attacker's probability is at most 2 to the minus 32. So I should note here that Kiltz et al proved a similar bound for regular snore signatures and the authors later let us know through personal communication that their analysis actually extends to the short snore signature scheme even though that's not mentioned in their paper explicitly. So however the generic group model used in their analysis is not equivalent to Schup's generic group model and in particular it's not suitable for analyzing pre-processing attacks. Okay, so for pre-processing attacks we prove the following bound. Let's suppose that our pre-processing attacker makes at most q pre-random oracle queries during its pre-processing phase and then outputs an s-bit hint which can be used by the online attacker. If the online attacker makes at most q on oracle queries during the online phase, then this attacker can win the multi-user signature forgery game against key prefixed short snore signatures with probability at most and then we've got this complicated looking expression here. So first comment here is what is key pre-fixing? Key pre-fixing, we're just going to modify the snore signature scheme by injecting the public key whenever we query the random oracle. So instead of computing e as tau of r concatenated with m we're just going to prepend the public key for the user. So that's the only change we're making. Now you might wonder why is key pre-fixing necessary? Well, actually there's a trivial pre-processing attack if the attacker can generate equal zero signatures. So in other words, let's suppose the pre-processing attacker outputs a hint, r, m such that hash of tau of r concatenated with m is zero. Okay, so if we're not doing key prefixing, now notice that r, zero is actually guaranteed to be a valid snore signature for m under any public key that we might generate. So this is kind of a master signature that works under any public key. So trivially, snore signatures are broken under preprocessing attacks. But if we make this modification and use key prefixing, then we do get security. Now I should note that several standardized implementations of snore signatures explicitly disallow equal zero signatures, so that rules out the attack that I just described in the slide. So actually this is an open research challenge is to quantify the security or insecurity of snore signatures against preprocessing attacks when equal zero signatures are explicitly disallowed but when we're not using key prefixing. So that could be an interesting question to look into. Okay, so let me just comment a little bit about the concrete security bound here. So here we want to achieve k-bit security. We're going to assume that the preprocessing attacker can make, let's say, two to the 3k queries to our random oracle. That's a lot of queries in the preprocessing phase. So for example, if k is 128, that's two to the 384 queries that we're allowing the attacker to make, but the attacker is limited in that they can only output an s-bit hint at the end of the day. Now to achieve k-bit security here, the middle term becomes a little bit problematic. So to achieve k-bit security, we actually have to increase our group size a little bit. So instead of p as two to the 2k, we need to set it to be two to the 2k times sn times log p. But we can still keep our shorter k-bit hash outputs. Okay? And in this case, our signature length is k plus log base 2 of p, which works out to be 3k plus log of s plus log of n. Here, n is the number of users that we're considering in the multi-user security game. S is the size of the hint that the attacker outputs. So for example, if the attacker can output a two to the k over 2-bit hint and n is 2 to the k over 4, then our signature length is roughly 3.75 k-bits, which is still shorter than the original Schnorr signature scheme. Okay. So I'm not going to go through the whole proof, but I wanted to just give you a few key technical ideas for details, see the paper. So we're using compression arguments all over the place in the paper. The basic idea is that if the pre-processing attacker wins the multi-user signature forgery game with larger than expected probability, we can either compress the generic group mapping tau or the random oracle h. Now, of course, information theory tells us that a random oracle h and this injective mapping tau should both be incompressible, so that would yield a contradiction. So we really kind of split our analysis into two cases. Case one, we can use the attacker to find a non-trivial linear relationship. So we've got secret keys x1 to xk. If the attacker can find some vector a and some integer b such that a.x is equal to b, the attacker has found a non-trivial linear relationship. This can be used to compress the generic group mapping tau. So that will be one case where we'll compress the group mapping tau. The other case is that the attacker somehow manages to successfully forge signatures without uncovering non-trivial linear relationships. And in this case, we argue that we can use the signature forgery attacker to compress the random oracle h. Okay, so the security reduction, we're going to use the signature attacker to win a game which we call the multi-user bridge game. So here we've got inputs tau x1 through tau xn. These correspond to the public signing keys in our signature scheme. And what we're going to do is we're going to simulate our signature attacker. And whenever the signature attacker queries are signing oracle, we're actually going to program the random oracle to allow us to forge signatures. Okay? And what we managed to prove on the one hand is that the probability the attacker wins the bridge game is greater than or equal to the probability our signature attacker wins the signature forgery game minus these big O terms shown here. And the analysis of the middle terms involves a compression argument on the random oracle. I'm not going to go into it if you're interested to see details in the paper. But on the other hand, what we can prove is that the probability the attacker wins the bridge game is at most this. Snq squared log p over p. So here s is the size of the hint, n is the number of users, q is the number of queries the attacker makes in the online phase. And the proof idea here is just a compression argument with the generic group model. Okay. So let's introduce this bridge game. And to introduce the bridge game, we need to try to maintain an invariant while we simulate our signature forgery attacker. The invariant we're going to maintain is that every output of a generic group query can be explained. So we want to maintain a list of tuples of the form tau y, a. Okay, so this should be b here. So we want to basically be able to explain that this is equal to b plus a.x, where x is the x1 to xn, these are the unknown secret keys. So initially our list is just going to contain entries for the generator, which is tau 1. Here b is 1, a is 0. And then we'll have entries for tau of x1 through tau of xn. Here b is 0 and our vector here is u1, u2, u3, just the unit vectors with a 1 in the i-th coordinate. Okay, and we want to maintain this invariant. So let's suppose the attacker queries the multiplication oracle with tau of x1 and tau of x2. Well, that's going to generate a new element, tau of x1 plus x2. So we can update our table with the explanation here. So this element is just, this vector a would just be u1 plus u2 and b would just be 0. If we multiplied x1 by tau of 1, we're going to get the same vector a, so a would be u1 and b would be 1. And similarly, right, for other generic group oracles, we can update this list. Now we might run into a problem here and this problem that we encounter with the attacker queries the, queries the generic group oracle with an element eta, where eta is just some random binary string that we haven't seen before. So this could throw us off and prevent us from maintaining our invariant. So the question is if the attacker makes such a query, how do we update our list l? We can't simply find b in a vector to update the list. To address this challenge, we're going to introduce what we call the restricted discrete log oracle. So we're actually going to give the attacker access to an oracle which solved the discrete log problem. Now of course if we just gave the attacker access to this oracle without any restrictions, this would make breaking security trivial. So we're going to restrict the attacker's access to this oracle. And in particular, we're only going to allow the attacker queries to the restricted discrete log oracle if the input is fresh. So in other words, if the input doesn't already occur in our list l, then the attacker can query this restricted discrete log oracle. So for example, the attacker can't query the oracle to find one of the secret keys. They can't do tricks like create linear combinations of the secret keys and then query the discrete log oracle. But if they pick a fresh binary string, they can query the discrete log oracle to get the discrete log of this new group element. Okay, so now that we have this restricted discrete log oracle, we can use it to maintain our invariant and update our list l. Now, as we're updating this list l, we'll say that the bridge event occurs if we find a non-trivial linear dependence. So in other words, if we end up adding the same group element to our list twice in two different explanations. So suppose we add a group element eta to our list twice, once with a vector a1 b1 and the second time with a vector a2 b2, where the explanations are distinct. In this case, we find a non-trivial linear dependence which we can use to compress the generic group oracle. So just as a simple example, suppose a queries the multiplication oracle on tau of x1 and tau of x2, which is this particular binary string. Then suppose they query the generic group oracle with tau of 1 and tau of x5. And let's suppose that we got a collision. In this case, what we learn is that x1 plus x2 is equal to 1 plus x5. That gives us a non-trivial linear dependence which allows us to compress the generic group oracle. Okay, good. So we'll call this a bridge event that the probability the attacker can cause the bridge event to occur is upper bounded as follows. Okay. So sweeping a lot of technical details under the rug here, but if you're interested, see the paper. So in conclusion, what we proved, we proved that the Schwarz-Nor signature scheme gives us three k-bit signatures with k-bits of security. And essentially all we do is just truncate the hash output. So we proved that truncation of the hash output does not adversely impact any of the concrete security guarantees even with multi-user security. We also looked at key prefixed Schwarz signatures games versus pre-processing attackers. We showed that key prefixing is necessary and we showed that we can continue to truncate the hash outputs without concrete security loss. However, we do need to increase our group by a multiplicative factor roughly n times s to achieve k-bit security. And then there's an open question which is to understand the security or insecurity of key non-key prefixed Schwarz signatures when we explicitly disallow equal zero signatures. I should also mention that our compression arguments also hold for other signature schemes like Chom Peterson or Cat Swing signatures for details, see the paper. All right, so thanks for listening and I'm happy to take any questions. Thanks, Jeremiah. Questions? I think Stefan also has a question. Big one. I don't know if you can hear me. Maybe you said something but I missed it. Can you say something about the tightness of the n times s? So the s is clear that it's tight but the n times s? Yeah, so that's a good question. I'd have to... I want to do some offline pre-processing to offer definitive response. The s is definitely required. I think there might be some possibility of removing the n term but I'd have to think more about it. Thanks. Yeah. For the term... Jeremiah, could you repeat the question? Okay, so the question is for the term with random oracle queries is our pre-processing bound tight. Well, because the random oracle is only outputting k-bit hashes, we can't get anything better than k-bit security. There's just no hope to get anything better. So, yeah, in that sense we can't tighten the bounds. One place where one might be able to tighten the bounds is in terms of the number of queries that the offline attacker is allowed to make. So we do restrict the offline attacker to make two to the three k queries and which is a very large number of queries but maybe one could remove this restriction. We needed to make that restriction for some technical reasons but it might be possible to get rid of it. Any more questions? If not then let's thank the speaker again and we have now lunch and we meet at 20 past before the next session.