Methods for verifying a key

Abstract

A method for verifying a key is provided. The method comprises a receiver generating a plurality of ephemeral keys, creating a digest of which each of the generated plurality of ephemeral keys is a member, and generating a signature of the digest. A sender subsequently verifies that the ephemeral key is a member of the digest, and verifies that the signature of the digest to confirm that the digest was signed by the receiver. If the ephemeral key is a member of the digest and the signature is verified, the sender generates a session key based on the verified ephemeral key.

Description

[0001] METHODS FOR VERIFYING A KEY

[0002] Technical Field

[0003] The present invention relates to methods for verifying a key, an information processing apparatus, and a program.

[0004] Background

[0005] The transition from classical to post-quantum cryptography marks a significant shift in the field of information security. Classical cryptography relies on the computational difficulty of certain problems like factoring large numbers or solving discrete logarithms. These cryptographic systems have served well for decades and have been used to provide secure communication over the internet and to safeguard sensitive data.

[0006] However, with the advent of quantum computing, these classical cryptographic systems are at risk. Quantum computers have the potential to solve problems that are computationally infeasible for classical computers. For instance, Shor’s algorithm, when run on a sufficiently large quantum computer, could factor large numbers efficiently, breaking some cryptographic algorithms.

[0007] This potential threat has led to the development of post-quantum cryptography (PQC), also known as quantum -resistant cryptography. PQC aims to develop cryptographic systems that are secure against both classical and quantum computer attacks. These new algorithms are based on mathematical problems that are believed to be resistant to quantum computing attacks, such as lattice-based problems, code-based problems, hash-based problems, and others.

[0008] The transition to post-quantum cryptography is not just a technical challenge, but also a logistical one. It involves updating and testing new algorithms, ensuring backward compatibility, and maintaining interoperability across different systems. Accordingly, developments in systems for performing cryptography are desired.

[0009] Summary

[0010] According to a first aspect of the present invention, there is provided a method for verifying a key, the method comprising: a receiver generating a plurality of ephemeral keys; creating, by the receiver, a digest of which each of the generated plurality of ephemeral keys is a member; generating, by the receiver, a signature of the digest to allow authentication of the digest being signed by the receiver; uploading, by the receiver, the digest, the signature, at least a key of the generated plurality of keys to the central actor; downloading, by a sender, the ephemeral key of the plurality of keys, the digest, and the signature from the central actor; verifying, by the sender, that the ephemeral key is a member of the digest; verifying, by the sender, the signature of the digest to confirm that the digest was signed by the receiver; and in a case that the ephemeral key is a member of the digest and the signature is verified, generating by the sender a session key based on the verified ephemeral key.

[0011] The receiver may upload the plurality of ephemeral keys to the central actor.

[0012] In some implementations, the sender downloads the plurality of ephemeral keys. The sender may verify that the ephemeral key is a member of the digest by using the plurality of ephemeral keys to recreate the digest and checking the recreated digest against the downloaded digest.

[0013] In some case, the central actor generates a witness for the ephemeral key of the plurality of ephemeral keys. The witness may allow the sender to verify that the ephemeral key is a member of the digest. The central actor may generate the witness in response to a request for the witness from the sender.

[0014] In other implementations, the receiver generates and uploads a witness associated with the key.

[0015] The digest may be created using a cryptographic accumulator. The cryptographic accumulator may be a Merkel tree. The digest may be the root of the Merkle tree. The cryptographic accumulator may allow proof that the ephemeral key was used to generate the digest. The cryptographic accumulator may be configured so that it is difficult to generate a key and, in some implementations, a witness for a digest that is not a key that was used to generate the digest.

[0016] The signature may be generated with a private signature key. The private key may be a signature key of the receiver. In other implementations, the private signature key may be a signature key for a ring signature scheme.

[0017] The plurality of keys may be ten or more keys. The method for verifying a key may be part of a key agreement for a messaging protocol.

[0018] In some implementations, the sender may generate a response package. The sender may upload the response package to the central actor. The receiver may download the response package and, in some examples, the receiver generates the session key based on the response package.

[0019] The receiver may upload indices associated with the plurality of ephemeral keys such that an index is associated with each key of the plurality of ephemeral keys. The response package may include an index that identifies an ephemeral key of the plurality of ephemeral keys that was used to generate the response package.

