 Hi, my name is Valerio and I will be talking together with Erkan about updateable signatures and message authentication codes. This is a joint work with Sebastia Ramaker, Dennis Lamening and Christoph Strix. In this work, we introduce a definition of framework for updateable signatures, US, and updateable message authentication codes, UMAC. The form of updateability we are interested in is that primitives are key updateable and allow to update all cryptographic objects, so in our case signatures or message authentication codes, from the old key to the updated key without requiring full access to the new key, but only via a so-called update token. Similarly to concrete practical motivations that led to recent works on updateable encryption, so for example, Leman et al. from Eurocript 18, we observed that also in the context of signatures and MACs, it's important to follow good key management practices and to periodically switch keys. Two possible examples of that are software distribution channels, when one relies on signatures to ensure the authenticity of the software distributed, or outsourced databases, which usually require signatures or MACs to ensure integrity of the stored data. In both cases, if the holders of the secret key could compute a token that allows some third party to update existing signatures or MACs to once valid under the new key, then these holders wouldn't have to generate fresh signatures and MACs for the old data again whenever they switch keys. In the context of signatures, we can describe the functionality of updateability as follows. As done in the context of updateable encryption, we use the concept of epochs, where each epoch has an associated key pair, PKE SKE, for epoch E. In any given epoch, the holder of the secret key can sign arbitrary messages to obtain the corresponding signatures. It can then send them to some third party, for example, a server or a database. At any time, the user can run an algorithm called NEXT, which, on input, the key pair of the current epoch generates a key pair for the following epoch, together with a so-called update token delta. The user can then send such token to the third party that was storing new signatures, so that this third party, using such update token, can run an update algorithm that converts signatures produced in the old epoch to new ones that verify for the same message under the new public key. Regarding security, we set to achieve two different security notions, unforgeability and unicability. As far as the first notion is concerned, we want to guarantee signatures and MACs unforgeability, even against an adversary that can trigger the other articles it has access to, arbitrary signature computations, adaptive computation of NEXT keys and updates of signatures, and also that can adaptably corrupt tokens and signing keys. Of course, with the restriction that we exclude trivial fargeries. The second security notion, unicability, essentially says that updated signatures cannot be distinguished from fresh ones. This again should hold against an adversary that can adaptably query signing keys, update tokens and signatures. As in recent work on updateable encryption, we use the concept of leakage profile to capture key, token and signature leakage that cannot be captured directly via the articles in the security experiment. Indeed, due to the updateability functionality provided, updateable signature schemes inherently allow for information leakage of updated message signature pairs, keys and tokens, besides what is modeled in the security experiment. For example, one single update token can be used to update polynomially many message signature pairs, and therefore we cannot capture which particular signature the adversary will potentially update. Moreover, tokens could potentially enable the adversary not only to upgrade, but also to downgrade signatures and or keys. Having upgrades only would lead to stronger schemes, which however seem of limited interest in authentication scenarios where all keys are typically assumed to be invalidated anyway. We therefore opted for the simpler and cleaner bidirectional setting. We consider the following leakage profile. Tokens allow to both update keys and to downgrade them. Pairs of consecutive secret keys leak the intermediate tokens between them, and update tokens allow also to update signatures from old app to new one and from new epoch to old ones. Graphically, which is probably easier to understand, suppose that an adversary has queried its key update and signing oracles to obtain the data colored in green. In our leakage profile, we did use that the adversary has access not only to this information but also to the data that can be derived from it. For example, using the update token for epoch E-2, the adversary can downgrade the secret key of epoch E-2 to obtain the secret key of the previous epoch. Now, with this new information, the adversary has access to both secret key of epoch E-4 and epoch E-3, from which it can derive the in-between update token delta E-3. Once it has access to such token, the adversary can then update signature from epoch E-4 to signatures valid in epoch E-3. Similarly, other information can be derived via these leakages, and eventually, all the information colored in blue can be obtained by the adversary. After defining this new primitive and modeling the security requirements, we provide a different distanciations based on various types of assumptions. We will describe here only some of them, and Erkan will give you an overview of all of them in the last part of the presentation. Here, we will focus on how to construct updateable signatures from chemomorphic signatures, primitive introduced by Darlin and Islamic. I will then discuss a lattice-based candidate US construction, which follows the GPV template. Erkan will then present how to construct UMAX from almost chemomorphic PRF, and will give you an overview of the security proof ideas we used in our work. Before introducing key homomorphic signatures, we need to first define what a secret key to public key homomorphism is. Consider a signature scheme, sigma, where both secret keys and public keys are elements of two different groups. If this is the case, then a secret key to public key homomorphism is a map between the secret key group and the public key one that satisfies two different properties. First of all, it is a group homomorphism, so it is a map that is compatible with the group structure of both groups. Second, such map should also be compatible with the key generation algorithm of the signature scheme. That is, it should send secret keys to the corresponding public keys. For example, in the deluxe setting, one usually has that the secret key is a random element in ZP, where P is the cardinality of the group G, and the corresponding public key is the given generator of the group G raised to the secret key. In this case, the map that exactly sends KZP to G2K in G is a secret key to public key homomorphism. A signature scheme is then called key homomorphic if it provides a secret key to public key homomorphism and an additional PPT algorithm called ADAPT, that is compatible with the secret key to public key map. Such algorithm, an input, a public key, a message, its corresponding signature and a token, which is an element of the secret key group, outputs a new public key and a new signature. The new signature should be a valid signature for the input message under the new public key. And the new public key should be derived via the secret key to public key homomorphism, the input token and the old public key. For example, in the BLS signature scheme, the signature of a message M under secret key SK is the hash of the message M raised to the SK. In this case, the ADAPT algorithm will output PK times G to the delta as the newly obtained public key, and sigma times the hash of the message M raised to the delta as the new signature. Given a key homomorphic signature scheme, it is possible to generically construct an updateable signature as long as the starting primitive satisfies an additional requirement that the error and slamming name perfect adoption, which however, all natural schemes seems to provide. Such generic transformation works as follows. In each epoch, signature and verification work as for the underlying key homomorphic signature. Whenever the next algorithm is run, it samples the update token as a fresh uniform element from the secret key group, and sets the new secret key as the sum of the old key plus this update token, and the new public key via the secret key to public key homomorphism. In this way, both new secret key and new public key are uniform elements in the respective groups. To update all signatures, one runs the ADAPT algorithm of the key homomorphic scheme which is guaranteed to produce a valid signature for the new public key, which moreover looks as a fresh one under this additional requirement of perfect adoption that we mentioned before. This last requirement is not only necessary to prove the unlinkability of the so-obtained updateable signature, but it's also required in our proof homomorphic ability as Erkan will later tell you. A second construction that we provided is based on the lattice-based GPV signature scheme. To briefly recall it, in such a scheme, the public key is a uniformly random matrix of appropriate dimensions over ZQ, and the associated secret key is a sufficiently short basis of the kernel lattice defined by the public key. Using the full domain hash paradigm, to sign a message M, one first applies the hash function to the message to obtain a random vector H of M. A valid signature corresponds then to a short preimage of H of M. In the illustration, yellow represents uniformly random matrices or vectors and green short ones. To prove the security of the scheme, one then leverages on the programmability of the random oracle. The reduction first samples the short vector, and then sets the oracle value on the message M to be the so-obtained value H of M. Using techniques from the proxy re-signature approach of FN and U, we can construct a US scheme as follows. In each epoch, the sign and verification algorithms are the ones from the GPV scheme. The next algorithm runs the key generation algorithm of the GPV scheme to obtain a uniformly random matrix together with a corresponding short basis, which will be the public key and secret key of the new epoch. To produce the update token, the algorithm basically uses the secret key of the new epoch to sign the old public key. We then get that the update token is a short matrix that maps the new public key to the old one. Such update token can then be used to update, by multiplication, old signatures to the new epoch. We can see already that updated signatures do not look as fresh ones. Even if both matrices involved in the update process are short, and so the resulting signature is also somewhat short, the norm of signatures increases with each update, and hence can be used to distinguish fresh signatures from updated ones. One can then check that the so-produced signature verifies under the new public key by simply writing down the verification equation and using the way the update token was produced to verify the above equality. I will now hand it over to Erkan for the next part of the... Before presenting our update above Mac construction, let's first remember the canonical Mac construction from a PRF. Let F be a secure PRF, then we can construct a Mac as follows. The signing operation involves just evaluating the PRF on the message to obtain the tag, which is denoted here with sigma. The verification involves just re-evaluating the PRF on the message and then comparing the result with the tag obtained from the signing procedure. Now in order to introduce updating capabilities to such a Mac, we need to replace the PRF with the key homomorphic variant. We say that the PRF is key homomorphic if it is a secure PRF, and in addition, its input and output spaces are groups. And for every input X, we have that adding two PRF evaluations at X, but under two different keys yields a PRF evaluation at X under the combined key. Using such a key homomorphic PRF, we can construct an updatable Mac as follows. The signing operation remains the same as in the canonical Mac, where we just evaluate the PRF on the message M under the key K1 in this case. To update the tag sigma 1, we evaluate the PRF on the message, but this time under the update token delta 2, which is defined as K2 minus K1. So if we add the output of this PRF evaluation to the previously computed sigma 1, what we end up with is sigma 2, which is just PRF evaluation on the message M under the key K2. So essentially K1 cancels out due to the key homomorphic properties of the underlying PRF. Lastly, to verify the Mac, we proceed as in the canonical Mac construction and just reevaluate the PRF on the message M under the key K2 and compare it with the previously obtained tag sigma. So far, we only considered perfectly correct key homomorphic PRFs. However, Bonnetau showed that one can also obtain lattice-based key homomorphic PRFs if the definition is relaxed a bit. More precisely, we can consider almost key homomorphic PRFs where the homomorphism in the key space is noisy. So essentially, we have equality up to an added noise term. However, this breaks correctness. Because now, after the update operation, we end up with the PRF evaluation with an addition of noise term. And if we were to naively compare that with the fresh evaluation of the PRF from the verification procedure, then the two tags won't be equal. The work around to this is to consider approximate canonical verification or more precisely, noisy equality check, where the verification operation computes the distance between the two tags and only succeeds if the distance between the two is smaller than some bound delta. Next, I will talk about the high-level idea of our PRF technique. Essentially, we reduce the updateable unforgeability of our constructions to the unforgeability of the underlying MAC or signature scheme. In order to prove that, we use the key insulation technique of QuoCetal, where we define an insulated region of epochs, which avoids trivial wins by the adversary. More precisely, we consider an insulated region where no key inside the region is corrupted, the tokens on the borders of the region are not corrupted, and lastly, all tokens inside the region are corrupted. To demonstrate this pictorially, let's consider the following eight epochs and the keys, tokens, and signatures associated to them. Here, we assume that the objects marked with red are already corrupted by the adversary. Then, we can set our insulated region to be the region between the epochs 3 and 7 because it satisfies all the properties of insulated region previously described. More precisely, no key inside the region is corrupted, but all the tokens are corrupted, and furthermore, no token on the borders of the region are corrupted. This kind of insulated region rules out a trivial forgery by the adversary. Once we have defined such an insulated region, our proof proceeds as follows. First, we associate the EUF-CMH challenger of the underlying signature scheme, sigma, to an epoch within the region, for example to epoch E- here, which is on the left border. Next, since we do not know the secret keys within the region, we implicitly set them by sampling a random update token delta for each epoch, and use the secret key to publicly homomorphism of sigma to set the public keys recursively as shown here. Lastly, we use the challenger of sigma and the ADAPT algorithm to answer the queries and adapt the forgery. For example, if we get query for the 5th epoch, we query the message to the challenger of sigma to obtain the signature, then we use the obtained signature within the ADAPT algorithm of sigma to move it in the forward direction. And we continue to do this until we reach the target epoch, in this case epoch 5. And due to the adoption property of sigma, we have that the adopted signature and freshly computed one are identically distributed and hence indistinguishable for the adversary. We follow a similar approach for outputting the forgery. For example, if our adversary outputs a forgery for epoch 6, then we can use the ADAPT algorithm to adapt the forgery backwards until we reach the epoch E- where the challenger of sigma is associated. This establishes on a high level how our security proof works and I refer you to our paper for the full details of the proof. Next, we provide an overview and describe our instantiations. We overview here the updateable signature schemes that we obtain. The UUCMI column specifies whether the scheme achieves unlinkability, the UB column specifies whether it supports an unbounded number of epochs, and MDMI stands for message dependent and message independent, where message independent schemes do not require the message during the update procedure, which in turn can improve the performance of the scheme. Since we can generically obtain updateable signatures from key homomorphic signatures, it follows that we can instantiate updateable signatures from many different schemes. For example, we obtain updateable signature from BLS, which is unlinkable and supports unbounded number of epochs. Furthermore, it can be instantiated as either message dependent or message independent. We obtain identical features also using the pointevel sender signature scheme. We obtain similar features also for water signature, however, we only obtain message dependent construction from it. Lastly, using the GPV signature, we can obtain lattice-based scheme that is message independent and provides only bounded number of updates, where the bound T is polyvogarithmic for this scheme. However, we note that this construction does not achieve unlinkability, and it only achieves unforgeability in a weakened model. I refer you to our paper for the concrete details. Analogously, we can instantiate UMAC using various key homomorphic PRFs. For example, using Naor, Pincas, Rheingold PRF, we obtain a scheme that achieves unlinkability and supports unbounded number of epochs. Furthermore, it can also be turned into a message independent scheme. Additionally, using the recent lattice-based almost key homomorphic PRFs, we obtain a scheme that is message dependent and supports only constant number of epochs. And even though these schemes are almost key homomorphic and there is an error term involved, we can still achieve unlinkability using our epoch-dependent error trick, for which I refer you to our paper. Next, we conclude and list some open questions. In conclusion, we introduce new cryptographic primitives, namely updateable MAC and updateable signature. We provided generic constructions from key homomorphic PRF and key homomorphic signature. In our paper, we also describe how to do message independent updates in order to improve the performance of the schemes. And additionally, we provided post-quantum instantiations using lattice-based signature and almost key homomorphic PRF. Finally, we leave two open questions. First, as we already mentioned, our lattice-based updateable signature scheme provides security only in the weakened model. This naturally brings us to the following question. Can we construct lattice-based updateable signature that achieves full security? Second, our construction of UMAC for almost key homomorphic PRFs involves a noise term which grows with every update. In our constructions, we took the conservative approach and only assumed a constant number of updates. And this brings us to the following question. Can we provide concrete bounds for the number of supported epochs for UMAC from almost key homomorphic PRF? With that, I want to conclude. Thank you for your attention.