 work by Jens Quot and Victor Schupp about the security of ECDSA with additive key derivation and pre-signatures and Victor is going to give the talk. Thank you. I hope you can hear me okay through my mask. Yes, I come from a planet where we have a pandemic so I'm still there in my mind at least. So how do I advance? I didn't touch anything when that happened. Okay, okay, so let me start with some context. So I'm currently at an organization called DFINITY which is building something called the Internet Computer which is a distributed platform for executing smart contracts in a secure way. It does great things and it's amazingly fast and everything and what we want to do though is we want to build a new threshold ECDSA signing protocol but that's what we're implementing and we're currently integrating it into our protocol, our larger protocol and we're doing this because we think that it might be a good idea to allow smart contracts running on the internet computer to be able to securely hold and spend Bitcoin and other types of cryptocurrencies and of course most of these currently still use ECDSA so we need a protocol for that. So this is the MPC session. I'm not really going to talk about a secure multi-party protocol for ECDSA signing that's in a companion paper and this talk I'll be talking about just the analysis of a non-threshold ECDSA that's appropriate for analyzing a distributed protocol. So you'll see what I mean in a little bit. So just let's recall ECDSA signatures. We have an elliptic curve of order Q and a generator G and the notation I'll use here is my secret key will be little D and my public key will be this big D and I'll use additive notation and yeah so this is ECDSA. You hash the message, you point with a laser pointer that doesn't work. You pick a random R and you multiply your generator by that so you get the group element R and then you apply this funny function C which is this conversion function. It doesn't really matter what it is but that converts a point on the curve to a number mod Q and then you test a little corner case that never really happens and then you compute S as R inverse times H plus TD and the signature is this is pair ST and then you verify a signature by just kind of doing the obvious thing in reverse. You hash the message and then you compute S inverse times H, multiply that by the group element G, S inverse times T, multiply that by the public key D and then you check that you get a non-zero point on the curve and then the conversion function maps to T and so I'll keep this kind of basic verification equation up here. As you'll notice there's a part of the signing process is independent of the message M and you can do some pre-computations and a lot of people have of course noticed this before so you can compute the random R, do the multiplication of R times G and then do even the conversion function all independently of the message M so I'll call this group element R a pre-signature. Now if you're doing an MPC implementation of this you'll probably be using some kind of a secret sharing scheme and so we can do a pre-computation which in addition to computing this group element R, this pre-signature R, we can also pre-compute sharings of little R, the random number R and then also we can pre-compute kind of a beaver triple kind of thing kind of adapted to ECDSA a little bit so we can compute the random number U mod Q shared among all the parties and then we can use U to multiply both R and D so we get R prime is a sharing of R times U and D prime is a sharing of D times U so we've got two random numbers and then products of them so we can also do this as kind of a pre-computation in a distributed protocol and then once we have all this then to sign a given message M we can just do a local computation where we compute the hash of the message and then we assuming standard secret sharing we can just locally compute H times U the hash times U plus T times this D prime up here and then once we each party locally compute stat they can just open their shares broadcast their shares and then everybody can combine them so we open here V and R prime so V is H U plus T D U and R prime is R times U you cancel the U's and you get the S component of the signature out um yeah so that's pretty much it and I guess you're also right and you're going to open uh and you also already have T okay so once we have this pre-signature group element R plus this pre-shared data then the point of all is this then the latency for a signature is just one round of communication everybody broadcasts a share everybody can combine them and you have a signature okay so that's one so pre-computation is a is a technique that's used in many ecdsa threshold implementations another thing that's relevant to threshold ecdsa and ecdsa in the cryptocurrency community is something called additive key derivation so here the idea is that starting from a secret key little d we can compute kind of an offset of that secret key d plus e um and a corresponding public key which is just uh the original public key plus e times the generator uh where this e is kind of a public value and an additive tweak that's typically derived by some kind of hashing process applied to some identifier so it's so the main thing is that e is a a public value um if you're familiar at all with um bitcoin and and related cryptocurrencies there's a standard called Bip32 that's essentially a special case of this uh this additive key derivation and it's used in bitcoin and other cryptocurrencies to implement something called hierarchical deterministic wallets um so if we want to do something like this in a threshold implementation first of all it's fairly easy to implement because uh everything this tweaking this this derived key is is a linear operation basically so uh that typically means that uh we can efficiently implement that using secret sharing also uh it's useful in a in a threshold setting it's it's really important to use this kind of thing to keep the key maintenance costs to a minimum um let me elaborate on that a little bit so for every signing key that we have we have to share that signing key among all the parties right and so and then we're gonna have to reshare this key occasionally specifically uh when the network membership changes we're gonna have to reshare the secret key and uh if we want to proactively uh refresh the secret shares on a on a regular basis so just imagine uh we had you know tens of thousands of keys one for every user and then every you know every few minutes whenever we want to do a proactive reshare we want to have to re run this resharing protocol for all these tens of thousands of users even though maybe most of these users are not even using their key at this time right maybe they're not even generating that many signatures so um because of these costs we actually don't want to have all of these independent signing keys we we would rather if we could have kind of like one master secret key and then just derive uh secret keys secret signing keys for each user using a simple key derivation such as this one here additive key derivation um also in addition to all that uh the maintenance costs might also include any additional protocols for like backing up a signing key right the kind of a disaster if people lost their bitcoin signing keys uh and there wasn't some kind of a backup so that's additive key derivation and when you uh incorporate additive key derivation into ecdsa well you're right so you're essentially just replacing the public key d by d plus e times a generator so when you plug that into this equation here you just get a a t times e times g extra factor here so this is the new down here on the bottom here's the new verification equation that you get for if you want to verify a signature with respect to a derived key so what do we know about ecdsa security um typically in your average threshold ecdsa protocol you'll find that there's a security proof that reduces the security of the protocol to the security of the non-threshold ecdsa signature scheme hopefully that's the case but if we use pre signatures and or in combination additive key derivation uh we will need to consider an attack on the non-threshold ecdsa scheme that incorporates this usage right revealing pre signatures prior to messages being chosen and also deriving public keys in this way so what's previously known about uh these different kind of modes of operation well first of all if we just have plain old ecdsa the unfortunate thing about that is we don't really have a good reduction uh from ecdsa to any kind of standard problem but we do know that in the generic group model as a result of brown from 2002 that shows that um this is secure in the so-called generic group model uh under some collision resistance and in random pre-image resistance um assumptions on the hash function then if we look at ecdsa with pre signatures well actually there's a paper uh by ronkinetti and friends in 2020 who showed that uh a proof of security in the generic group model plus the random oracle model showed that ecdsa with pre signatures was secure for ecdsa with additive key derivation there's actually no general results prior to our work at least that i know of uh there are some results with various restrictions on the attack on the types of messages that you sign on the on the ways in which you use the public keys but uh there haven't been any real general results and then well in particular if you look at ecdsa with pre signatures and additive key derivations there's nobody's ever really looked at this at all even though uh this mode has been this mode of operation has been advocated in the literature for use i won't say who advocated it but because it's not really substantiated by anything but um yeah but you can see why you would want to use it right for those there's there's compelling reasons to want to use both of these modes of operation in combination so here's what happens if you were to use pre signatures plus a key additive key derivation there's actually an attack of sorts so here's how the attack works you make one pre signature query to get this random group element r and the and the corresponding uh you apply the conversion function to get the corresponding number t mod q and then the main step is step two where we want to find message m tweak e and another message m star and a tweak e star so we want to find these four things so this attack uh the the name of this attack is called the meme attack so the name was discovered by tall raven who wanted to make sure i gave her credit for the name for the meme and then what you want to do is find m e m e m star e star such that this equation holds here h plus te equals h star plus te star and the only real constraint is that the tweaks should be different the hash is the the messages could even be the same message it doesn't matter um and so so once you find these four values then you ask for a signature um on message m um you ask for a you ask for a signature st using this pre signature on the message m with tweak e and that immediately gives you a signature on m star with respect to tweak e star i mean this is just trivial math right so you can look at the verification equations and see that that's what you get so this is a valid signature on m star with respect to e star so that's kind of a simple thing to see now the hard part of course is the step two to find the meme and this is essentially a four-some problem um you can kind of just look at the hash outputs as basically random numbers and the tweaks are also kind of random numbers multiplied by this fixed value t so you're looking for four random numbers that add up in in this particular way so this is a well-studied problem called the four-some problem uh Wagner had a nice paper also 20 years ago that shows that you can do this in time cube root of q uh instead of square root of q which is what you would expect the the time it would take to uh attack e c dsa generically so it's still you know not a polynomial time attack but it's still uh i guess a bug rather than a feature in using this kind of mode of operation so uh i want to talk about some ways to mitigate against this type of attack and then um i'll present our results which basically is some analyses of these mitigations in the generic group model so one idea that we had um to prevent this kind of cube root type of attack is to use what we call re-randomized presignatures and when i show this to you'll think it's just kind of cheating in some way so the idea is this we start with a base presignature just as a normal presignature but i'll call it a base presignature r prime so you you pre-compute those now when a signing request comes in what we do only after the message has been committed to by the by the attacker we replace this this base presignature by the actual presignature so we we generate or we obtain a random number delta and basically add that to a delta times generated to our base presignature so the important thing is that this delta is a public random value so we don't it's not secret shared or anything so it's just derived publicly it's kind of like a you could get it from like a random beacon or some other threshold uh signing protocol that you could use like a BLS signature scheme for example that's what we actually do in our implementation so it's so it's a little bit cheating because we're going to use another threshold signature scheme namely BLS actually in our implementation to generate this public randomness but other than that it's sufficient to implement it may introduce some additional latency in the sense that you can only generate this delta after the the message to be signed has been committed to at least in our implementation it doesn't introduce any latency because anyway a signing request has to pass through a whole consensus protocol and by the time that happens you can easily start releasing the the shares of delta before before that happens so that's one mitigation this re-randomized presignatures the other one is i'll call it uh homogeneous key derivation so here the idea is that instead of having a single kind of master secret key d we're going to have two master secret keys d and d prime and then a corresponding master public key big d and big d prime then once we get a tweak we're going to derive the secret key as a linear combination of d and d prime so we're going to the new secret key will be d plus the tweak e times d prime and then the corresponding public key will be uh that so the this so that's a mitigation and I'll show you in a minute um what it buys you but right away just one disadvantage that I'll point out is that um it's not compatible with bib 32 and we wanted to have some compatibility with bib 32 so we didn't actually implement this um but one could and um finally you could actually if you wanted to combine both of these mitigations and you'll see on the next slide that this also buys you something you can combine re-randomized presignatures with homogeneous key derivation so this is what we analyze in this paper is actually we have like nine different theorems so let me just uh walk through kind of briefly and highlight some of the main salient features so first we start out looking at no key derivation and we look at no presignatures presigs and re-randomized presignatures so this first result here is basically Brown's theorem from uh 2002 this says that in the in the generic group model the the advantage that an adversary has in breaking the signature scheme is just the advantage of finding a collision that's this epsilon cr plus n times the advantage of finding a pre-image of a random number under the hash function and then there's this strange zpr which is the advantage of finding a pre-image of zero of the hash function and then you have the n squared over q which comes from the usual generic group model kind of analysis so that's actually Brown's result um yeah n here is the number of queries that counts group operation queries in the generic group model uh signing queries etc then if we look at again still no key derivation but with presignatures then we get another result which here uh let's see um qualitatively what's different you'll see here we have a factor u times n instead of an n here uh and then also so you here is the number of unused presignatures at any point in time you can generate presignatures and then you consume them when you sign and then there's at any point in time there's some number of unused presignatures and that for whatever reason comes into the analysis we also have another complexity assumption here which is I'll call ratio resistance this epsilon rr so this is the a bound on the advantage to find two messages who who's who's uh if you look at their hashes their ratios hit some random number so um this is similar to the result approved by kanedi et al in 2020 it's a little bit tighter actually than their result but that's not that interesting um then if we look at re-randomized presignatures this first mitigation I told you about so you'll see here that you know this reduction here in the second column is much sloppier than the than the original brown result and the nice thing you'll notice about this slide even though there are nine boxes a lot of them are the same in particular everything in column three is going to be the same as everything in column one so when we apply the re-randomized presignatures um mitigation we end up back in column one as if there were no uh presignatures at all then we look at additive key derivation um and again you can see here that everything gets slightly more painful and and the reduction gets sloppier and sloppier here we have to multiply this random pre-image thing by a factor uh of the size of the tweak set so here in this particular analysis I'm looking at the set of allowed tweaks I'm viewing the tweaks as the output of some random oracle I'll say something more about that in a minute um but assuming that we view the tweaks themselves as the output of some random oracle we can kind of make the adversary commit to the set of all possible tweaks in advance and then we have a guessing argument that kind of inflates the the the reduction here then we come to pre this is okay this is the worst of all possible words worlds here is when you combine additive key derivation with presignatures I showed you this quote unquote attack the good news is that's it's no worse than that we can basically we basically show that there are some specific instances that are for some problem that you can bounce the bounce the the probability of breaking it by so you get a reduction to a for some problem and then as usual if we add re-randomized presignatures to that we get back to column one so that's good so this is actually what we we implement additive key derivation with re-randomized presignatures it's it gives you a pretty good bound then finally if we look at homogeneous key derivation the good news is here column no row three is the same as row one so when you so so homogeneous key derivation is actually a more a more powerful mitigation so here you just see we get everything as in column one in particular the cell down here on the lower right is the same as brown's cell up on the right so if you do homogeneous key derivation plus re-randomized presignatures you're like living in the same world that brown was living in 20 years ago so that's nice it gives you a nice tight reduction and I'll finish up by just mentioning a couple other features of our analysis I won't be doing any proofs here it's all done in a generic group model there's been some complaints about the generic group model especially as it relates to the elliptic curves and e-cdsa in particular so what we do to kind of address some of those complaints is to you know in so in the generic group model we're basically going to choose a random encoding of the group we have a group of a prime order q and we're going to just pick a random encoding of it and then the adversary gets black box access to add and do group operations on these random encodings but our encoding space so to speak is actually an elliptic curve of prime order q it's just that we ignore the group law right so the group law is just has nothing to do with the group law of the elliptic curve but the space in which the group elements the encoded group elements live is an elliptic curve except again to address complaints we enforce the condition that the inverse in the group of an element of this curve really respects the usual inverse law right and this gets at this allows us to model some quirks in e-cdsa in particular malleability in particular if you have a signature st on a message m then so is minus st so we can actually model this and not only can we model the malleability we can actually then prove in this particular ggm model that e-cdsa is only malleable in this way which isn't surprising really we also analyze the standardized bib 32 construction and show that it's actually indifferential from a random oracle really a public random oracle but it doesn't really matter in this application and we also analyze the additive key derivation without using random oracles and just using kind of concrete assert security assumptions and the interaction between the e-cdsa hash and the hash that's used to derive the tweaks so that's it thanks and i'll make a shameless plug do we're all we're still looking to hire people at the finity um thank you um thanks for the talk uh are there questions for the last speaker um maybe a quick one um so in addition or except for the meme attack that you had are there any known attacks uh on uh if you have only uh precix or additive key derivation but not both together well we did i mean we do have lower bones but does it translate into um something because you have a bit of a loss right in comparison to the oh yeah there's some others yeah there's some other sloppiness in here like this extra factor here and there are various extra factors here and there that come in to just making a standard kind of hybrid argument or guessing argument and it's typical right in those cases i there may be attacks there may not be attacks we didn't really dive too deep into that there could be attacks there that match the upper bounds but i'm actually wouldn't want to spend any money thanks a lot okay so let's thank all the speakers from the last session again and this concludes day one of Eurocrypt have fun