[0020] A second aspect of the present invention may provide one or more program that, when executed by a system for verifying a key comprising a receiver, a central actor, and a sender, causes the system to perform a method according to the first aspect.

[0021] According to a third aspect of the present invention there is provided a system for verifying a key comprising a receiver, a central actor, and a sender, the receiver being configured to: generate a plurality of ephemeral keys; create a digest of which each of the generated plurality of ephemeral keys is a member; generate a signature of the digest to allow authentication of the digest being signed by the receiver; and upload the digest, the signature, at least a key of the generated plurality of keys to the central actor; the sender being configured to: download the ephemeral key of the plurality of keys, the digest, and the signature from the central actor; verify that the ephemeral key is a member of the digest; verify the signature of the digest to confirm that the digest was signed by the receiver; and generate, in a case that the ephemeral key is a member of the digest and the signature is verified, a session key based on the verified ephemeral key.

[0022] Further features and advantages of the invention will become apparent from the following description of preferred embodiments of the invention, given by way of example only, which is made with reference to the accompanying drawings.

[0023] Brief Description of the Drawings

[0024] Figure l is a diagram showing two communication devices and a server;

[0025] Figure 2 is a schematic diagram of an information processing apparatus; Figure 3 shows an embodiment based on the X3DH key agreement protocol;

[0026] Figure 4 illustrates features of a Merkle tree; and

[0027] Figures 5a and 5b show a post-quantum Signal-conforming Authenticated Key Exchange protocol.

[0028] Detailed Description

[0029] A likely feature of the transition from classical to post-quantum cryptography is that the protocols will become more complex and computationally intensive. A further feature is that the sizes of some data elements, such as signatures, is likely to become larger.

[0030] Signal protocol is an example of a classical messaging protocol. The protocol includes two parts: an extended triple Diffie-Hellman (X3DH) key agreement, during which parties that are to exchange messages agree a symmetric key and double Ratchet algorithm to exchange messages. The Double Ratchet algorithm allows parties to derive new keys for each message in a conversation so that earlier keys cannot be derived from later ones and later keys cannot be derived from earlier keys. The symmetric key derived from the X3DH key agreement acts as an input to the Double Ratchet algorithm such that both parties that are communicating can derive the keys used to encrypt messages exchanged between the parties, but other parties that do not have the symmetric key cannot.

[0031] A user may wish to separately exchange messages with several different people. This doesn’t refer to group messaging where a single message is sent to several different users at the same time, but to different sequences of messages, which may be referred to as conversations, that are separate and use different symmetric keys. Accordingly, a key agreement process, such as X3DH, may be performed more than once to generate shared symmetric keys for use with each different sequence of messages (conversation) with a different party.

[0032] A further feature of Signal and similar protocols is that they are asynchronous. A user of a messaging service may wish to be able to send a message regardless of whether the recipient is online. The messages are accordingly sent via a server, cloud service, or the like (referred to herein as a central actor) that ideally is always available (and in practice has high availability). To allow messages to be sent to a recipient while the recipient is offline, including starting new conversations, a recipient may upload information for pre-key bundles to the server that includes information needed to generate a session key and send a message to the recipient. As the recipient may not know in advance who they will receive a message from, the pre-key bundle needs to be peer-oblivious and not dependent upon details of the sender sending the message.

[0033] The recipient may also not know how many messages from new senders they will receive while they are offline. Accordingly, the protocol may allow the recipient to upload information for a number (for example ten or one hundred) pre-key bundles to the central actor. Accordingly, several different senders may start conversations with a recipient while the recipient is offline each using one of the pre-key bundles.

[0034] Post-quantum substitutes for Signal are known such as PQXDH (see also Keitaro Hashimoto, Shuichi Katsumata, Kris Kwiatkowski, and Thomas Prest. An efficient and generic construction for Signal’s handshake (X3DH): Post-quantum, state leakage secure, and deniable. In Juan Garay, editor, PKC 2021, Part II, volume 12711 of LNCS, pages 410-440. Springer, Heidelberg, May 2021). Key Encapsulation Mechanism (KEM) variants of the double ratchet protocol are also known.

[0035] The following embodiments will illustrate improved messaging protocols according to various embodiments, including an embodiment based on X3DH. The messaging protocols each use a similar hardware system, an example of which is shown in Figure 1. Figure 1 illustrates a plurality of communication devices 10 that can exchange messages via a central actor 10. While Figure 1 shows two communication devices 10, more communication devices 10 may be included. The communication devices may be devices such as mobile phones, information processing apparatus such as computers or laptop computers, loT devices, etc. A wide range of devices may be used and are not all listed here, but include messaging applications built into cars, secure messaging between applications, etc. The central actor includes an information processing apparatus and may be implemented as a server, a cloud service, by distributed computing or otherwise. As will be explained in more detail below, the central actor serves to receive and store information from the communication devices, allowing for asynchronous communication as discussed above.

[0036] The communication devices and the central actor can communicate with each other via one or more networks. The communications networks may each comprise one or more different physical networks which are interconnected. For example, and without limiting the scope of the present disclosure, the communications network may include the public internet, and one or more local area networks.

[0037] The communications networks may be wireless communications networks, operating according to a cellular wireless communications specification, such as in accordance with the 3 GPP 2G (GSM / GPRS / EDGE), 3G (UMTS), 4G (LTE) or 5G (NR) standards or in accordance with a local area or personal area wireless communications network, such as in accordance with an IEEE 802.11 standard, a Bluetooth standard, or a Zigbee standard.

[0038] In some embodiments, either or both communications networks may be particularly suitable for loT devices and may accordingly use a suitable communications protocol such as Zigbee or Bluetooth. The communication networks may be a combination of the networks described above.

[0039] Figure 2 is a schematic diagram showing hardware of an information processing apparatus. The information processing unit may comprise a processor 20, a storage 21, an I / O unit 22, a network unit 23, and a power unit 24. Other components may be present but not shown as is well known in the art. The processor 20 is configured to execute instructions and perform computations. The processor may consist of one or more a central processing unit (CPU), a graphics processing unit (GPU) and a neural processing unit (NPU). The storage unit may include both volatile (RAM) and nonvolatile (ROM, SSD, HDD) memory components. The storage unit 21 may store both the instructions to be executed by the processing unit and the data on which these instructions operate. The Input / Output Interfaces unit 22 allows the apparatus to communicate with external devices. Input interfaces may include components like a keyboard, mouse, or touchscreen for user interaction, while output interfaces may include a display, printer, or speakers. The network unit 23 may enable the apparatus to connect to networks (e.g., LAN, WAN, Wi-Fi, Bluetooth, etc.) for data exchange. The network unit 23 may include wired or wireless communication modules. The power unit 24 may provide the necessary power for all components of the apparatus. The power unit 24 may be connected to an external power source or include an internal battery for portable use. First embodiment

[0040] Figure 3 shows an embodiment based on the X3DH key agreement protocol. In addition to a description of the protocol, differences compared to the X3DH protocol will be explained below.

[0041] The following key agreement protocols perform a key agreement between two parties, such as communication devices. The two parties are labelled ‘Alice’ and ‘Bob’ in the following embodiments, but it will be apparent that this is for ease of reference and that the actual identities of the parties do not matter for the purposes of the protocol. Accordingly, Alice may be referred to as a first party or a receiver and Bob may be referred to as a second party or a sender.

[0042] Each party (Alice and Bob) has a long-term signing (identity) key pair Isk. This is a long-term signing key pair can be used to identify the party to each other and includes a private key, skA / skis, and a public key, a I b. In practice, the long-term identity key pair is expected to change infrequently, such as when a party loses their private signing key.

[0043] Each party also has a long-term key public key encryption pair, Ipk. Alice and Bob generate and upload the public portion of their long-term keys to the central actor once. The validity of the long-term keys may be checked between the parties using an authentication mechanism. Further details of this are not provided here but may be found in ‘Moxie Marlinspike and Trevor Perrin. The X3DH key agreement protocol, November 2016’ available from ‘https: / / signal.org’.

[0044] People familiar with X3DH will appreciate that Figure 3 is simplified because it considers the case in which Alice does not upload a one-time prekey for use in generating the session key. However, this does not affect the explanation below, because the one-time prekeys in X3DH are included to prevent replay attacks and do not require a signature. In general the method may include use of one-time prekeys.

[0045] Initially, Alice samples a random integer T times in order to generate T random integers, x,. Alice generates corresponding first ephemeral keys, gXl, where g is a public parameter known to both Alice and Bob. Alice stores each random integer , x,.

[0046] Alice then uses a cryptographic accumulator, Acc, that takes the first ephemeral keys, gXi, and includes them in a digest, d, and generates a corresponding witness, wi, that allows a party to prove that each ephemeral key was included in the digest. An example of a cryptographic accumulator is a Merkle tree. Figure 4 is an illustration of a Merkle tree. At a bottom level of the tree are provided the plurality of ephemeral keys generated by Alice. Adjacent pairs of the ephemeral keys are hashed together to generate a first intermediate layer. The hashes from the first intermediate layer are hashed together to generate a root value 42, referred to herein as the digest 42.

[0047] Figure 4 shows a simple example including four ephemeral keys. However, the scheme may be generalized to have more than two layers and a greater number of ephemeral keys may be provided on the base layer. If the number of ephemeral keys is not a power of two, other dummy values may be generated to complete the Merkle tree.

[0048] By virtue of having hashed the ephemeral keys together to form a single digest (root value), the size of the digest is much smaller than that of the original set of ephemeral keys. A feature of the digest is that by providing a witness, a party may prove that the ephemeral key was used to generate the digest. A witness for the value 40 in the example of Figure 4 is the two values, 43 and 44 illustrated by black boxes in Figure 4. These values define a branch of the Merkel tree. The ephemeral key 40 for which the witness is being provided may be hashed with a first part of the witness 43 corresponding to the adjacent ephemeral key (black box on the base layer) to generate a first hash value 41 on the first layer. The first hash value 41 may be hashed with a second part 44 of the witness to generate the digest 42. By virtue of the presumed difficulty in determining the input value of a hash function based on its hash, it is assumed to be impossible for a third party to generate an ephemeral key and witness based on the digest that is not in the set of original ephemeral keys used to create the digest.

[0049] A Merkle tree is only one example of a cryptographic accumulator and further examples of accumulators are described in, for example, Anais Barthoulot, Olivier Blazy, and Sebastien Canard. Cryptographic accumulators: New definitions, enhanced security, and delegatable proofs. Cryptology ePrint Archive, Paper 2024 / 657, 2024.

[0050] Symmetric accumulators do not require a witness to verify presence in the digest. Accordingly, use of a witness is optional depending upon the implementation. On the other hand, asymmetric accumulators are currently available that have better size properties, such as having a constant digest size. Accordingly, some implementations may use an asymmetric accumulator. A witness may be generated by Alice (or in some implementations the central actor) for each accumulated ephemeral key. As noted, in some examples, the accumulator may produce a fixed sized digest regardless of the number of accumulated ephemeral keys.

[0051] After generating the digest and witnesses, Alice signs the digest, d, using longterm signing key, skA, to generate a signature of the digest, OA.

[0052] Alice uploads an identifier, Alice, the plurality of first ephemeral keys, gXl, the witnesses, w,, the digest, d, and the signature, OA, to the central actor in a pre-key bundle. Alice may also upload an index associated with the ephemeral keys to allow Alice and Bob to identify each ephemeral key of the T first ephemeral keys.

[0053] Sometime later, Bob wishes to start a conversation with Alice. Bob downloads a first ephemeral key, gXc, a corresponding witness, wc, and the digest, d, from the central actor. Bob only needs a single ephemeral key, gXc, to start a conversation. Accordingly, in some implementations, Bob does not need to download all the ephemeral keys or witnesses. In this example, the index may be ‘c’ which identifies the ephemeral key that Bob has downloaded.

[0054] Bob verifies that the signature of the digest, d, belongs to Alice using Alice’s public signature key, a. Bob also checks that the first ephemeral key, gXc, is a part of the digest, d, using the witness, wc, as described above.

[0055] If both of these tests are passed, Bob samples a random integer, y.

[0056] Bob generates a second ephemeral key, gy.

[0057] Bob generates a session key, kB, as follows: kB'•= KDF((gXc b, (ga y, (gXc y

[0058] Bob uploads a response package including identifiers for Alice and Bob (Alice, Bob to identify the conversation, and the second ephemeral key, g', to the central actor and deletes the value, y. Bob may also upload the index, c, to allow Alice to identify the first ephemeral key that Bob is using in the key agreement method.

[0059] Alice retrieves the second ephemeral key, g', from the central actor and, using the index identifies the first ephemeral key that Bob has downloaded. Alice then generates the same session key as Bob (assuming that both parties behave honestly) by calculating: kA-.= KDF gbrc^gy^gyyc

[0060] Now that both parties have derived a common session key, the parties can exchange messages using a protocol such as double ratchet.

[0061] A feature of the method described above is that individual signatures were not generated for each of the first ephemeral keys, gXl, and were not uploaded to the central actor. Instead, the keys were included in a digest, d, and the digest was signed. The signature of the ephemeral keys is required because otherwise a malicious central actor can potentially mount a person-in-the-middle attack by substituting the ephemeral keys with something that it has generated.

[0062] This modification to use accumulators may be surprising for a classical scheme in which the signatures are relatively small (although a benefit of reduced size of data to be transferred and stored at the central actor may still be still achieved), but this benefit becomes greater when considering post-quantum signature schemes in which the signatures are larger and the need to upload a large number of separate signatures may be undesirable.

[0063] Second embodiment

[0064] Figure 5a shows a further key agreement method for generating a session key. This embodiment involves communication between a receiver (Alice) and a sender (Bob). Each party has a long-term encryption key pair, dk, ek, and a long-term signing key pair, sk, vk. Both parties have access to common parameters including a randomly chosen seed, s, and common parameters for setting up two key encapsulation mechanisms. These may be shared via the central actor (illustrated by a server in Figures 5a and 5b) or some other mechanism.

[0065] The parties may use some or all parts of a first key encapsulation mechanism (KEM). The first key encapsulation mechanism may be IND-CCA secure (INDistinguishability under adaptive Chosen Ciphertext Attack). The first key encapsulation mechanism includes a key generator, KEM.KeyGen, an encapsulation function KEM.Enc, and a decapsulation function, KEM.Dec.

[0066] The parties may also make use of some or all parts of a second key encapsulation mechanism (wKEM). The second key encapsulation mechanism may be a KEM which is IND-CPA secure (INDistinguishability under Chosen Plaintext Attack). The second key encapsulation mechanism includes a key generator, wKEM.KeyGen, an encapsulation function wKEM.Enc, and a decapsulation function, wKEM.Dec.

[0067] The parties may also make use of some or all parts of a signature scheme that includes a key generator, SIG.KeyGen, a signature function, SIG. Sign and a verification function, SIG.Verify.

[0068] The top of Figure 5a shows that both Alice and Bob upload their long-term public keys (IpkA and Ipkn) to the central actor (shown as a server in Figures 5a and 5b). The terminology here differs from the first embodiment and is as follows. Isk are the long-term secret keys and include a private decapsulation key, dkA, and a signature key, skA. Ipk are long-term public keys and include the public encapsulation key, ekA, and the public signature verification key, vkA.

[0069] The method for generating a session key begins with Alice generating a plurality of ephemeral encapsulation keys, ek-r, and decapsulation keys, dl< r, using wKEM.KeyGen. Alice may generate T ephemeral encapsulation keys where T is a predetermined number.

[0070] As with the first embodiment, Alice uses an accumulator function, Acc, to accumulate the ephemeral encapsulation keys, ek-r, into a digest, d. Alice also generates a witness, w,, corresponding to each ephemeral encapsulation key. Alice then signs the digest to generate a signature, OA. The accumulator function may be a Merkle tree or other accumulator function as described in connection with the first embodiment. Accordingly, the description of the accumulator is not repeated.

[0071] Alice stores the set of ephemeral encapsulation and decapsulation keys.

[0072] Alice sends the ephemeral encapsulation keys, ek-r, (ephemeral keys), the digest, d, the witnesses, w,, and the signature, OA, to the central actor. These ephemeral encapsulation keys are receiver oblivious. The central actor stores the ephemeral encapsulation keys, ek-r, (ephemeral keys), the digest, d, the witnesses, w,, and the signature, OA. Alice may send an index (not illustrated) associated with the ephemeral encapsulation keys, ek-r, that allows Alice and Bob to identify which ephemeral encapsulation key is being used.

[0073] Turning now to Figure 5b, in a case that Bob wants to start a conversation with Alice, Bob downloads an ephemeral encapsulation key, ek-r, the digest, d, a witness, w, corresponding to the ephemeral encapsulation key, and the signature, OA. AS before, Bob only needs a single ephemeral encapsulation key to start a conversation. Accordingly, in some implementations Bob may not download all the ephemeral encapsulation keys.

[0074] Bob checks that the ephemeral encapsulation key is accumulated in the digest, d, using the witness, w. Further Bob checks the signature, OA, of the digest against the digest using Alice’s public signing key, vk\. If both tests are passed, Bob continues with the key exchange method.

[0075] Bob generates a ciphertext CT that encapsulates a value KT using the received ephemeral encapsulation key, ekT , and key encapsulation function wKEM.Encap(ekT).

[0076] Bob further generates a second ciphertext C that encapsulates a value K. To do this, Bob generates an ephemeral key pair, ekA, dkA, using key generation function, KEM.KeyGen. Bob generates the second ciphertext C that encapsulates a value K using Alices’ s long-term public encapsulation key, ekA, and key encapsulation function KEM.Encap(ekA).

[0077] Bob uses an Extractor function (a strong randomness extractor such as HMAC- SHA256) Exts to generate two intermediate keys in the form of pseudo-random function (PRF) keys, Ki and K2.

[0078] Bob is then in a position to generate a session identifier, sid, formed from a concatenation of an identifier of Alice, an identifier of Bob, the long-term public keys (encryption and signature) of Alice, the long-term public keys (encryption and signature) of Bob, the exchanged ephemeral encapsulation key downloaded by Bob (ek^, the ciphertext CT and the second ciphertext C.

[0079] Bob computes a pair of keys kB and k using a pseudo-random function, F. An example of the pseudo-random function is HMAC-SHA256, but other functions may be used. These keys are generated using an exclusive OR of the output of the pseudorandom function operating on PRF key Ki and the session ID, sid, and the pseudo- random function operating on PRF key K2 and the session ID, sid. A first of those keys, ku, is the session key, which is the output of the key generation method, and the second of the keys, k , will be referred to as the signature key. While an exclusive OR is used to generate the pair of keys in the example above, a sum or modulo of the pseudorandom functions may be used in alternative implementations.

[0080] Bob signs the session ID, sid, using its long-term secret signing key skB to generate a signature 6.

[0081] The signature is encrypted using the signature key, k to generate a ciphertext, c.

[0082] Bob sends a response package including the ciphertexts, C, CT and c to the central actor. Bob also sends the index received the central actor that identifies the ephemeral encapsulation key that Bob downloaded.

[0083] Alice downloads the ciphertexts and the index from the central actor.

[0084] Alice then performs the following steps to generate the session key, kA, and verify the identity of Bob. Alice uses the decapsulation function, its long-term private decapsulation key, dkA, and received second ciphertext, C, to generate value K. In other words, Alice calculates KEM.Decap(dkA, C).

[0085] Alice also uses the ciphertext CT, the decapsulation function and the ephemeral decapsulation key, dkT, that was previously generated but not exchanged with Bob to generate value, KT. The ephemeral decapsulation key, dkT, can be identified using the index provided by Bob with the ciphertexts.

[0086] Similar to the operation performed by Bob, Alice uses the Extractor function Exts to generate two pseudo-random function (PRF) keys, Ki and K2.

[0087] At this point Alice can generate a session ID, sid, which should be the same as session ID, sid, generated by Bob if the parties are behaving honestly. The session identifier, sid, is formed from a concatenation of an identifier of Alice, an identifier of Bob, the long-term public keys (encryption and signature) of Alice, the long-term public keys (encryption and signature) of Bob, the exchanged ephemeral encapsulation key (ekT), the ciphertext CT and the second ciphertext C.

[0088] Alice then computes the pair of keys kA and k using the pseudo-random function, F. The keys are generated using an exclusive OR of the output of the pseudorandom function operating on PRF key Ki and the session ID, sid , and the pseudo- random function operating on PRF key K2 and the session ID, sid. A first of those keys, kA, should be the same session key as generated by Bob, if the Parties are acting honestly. As above, the second of the keys, k , is referred to as the signature key.

[0089] Alice can verify the identity of Bob as follows. The ciphertext c is decrypted using signature key, k . The signature can be verified by using a signature verification function that takes the public key of Bob, vkn, the calculated session ID, sid, and compares it with the decrypted signature 6.

[0090] If both parties have behaved honestly, the method ends with Alice having verified the identity of Bob and with both parties having the same session key,

[0091] Alice may delete the ephemeral decapsulation key, dk-r, once the session key, kA, is generated.

[0092] As with the first embodiment, a feature of the above method is that a plurality of ephemeral keys, ek-r, are represented in a digest using a cryptographic accumulator. The digest is signed so that the central actor only receives and stores a single signature from Alice. Bob verifies the ephemeral encapsulation key by checking that it was used when generating the digest (using a corresponding witness in some implementations) and by verifying the signature on the digest.

[0093] As mentioned above, post-quantum signatures can be large in size. For example, Falcon signature (FALCON-1024) may be in the region of 1.2 MB in size. Accordingly, it can be understood that if each user were to upload around one hundred individual signatures that would correspond to around lOOMB per user. WhatsApp RTM is reported to have around 2 billion active users and WeChat RTM is reported to have around 1.3 billion active users. Accordingly, for a widely implemented system, savings in storage may be considerable.

[0094] The above embodiments are to be understood as illustrative examples of the invention. Further embodiments of the invention are envisaged. For example, examples have been given of use of accumulators to reduce signature size costs in connection with X3DH protocol and a post-quantum signal-confirming AKE protocol. However, the technique may be further applied to other key agreement protocols where multiple ephemeral keys may be stored at a central actor, such as a server or the like. Further examples are PQ3 (by Apple RTM) and the Messaging Layer Security (MLS) protocol (RFC 9420). In each case, key packages including an ephemeral key are exchanged to allow generation of a common key and signatures of the key packages are checked. This step in each protocol can be modified by including the ephemeral key in a digest and signing the digest. Subsequently, the ephemeral key may be checked by verifying that the ephemeral key is accumulated in the digest (using a witness in some implementations) and checking the signature of the digest.

[0095] In the above examples, Alice generated the witnesses for the ephemeral keys. In further embodiments, the central actor may generate the witnesses instead of Alice reducing the amount of data that needs to be sent from Alice to the central actor. The central actor receives the ephemeral keys generated by Alice and the digest generated by Alice. Accordingly, by recreating the Merkle tree (or other accumulator) from the ephemeral keys, the central actor may generate the witnesses. The signature of the digest needs to be performed by Alice as only Alice can have Alice’s private signing key.

[0096] In embodiments in which the central actor generates the witnesses, the central actor may generate the witnesses on demand in response to a request from Bob to download an ephemeral key. An advantage of this is that, as explained above, the witnesses include a number of hashes depending on the size of the Merkle tree. In general the size of the proof for a Merkle tree with n leaves has O(log2n)-sized proofs. Accordingly, storing proofs for each ephemeral key for each user may again use a large amount of storage. In contrast, if the witness can be generated on demand, the witnesses do not need to be constantly stored.

[0097] In yet further embodiments in which the accumulator is a Merkle tree, the witnesses may be omitted entirely, and Bob may download the complete set of ephemeral keys. Bob may verify the signature by recreating the Merkle tree from the ephemeral keys and checking the signed digest against the recreated digest.

[0098] The above examples have assumed that the signature of the digest is the signature of the receiver. In some implementations, a ring signature that demonstrates that the receiver is a member of a group, but does not specifically identify the receiver, may be applied. For an example of this, see Keitaro Hashimoto, Shuichi Katsumata, Kris Kwiatkowski, and Thomas Prest. An efficient and generic construction for Signal’ s handshake (X3DH): Post-quantum, state leakage secure, and deniable. In Juan Garay, editor, PKC 2021, Part II, volume 12711 of LNCS, pages 410-440. Springer, Heidelberg, May 2021.

[0099] The term ‘signature’ and may refer in general terms to any mechanism that allows the digest to be authenticated as having been signed by the signer. This may include cryptographic signature schemes and may include any other suitable authentication scheme.

[0100] In the described embodiments, a plurality of ephemeral keys are uploaded to the central actor (say 10 or 100 ephemeral keys). These keys may be refreshed periodically. For example, they may be refreshed when a receiver comes ‘online’ and contacts the central actor or they may be refreshed at a predetermined time interval. The receiver may generate more ephemeral keys than it sends to the central actor. Accordingly, the accumulator may be refreshed at the same time that the keys are refreshed or the accumulator may include keys for a plurality of refreshes of the keys. In these implementations, the keys that have generated, included in the accumulator, but not yet sent to the central actor may be stored at the receiver.

[0101] It is to be understood that any feature described in relation to any one embodiment may be used alone, or in combination with other features described, and may also be used in combination with one or more features of any other of the embodiments, or any combination of any other of the embodiments. Furthermore, equivalents and modifications not described above may also be employed without departing from the scope of the invention, which is defined in the accompanying claims.

Claims

CLAIMS1. A method for verifying a key, the method comprising: a receiver generating a plurality of ephemeral keys; creating, by the receiver, a digest of which each of the generated plurality of ephemeral keys is a member; generating, by the receiver, a signature of the digest to allow authentication of the digest being signed by the receiver; uploading, by the receiver, the digest, the signature, at least a key of the generated plurality of keys to the central actor; downloading, by a sender, the ephemeral key of the plurality of keys, the digest, and the signature from the central actor; verifying, by the sender, that the ephemeral key is a member of the digest; verifying, by the sender, the signature of the digest to confirm that the digest was signed by the receiver; and in a case that the ephemeral key is a member of the digest and the signature is verified, generating by the sender a session key based on the verified ephemeral key.

2. A method according to claim 1, wherein the receiver uploads the plurality of ephemeral keys to the central actor.

3. A method according to claim 2, wherein the sender downloads the plurality of ephemeral keys and verifies that the ephemeral key is a member of the digest by using the plurality of ephemeral keys to recreate the digest and checking the recreated digest against the downloaded digest.

4. A method according to claim 2, wherein the central actor generates a witness for the ephemeral key of the plurality of ephemeral keys, wherein the witness allows the sender to verify that the ephemeral key is a member of the digest.

5. A method according to claim 4, wherein the central actor generates the witness in response to a request for the witness from the sender.

6. A method according to claim 1 or claim 2, wherein the receiver further generates and uploads a witness associated with the key, wherein the witness allows the sender to verify that the key is a member of the digest.

7. A method according to any preceding claim wherein the digest is created using a cryptographic accumulator.

8. A method according to claim 7, wherein the cryptographic accumulator is a Merkel tree, and the digest is the root of the Merkle tree.

9. A method according to any preceding claim wherein the plurality of keys is ten or more keys.

10. A method according to any preceding claims wherein the method for verifying a key is part of a key agreement for a messaging protocol.

11. A method according to any preceding claim, wherein: the sender generates a response package and uploads the response package to the central actor; the receiver downloads the response package; and the receiver generates the session key based on the response package.

12. A method according to claim 11, wherein: the receiver uploads indices associated with the plurality of ephemeral keys such that an index is associated with each key of the plurality of ephemeral keys, and the response package includes an index that identifies an ephemeral key of the plurality of ephemeral keys used to generate the response package.

13. One or more program that, when executed by a system for verifying a key comprising a receiver, a central actor, and a sender, causes the system to perform a method according to any of claims 1 to 12.

14. A system for verifying a key comprising a receiver, a central actor, and a sender, the receiver being configured to: generate a plurality of ephemeral keys; create a digest of which each of the generated plurality of ephemeral keys is a member; generate a signature of the digest to allow authentication of the digest being signed by the receiver; and upload the digest, the signature, at least a key of the generated plurality of keys to the central actor; the sender being configured to: download the ephemeral key of the plurality of keys, the digest, and the signature from the central actor; verify that the ephemeral key is a member of the digest; verify the signature of the digest to confirm that the digest was signed by the receiver; and generate, in a case that the ephemeral key is a member of the digest and the signature is verified, a session key based on the verified ephemeral key.

Images