Authenticated Key Exchange

Abstract

Some embodiments are directed to a system comprising a first cryptographic device 10 and a second cryptographic device 20. Both devices may compute a final seed from a pre-shared secret known to each device and a pre-seed exchanged between the two devices. The final seed can be used to derive a common object a.

Description

[Technical field]

[0001] The subject matter of this disclosure relates to a first cryptographic device, a second cryptographic device, a first cryptographic method, a second cryptographic method, and a computer-readable medium. [Background technology]

[0002] In cryptography, a key agreement protocol is a protocol that allows two or more parties to share a key. The shared key may then be used to protect further communications between the parties, e.g. to authenticate and / or encrypt the further communications. An attacker eavesdropping on all communications between both parties should not learn anything about the key; an attacker looking at the same communications would learn nothing or very little, while both parties themselves would be able to derive the shared key.

[0003] A practical key agreement protocol was introduced in 1976 when Whitfield Diffie and Martin Hellman introduced the concept of public key cryptography. They proposed a system for two-party key agreement that exploits the apparent difficulty of computing logarithms over a finite field GF(q) with q elements. Using this system, two users can share a symmetric key.

[0004] Key agreement protocols are useful in many applications where multiple parties communicate, for example in areas such as the internet of things (IoT) or ad-hoc wireless networks. Key agreement can be used to secure links between devices. Another example is the communication between a reader and an electronic tag, for example a card reader and a smart card, or a tag reader and a tag, for example an RFID tag or an NFC tag.

[0005] To facilitate secure communication between parties, key agreement protocols are sometimes further subdivided into Key Exchange (KEX) schemes and Key Encapsulation (KEM) schemes, which use asymmetric cryptography to establish a shared secret between two parties using a publicly known value (e.g., a public key) and a secret value that each party has (e.g., a private key).

[0006] KEX schemes involve the exchange of public keys by each party, which are then used independently by the other party with their respective private keys to compute a common shared secret. A well-known example of a KEX scheme is the Diffie-Hellman key exchange mentioned above, whose security is based on solving the discrete logarithm problem. Typically, both parties can influence the outcome, so that neither party can force the choice of key. An interesting feature of some KEX schemes is that the actual final shared secret is never exchanged between the parties (even in encrypted form), but is computed independently by both parties. This results in a desirable property known as forward secrecy, ensuring that even leakage of a party's long-term private key to a future attacker does not result in leakage of the secrecy of previously exchanged encrypted messages.

[0007] The KEM scheme uses asymmetric cryptography to establish a shared secret between two entities or parties by one party, usually the initiator of the communication, encrypting the shared secret using the public key of the other party, known as the responder, and sending it to the other party. The responder can then decrypt it using its private key and use it to communicate securely with the initiator party. The KEM scheme does not achieve forward secrecy, since an attacker who compromises one of the parties' private key for a past session and records all messages exchanged between the parties in that session can recover the shared secret for that session.

[0008] Since the Diffie and Hellman paper, new concerns have been raised. Due to the increasing security needs of the IoT, key exchange schemes must further achieve high efficiency and low communication or bandwidth requirements. Also, it is preferable that key agreement protocols are secure against classical and quantum-enabled adversaries.

[0009] Moreover, a drawback of these key agreement protocols is that they do not authenticate the parties. This makes them vulnerable to man-in-the-middle (MITM) attacks. In a man-in-the-middle attack, an attacker can place himself between the first and second party. He can then negotiate a first shared key with the first party and a second shared key with the second party. Thus, he can decrypt everything. Traditionally, both KEX- and KEM-type protocols require, for example, digital signatures to get around this problem. Signing is an action that is typically avoided even in lightweight protocols.

[0010] An approach to address this is the so-called authenticated key exchange (AKE). The AKE protocol can authenticate the identities of the communicating parties at the same time as negotiating the keys. A particularly important type of AKE is password-based AKE (PAKE). PAKE uses a human-memorable password (or passphrase), which may not be cryptographically secure, to authenticate and negotiate a symmetric session key. In PAKE, the password can be shared in advance by both parties.

[0011] In the paper “Efficient Implementation of Password-Based Authenticated Key Exchange from RLWE and Post-Quantum TLS” by Xinwei Gao et al., which is incorporated herein by reference, a post-quantum password-based authenticated key exchange (PAKE) protocol called RLWE-PPK is proposed in Figure 2 of the paper.

[0012] RLWE-PPK is a protocol between two parties (party i and party j) with a pre-shared password pwd. Each party computes two different hashes from the shared password, γ1 = H1(pwd) and γ2 = H2(pwd), which are used to mask and unmask each party's public key before and after sending it to the other party. Computing the shared key requires each party to compute an additional hash, bringing the total number of hashes to three per party. RLWE-PPK is a two-pass implicitly authenticated key protocol. Implicit authentication means that no explicit confirmation of authentication can be computed, but if authentication fails, both parties do not obtain the same key, thus preventing disclosure of communications to unauthorized parties.

[0013] This known protocol has several drawbacks, for example, it requires the computation of three hashes for each key agreement, which can be burdensome for resource-constrained devices. Furthermore, this known protocol requires the public key to be kept secret, since password hashes can be computed from knowledge of the public key and from eavesdropped communications. Summary of the Invention

[0014] It would be beneficial to have a device and / or method with improved authenticated key agreement. Described and claimed herein are cryptographic devices and methods that are intended to address the above and other problems.

[0015] Existing key agreement protocols, even if they are quantum secure, are typically not authenticated, either implicitly or explicitly. It would be beneficial to be able to extend existing key agreement protocols to authenticated key agreement protocols, which are more suitable for use in real-world scenarios where two parties need to verify a communication channel.

[0016] The subject matter of the present disclosure includes a first cryptographic device, a second cryptographic device, a first cryptographic method, a second cryptographic method, and a computer-readable medium. The first and second cryptographic devices may be configured to calculate a final seed from a pre-shared secret, such as a password, and from a pre-seed exchanged between both devices. The final seed may be used to calculate a common object, and the common object may be used to calculate a public key, for example to perform a key agreement protocol.

[0017] The embodiment is useful for preventing man-in-the-middle attacks. Since the first cryptographic device (also called the first party) and the second cryptographic device (also called the second party) have a pre-shared secret, both devices can derive a common object that is used to derive the public key. The attacker cannot compute the common object because he does not have access to the password. Therefore, the attacker cannot interrupt the communication between the two parties because the common object is necessary to perform the correct calculation. Interestingly, the strength of the password is mainly related to the strength of the authentication, and the strength of the derived shared key may not be affected. In particular, the key agreement protocol according to an embodiment can be as strong (e.g., quantum-resistant) as without authentication.

[0018] The embodiments may be implemented more efficiently. For example, in one embodiment, both parties may only perform a single hash function calculation, e.g., to calculate the final seed. Optionally, explicit authentication may be obtained without asymmetric digital signatures. Also, the public key need not be secret. Note that, according to one embodiment, all or most NIST post-quantum cryptography (PQC) lattice-based candidates may be adapted for authentication.

[0019] In one embodiment, the pre-seed is communicated in the clear over the communication channel, while the pre-shared secret is not communicated over the channel or is not communicated in the clear, for example, the communication channel may also be used for other data exchanged between devices in the key agreement protocol.

[0020] Aspects of the subject matter of this disclosure include cryptographic methods.

[0021] The method embodiments may be implemented on a computer as a computer-implemented method, on dedicated hardware, or as a combination thereof. Executable code for the method embodiments may be stored on a computer program product. Examples of computer program products include memory devices, optical storage devices, integrated circuits, servers, online software, etc. Preferably, the computer program product includes non-transitory program code stored on a computer-readable medium for executing the method embodiments when the program product is executed on a computer.

[0022] In one embodiment, the computer program comprises computer program code configured to perform all or part of the steps of the method embodiments when the computer program is run on a computer. Preferably, the computer program is embodied on a computer readable medium.

[0023] Another aspect of the subject matter of the present disclosure provides a method for making a computer program downloadable. This aspect is used when the computer program is uploaded to, for example, Apple's App Store, Google's Play Store, or Microsoft's Windows Store, and the computer program is downloadable from such a store. [Brief description of the drawings]

[0024] Further details, aspects and embodiments are described below, by way of example, with reference to the drawings, in which elements are illustrated for simplicity and clarity and are not necessarily drawn to scale, and in which elements corresponding to elements already described may be given the same reference numerals.

[0025] [Figure 1]FIG. 1 illustrates a schematic of an example embodiment of the KEX protocol. [Diagram 2] FIG. 2 illustrates a schematic of an example embodiment of the KEM protocol. [Diagram 3] FIG. 3 illustrates a schematic of an example embodiment of the protocol. [Figure 4] FIG. 4 illustrates a schematic diagram of an example cryptographic system according to one embodiment. [Figure 5a] FIG. 5a illustrates a schematic diagram of an example cryptographic method according to an embodiment. [Figure 5b] FIG. 5b illustrates a schematic diagram of an example cryptographic method according to an embodiment. [Figure 6a] FIG. 6a illustrates diagrammatically a computer readable medium having a writeable portion containing a computer program according to an embodiment. [Figure 6b] FIG. 6b shows a schematic representation of a processor system according to one embodiment. [Explanation of symbols]

[0026] 10 First Crypto Device 20 Second Crypto Device 10.1~10.3 Encryption operations 11.1 Encrypted Messages 20.1~20.2 Encryption Operation 21.1~21.2 Encrypted Message 13 Out-of-bound communication 14~15 Key sharing protocol 16~17 Message 31 Registration Phase 32 Key Agreement Phase 33 Use Phase 300 First Crypto Device 301 Cryptosystem 305 Communication Interface 315 Public / Private Key Generator 325 Raw Key Generator 335 Adjustment Unit 340 Decapsulation Unit 350 Second Crypto Device 355 Communication Interface 360 Public Key Extractor 365 public / private key generator 375 Raw Key Generator 385 Adjustment Data Generator 390 Encapsulator 1000 Computer Readable Medium 1010 Writable part 1020 Computer Programs 1110 Integrated circuits 1120 Processing Unit 1122 Memory 1124 Special Purpose Integrated Circuit 1126 Communication Elements 1130 Interconnect 1140 Processor System DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0027] While the subject matter of the present disclosure may take on embodiments in various forms, one or more specific embodiments are shown in detail in the drawings and the following description. It is to be understood that the present disclosure is to be considered as an exemplification of the principles of the subject matter of the present disclosure and is not intended to limit the subject matter of the present disclosure to the specific embodiments shown and described.

[0028] For purposes of understanding, elements of an operational embodiment are described below, however it will be apparent that each element is configured to perform the functions described as being performed by each element.

[0029] Furthermore, the subject matter of the present disclosure is not limited to the embodiments, and features described in this specification or recited in mutually different dependent claims may be combined.

[0030] Various embodiments are disclosed below. Various protocols are illustrated in Figures 1-3, for which the first cryptographic device 10 and the second cryptographic device 20 may be configured. In particular, the first cryptographic device 10 and the second cryptographic device 20 may be configured for a key agreement protocol, in particular an authenticated key agreement protocol, more specifically a password authenticated key agreement protocol (PAKE).

[0031] The embodiment may be based on so-called noisy multiplication. For example, to derive a public key from a private key, the first cryptographic device 10 and the second cryptographic device 20 may be configured to multiply a common object (a) with the private key and obtain the public key using noisy multiplication. Many examples of noisy multiplication are known and are used in cryptographic key agreement protocols such as Round5, Saber, Kyber, NewHope, and Frodo. These are examples of lattice-based key exchange and / or key encapsulation mechanisms that allow two parties to agree on a common key. In these schemes, the public key components b and u may be obtained from the respective secrets r and s of the devices 10 and 20 using a parameter a that is conventionally public. At least two key agreement variations may be used, namely the KEX protocol and the KEM protocol. The following notations are used in Figures 1 and 2: - a represents a common object known to the first cryptographic device 10 and the second cryptographic device 20. For example, the common object may be a polynomial in a given ring (e.g., the ring used in RLWE or RLWR), or a matrix with integer entries (e.g., the matrix used in LWE or LWR), or a matrix with polynomial entries. r and s represent the secrets of the parties, e.g. device 10 and device 20. - b and u represent the parties' public keys or public key shares, e.g. obtained as the noisy product of a*r or a*s. The * operation may represent a noisy multiplication, which may be a one-way function of the underlying cryptographic problem (e.g. (R)LWE or (R)LWR, or modular versions of them).

[0032] For example, the LWR a*r may be implemented as Round((Ar(mod q)),p,q). This may be the product of r, a vector of length n, modulo q with a square n-by-n matrix A. Then the result is rounded with integers p and q by doing p / q(Ar)(mod q) (p <q)。 - c represents the encapsulated data. - h represents helper data including reconciliation bits. The function sd is configured to generate a final seed τ from the input and to generate a common object a from the final seed τ. The function grc is a function that generates reconciliation data for an input. For example, the function grc(k) may be configured to return the reconciliation bits from a raw key k. The function grc may also be called get_reconciliation(k). - The function rc is a function for reconciling the raw key using the calibration data. For example, rc(k',h) may be a function that reconciles the raw key k with the given calibration bits h. The function rc may also be called reconciliate(k',h). - The function ecp is a function for encapsulating data using a raw key. For example, ecp(k,K) may mean that the transmission key K is encapsulated with the raw key k. For example, the encapsulation function may mask the key K using the key k in such a way that the effect that an error in k has on m is limited (e.g., linear effect). For example, if k is an element (e.g., a vector, matrix, or polynomial) on Z_q, the key K may also be represented in Z_q. The encapsulation is performed component-wise, e.g., c=k+K·(q / 2)(mod q). The modulus q may be even and in some implementations may be a power of 2. The transmission key K may be a key that can be used as the result of a key agreement protocol. For example, the transmission key may be used to protect subsequent messages between the parties. Further protection may be authentication and / or encryption of subsequent messages. - The function dcp is a function for decapsulating encapsulated data. For example, dcp(c,k') may decapsulate data c using raw key k', returning, for example, a bit string K. The function dcp may also be called decapsulate(c,k'). For example, to decapsulate, we may subtract k' and round to the nearest multiple of q / 2.

[0033] In one embodiment, additional information specific to the parties is used to derive the final seed τ, which is referred to as context information. The context information may include secret information p. This secret information may be secret, for example, to untrusted parties, e.g., parties other than the first cryptographic device 10 and the second cryptographic device 20, or parties other than the first cryptographic device 10 and the second cryptographic party 20 and various trusted parties, such as the manufacturer. The context information may not be secret, e.g., may be public. Using the context information to derive the final seed improves the reliability and freshness assurance of the communication channel. A distinction is made between non-secret information shared in the key agreement protocol, e.g., the pre-seed σ, and further information z, which is not secret but is not shared in the key agreement protocol itself. Examples of further information z include network configuration data, public random beacons, etc.

[0034] For example, to obtain a Password Authenticated Key Exchange (PAKE), each party may share a secret p, e.g., a password, e.g., a PIN. Each party computes a parameter a used for the communication link as a=drbg(hash(σ,p)), where σ is a pre-seed, also called the public seed, e.g., a seed that may also be exchanged in plaintext during the protocol. The pre-seed may be used as input to derive a final seed τ. A common object may be derived from the final seed τ.

[0035] According to this construction, a secure connection with at least implicit authentication is established if each party shares the same p. Since s and r are also secret, the exchanged public components b and u give no information about p. In particular, if s and r are chosen randomly, b and u certainly cannot give any information about p. Note that the security of the link does not depend on the amount of entropy in p, e.g., in the PIN, since the confidentiality guarantee in the key K does not depend on the secrecy of the common object. Advantages of this approach include (i) fewer hashes that need to be computed to obtain the PAKE, and (ii) easier incorporation into existing NIST PQC proposals that compute the common object a from a seed, e.g., as a=drbg(seed). Incorporation may involve changing the way the seed is obtained.

[0036] For example, in one embodiment, the parties are configured as follows: - Obtain a public pre-seed σ. For example, a first party may generate the pre-seed, for example using a random number generator. The first party may send the pre-seed to a second party. In this respect, the pre-seed may be considered public in the sense that it may be shared without cryptographic protection. - Obtain a context-dependent input, e.g., a secret p (e.g., a password and / or further information z), to compute a final seed τ (e.g., τ=Hash(σ|p), e.g., τ=Hash(σ|p|z)), where hash() denotes a hash function and | denotes concatenation. The final seed τ is used to obtain a common object a at each of the two parties. For example, the context-dependent common object may be applied by applying a drbg, e.g., a deterministic random number generator, or PRNG, etc. (e.g., a=drbg(τ)).

[0037] Interestingly, context-dependent (e.g., specific to the current key sharing) common objects can be used. This may be used, for example, to provide implicit authentication when a pre-shared secret is used. This can be used to enhance resistance to man-in-the-middle attacks. This can be used to enhance resistance to pre-computation attacks on the common object.

[0038] Many noisy multiplications in many different fields or rings are known. For example, a noisy multiplication may be performed by performing a true multiplication and adding a noise source. For example, the noise may be explicit noise generated from a noise source, or implicit noise generated, for example, by rounding the result. For example, to round a multiplication modulo q, it may be scaled from a modulo q element to a modulo p element, for example, by multiplying by p / q and rounding the result (p < q). There are various options for rounding the result, such as rounding down to the nearest integer, rounding up, and rounding may include adding a value to reduce bias. Further, or alternatively, the noise source may include the addition of explicit noise to the multiplication result, such as the addition of Gaussian noise.

[0039] For example, the first and second public keys, the first and second secret keys, the first and second raw keys, and the common object may be matrices or vectors over a finite field or ring. For example, the first and second public keys, the first and second secret keys, the first and second raw keys, and the common object may be polynomials over a finite field or ring.

[0040] By binding the common object a in the key sharing protocol to the context information shared by each party, channel authentication can be introduced into standard KEX protocols and KEM protocols such as Round5, Kyber, Frodo. Channel authentication helps to avoid MitM or impersonation attacks.

[0041] Note that in one embodiment, the parameter a used by the parties may be secret. This differs from traditional key agreement protocols, where the common object is typically a public parameter. Advantageously, this further reduces the information available to an attacker wishing to break the cryptosystem.

[0042] An example embodiment of the KEX protocol is shown in schematic form in Figure 1. In Figures 1-3, time increases from top to bottom of the drawing.

[0043] KEX in Figure 1 allows a first party and a second party to share a key that is unlikely to fail because the first and second parties exchange a number of adjustment bits.

[0044] Figure 1 shows a first cryptographic device 10 configured to communicate with a second cryptographic device 20. The first cryptographic device 10 is configured to perform cryptographic operations 10.1.

[0045] Cryptographic operation 10.1 of device 10 may include selecting a pre-seed σ. For example, the pre-seed may be randomly generated. The common object a may be derived in part from the pre-seed. Thus, the entropy in the common object may be controlled via the pre-seed, for example, the common object may be at least as random as the pre-seed. The randomness source is represented in Figures 1 and 2 as $.

[0046] Cryptographic operation 10.1 of device 10 may include computing a final seed τ from a pre-seed σ and a pre-shared secret p. The computation of the final seed τ from two or more inputs, such as in this case the pre-seed σ and the pre-shared secret p, may be performed by applying a function, such as a seed function, such as a hash or key derivation function.

[0047] For example, the pre-shared secret p may be pre-shared between the second cryptographic device and the first cryptographic device. For example, the pre-shared secret p may be shared between the devices via an out-of-bound communication channel. For example, the protocol may be configured to communicate between the devices via a first communication channel, e.g., an electronic communication channel, e.g., a wired or wireless communication channel. The pre-shared secret p may be transmitted in a different manner, e.g., via a second communication channel different from the first communication channel.

[0048] In one embodiment of the second communication channel, the secret p is pre-programmed into one or both of the first device 10 and the second device 20, for example by a manufacturer. For example, the secret p may be pre-programmed into one of the first device 10 and the second device 20 or may be generated in the device. For example, a user may input the secret into the other of the first and second devices via a user interface. For example, the secret may be displayed on a display, displayed in an internet browser, or displayed on a sticker on the device, and then, for example, a user inputs (e.g. types) the secret p into the other device, for example, via a user interface. A hash function or a key derivation function, etc., may be applied to calculate the final seed τ from multiple inputs, for example, from the pre-seed σ and the shared secret p. The hash function may also be applied to the further information z.

[0049] Once the final seed has been calculated, operation 10.1 may include calculating a common object a from the final seed τ. For example, a deterministic random number generator may be used for this. For example, the common object a may be a matrix or a polynomial whose coefficients are randomly calculated from the final seed τ. In FIG. 1, the combination of the calculation of the final seed and the generation of the common object is combined in a function sd. For example, the function sd may be implemented as a combination of a hash and a dbrg, for example, to combine the pre-seed and other inputs into the final seed and to derive the common object from the final seed.

[0050] In one embodiment, the common object, the public key, and the private key include one or more polynomials. The degree of the polynomial may be, for example, at least 128, at least 256, at least 512, etc. The modulus of the common object and / or the private key may be modulo an integer that is at least 2^8, at least 2^9, at least 2^10, etc. The modulus of the private key may be modulo an integer that is at least 2^5, at least 2^6, at least 2^7, etc.

[0051] Act 10.1 may further include obtaining a first private key r associated with the first cryptographic device.

[0052] The private key may be randomly selected, e.g. drawn from a random source. This may increase the security of the protocol, e.g. by further obfuscating the connection between the corresponding public key and the common object. However, it is not mandatory to randomly generate the private keys, such as the first private key r, for each protocol. In one embodiment, a new private key is used by one or both parties to compute the key. However, it is possible that the private key may be reused, e.g. for this particular communicating party, or for multiple cryptographic devices that may execute the protocol. Various restrictions may be imposed on the private key to reduce its size, e.g. the number of non-zero coefficients in the private key may be limited. The latter is optional and not mandatory.

[0053] After a first private key r is obtained, e.g., generated or retrieved from storage, e.g., local storage of the device, operation 10.1 includes computing a first public key b from the first private key r. Computing the public key includes multiplying the private key by a common object a, e.g., using noisy multiplication.

[0054] The first public key b and the pre-seed σ are sent to the second cryptographic device 20. Figure 1 shows a communication 11.1 from the first device 10 to the second device 20. The communication 11.1 may include the first public key b and the pre-seed σ.

[0055] 1 shows a second cryptographic device 20 configured to communicate with a first cryptographic device 10. The second cryptographic device 20 may be configured to perform cryptographic operation 20.1.

[0056] The second cryptographic device 20 is configured to receive the first public key b and the pre-seed σ sent from the cryptographic device 10. The second cryptographic device 20 is configured to retrieve the shared secret p, e.g. from a storage in device 20, e.g. in the same manner as above.

[0057] Operation 20.1 may include computing a final seed from a pre-seed σ received from the first cryptographic device 10 and a pre-shared secret p, for example by applying the same seed function as device 10. Operation 20.1 may be configured such that device 10 and device 20 arrive at the same final seed τ. Operation 20.1 may include computing the same common object a from the final seed. Operation 20.1 may be configured such that device 10 and device 20 arrive at the same common object a.

[0058] Note that the common object does not need to be shared between the first device 10 and the second device 20 via a communication channel, e.g., the first communication channel, and the shared information, e.g., σ, b, is not sufficient to compute the common object, which means that an eavesdropper does not know the common object used.

[0059] Action 20.1 may include obtaining a second private key(s) associated with the second cryptographic device. The options for obtaining this are the same as for device 10, e.g. generated (e.g. randomly generated), e.g. retrieved, etc. A first public key b associated with the first cryptographic device is obtained, e.g. received, from the first device.

[0060] Act 20.1 may include computing a second public key u from a second private key s. The second private key s is computed in the same manner as the first public key b, e.g., computing the second public key u may include multiplying the second private key s with the common object a.

[0061] Operation 20.1 derives k from a first public key b and a second private key s. * The second raw shared key k may include computing a second raw shared key k, also denoted as k = s . Calculating the second raw shared key may include multiplication of the second private key s and the first public key b, which may be the same type of multiplication, but need not be a noisy multiplication.

[0062] The second public key u is sent to the first device 10. Using the second public key u, the first device 10 can calculate a first raw key that is approximately the same as the second raw key. The first raw key and the second raw key may or may not be equal. Various elements may be added to the protocol to reduce potential differences between the first and second raw keys. For example, FIG. 1 shows an example where adjustments are used.

[0063] For example, in one embodiment, operation 20.1 may include generating alignment data h for at least a portion of the modulus of the raw shared key. The alignment data h may include information that enables reducing the difference between the first and second raw keys derived at the first and second devices, respectively.

[0064] Finally, operation 20.1 generates the second raw shared key k *, which may include generating a transmission key K from the

[0065] The second public key u and the adjustment data h are sent to the first cryptographic device 10. Figure 1 shows communication 21.1. For example, communication 21.1 may include the second public key u and the adjustment data h.

[0066] The first cryptographic device 10 is configured to receive the second public key u and the adjustment data h sent from the second cryptographic device 20. The first cryptographic device 10 may be configured to perform a cryptographic operation 10.2.

[0067] Cryptographic operation 10.2 of device 10 may include computing a first raw shared key k' from a second public key u and a first private key r. This may be done in the same way as in the second device 20, but the keys used are different. For example, computing the first raw shared key may include a multiplication between the second public key (u) and the first private key (r). As a result, the first raw key and the second raw key are likely to be close to each other.

[0068] Cryptographic operation 10.2 of device 10 may include applying adjustment data h in an adjustment function to at least some of the coefficients in the first raw shared key k'. As a result, the adjusted first raw key is likely to be equal to the second raw key. The same transmission key K may then be derived from the adjusted first raw shared key (k'). If only some of the coefficients of the raw keys are adjusted, the first and second devices may use the adjusted coefficients to calculate the transmission key and ignore the unadjusted coefficients. There remains a small possibility that the two devices will not arrive at the same transmission key, but this probability is manageable and can be reduced if necessary.

[0069] Cryptographic operations 10.1, 20.1, and 10.2 may be performed in that order.

[0070] Examples of methods for calculating the adjustment data are described in the patent application “REACHING AGREEMENT ON A SECRET VALUE” by the same applicant, application number 16197277.3, filed at the EPO on November 4, 2016. For example, the method on pages 7-10 may be used in embodiments for the adjustment. Variations disclosed elsewhere in this cited patent application may also be employed. The following notation is used in this application for the following three functions:

[0071] 1. Rounding Functions

number

number

number

number

number

[0072] 2. Cross-rounding functions

number

number

number

number

[0073] 3. Adjustment function rec(w,b):

number

number

number

[0074] These three functions may be applied coefficient-by-coefficient to a polynomial, matrix, etc. The adjustment functions above are used herein as examples. As mentioned above, the adjustment methods in the above cited applications may also be used. The cross-rounding function may be applied to obtain adjustment data, and the rounding function may be applied to obtain the data to be adjusted. The adjustment data may later be used in the adjustment function to recover the adjusted data. In other words,

number

[0075] In one embodiment, the first and second public keys, the first and second private keys, and the raw key are polynomials over a finite field or ring, where the public key is obtained from the private key by noisy multiplication with a shared polynomial (a). For example, the polynomials may be used in modular lattices where the elements of the lattice are polynomials.

[0076] Figure 2 shows a schematic of an example embodiment of the KEM protocol. The protocol shown in Figure 2 is generally the same as the protocol in Figure 1, except that raw keys are used for encapsulation and the probability of possible differences between the raw keys is reduced in a different way. The advantage of the protocol in Figure 2 is that the second party can encapsulate a random key of its own choosing based on the public key b of the first party. This allows for active security.

[0077] In the embodiment according to Fig. 1, the first device 10 first performs the cryptographic operations, which may be an embodiment of operation 10.1 shown in Fig. 1. The communication 11.1 from device 10 to device 20 may be the same as in Fig. 1.

[0078] FIG. 2 may then proceed to cryptographic operation 20.2 after receiving the pre-seed σ and the public key b. Cryptographic operation 20.2 may be the same as operation 20.1, except that no adjustment data is calculated. Instead, operation 20.2 may include the generation of a transmission key K. The difference between FIG. 1 and FIG. 2 is that in FIG. 2 the second device 20 may have control over what the final transmission key will be, for example, the second device 20 may select it. The selection may be a random generation, but may also be the result of another algorithm.

[0079] Instead of the adjustment data, the transmission is encapsulated with at least a portion of the second raw shared key by applying an encapsulation function (eg, function ecp) to obtain encapsulated data c.

[0080] The encapsulated data c is sent to the first cryptographic device, for example together with the second public key u. For example, the second device 20 may send a communication 21.2 to the first device 10.

[0081] The first device 10 may be configured to receive encapsulated data c sent from the second cryptographic device 20, for example together with the second public key u. The first device 10 may be configured to perform cryptographic operation 10.3. Operation 10.3 is similar to operation 10.2, except that encapsulation is used instead of adjustment to reduce the difference between the first raw key and the second raw key.

[0082] For example, act 10.3 may include obtaining a transmission key K by deencapsulating the encapsulated data c using at least a portion of the first raw shared key k'.

[0083] In one embodiment, the transmission key K is random and / or ephemeral and / or symmetric and / or independent from the first public key (b).

[0084] For example, the transmission key K may be generated independently from the first private key, the first public key, the second private key, and the second public key, i.e., the transmission key K is independent from the first and second raw keys. Note that the raw keys depend on the public and private keys. For example, the transmission key may be generated at least partially randomly. Independent keys make active security easier to achieve. The randomness for calculating the keys, e.g., the private key or the transmission key, may be obtained from a conventional random number generator, preferably a true random number generation.

[0085] In one embodiment, the common object and the private key are polynomials of degree n with coefficients modulo q. The public key may be a polynomial of degree n modulo p.

[0086] A wide range of parameters is possible, but is generally limited in that the resulting key agreement protocol generates sufficiently large keys with a sufficiently low probability of failure. The latter two parameters may be observed empirically or calculated theoretically. Acceptable values ​​depend on the application.

[0087] Certain advantageous KEM protocols that may be used in conjunction with Figure 2 are described in NIST proposal "Round5: KEM and PKE based on (Ring) Learning with Rounding Thursday 28th March, 2019," which is incorporated herein by reference. For example, Sections 2.9.5 and 2.9.7 provide examples of parameters suitable for a wide range of situations. For example, the above reference provides examples of encapsulation, error correction, and other KEM protocol details.

[0088] For example, the KEM protocol, such as that of FIG. 2, is preferably implemented using a cyclotomic ring Z q [x] / Φ n+1 (x), the reduction polynomial can be any, but the (n+1)th cyclotomic polynomial Φ n+1 (x)=x n +···+x+1 may be an efficient choice. A is a common object Z. q [x] / Φ n+1 (x) can be a d / n × d / n matrix with entries in (x). The private key is

number

number

[0089] For example, the following parameters may be used: d: number of polynomial coefficients per row of the public matrix n: Degree of the reduction polynomial. Also indicates whether an instantiation of a ring (n > 1) or a non-ring instantiation (n = 1) is being used. h: Number of non-zero polynomial coefficients per column of the secret matrix q, p, t, b: Rounding moduli, e.g., all powers of 2 such that b | t | p | q, e.g., b < t < p < q b_bits: Number of bits extracted per symbol within the ciphertext component, = 2 b_bits κ: Security parameter, number of information bits of the transmission key

Number

Number

[0090] For example, in one embodiment, d = 618, n = 618, h = 104, q = 2 11 , p = 2 8 , t = 2 4 , b = 2 1 , κ = 128,

Number

Number

[0091] To further reduce the probability of error, the transmission key may be encoded into a codeword before encapsulation. This may use the following additional parameters. f: Number of bit errors correctable by the error correction code xe: Number of parity bits of the error correction code μ: Ciphertext component

Number

[0092] For example, in the above case, the parameters may be f=0, xe=0, μ=128.

number

[0093] Another instantiation is d=1186, n=1, h=712, q=2 15 , p=2 12 , t=2 7 , b=2 4 , κ=256,

number

number

[0094] Another instantiation is d=490, n=490, h=242, q=2 10 , p=2 7 , t=2 3 , b=2 1 , κ=128,

number

number

[0095] Similar parameters may be used in the protocol according to FIG.

[0096] Various other methods exist for reducing the distance between the first and second raw keys and may be used in addition to or instead of those shown in connection with Figures 1 and 2. For example, in one embodiment both encapsulation and adjustment are used. In that case, the adjusted raw key may be used for the encapsulation. For example, before calculating the adjustment and / or encapsulation, so-called high reliability bits of the second raw key may be selected, e.g. the coefficients of the second raw key that are most likely to generate the same bits in the first device 10. Then, the adjustment and / or encapsulation may be applied to the selected high reliability coefficients. An index of the high reliability coefficient may be communicated from the device 20 to the device 10, e.g. in communication 21.2.

[0097] Examples of various methods for computing the final seed τ, the pre-seed σ, and / or the pre-shared secret p are provided below, each of which may be incorporated into the various key agreement protocols described herein, particularly the protocols of FIGS.

[0098] For example, in one embodiment, the pre-shared secret may include a pre-shared password. For example, the password may be an alphanumeric sequence or a numeric sequence. For example, the pre-shared secret may be obtained via an out-of-band channel.

[0099] For example, in one embodiment, the pre-seed σ may be transmitted and received in plaintext form. For example, the device 10 may randomly generate the pre-seed σ and send it to the second device 20 in plaintext form, e.g., unencrypted. Interestingly, the security of the system is not affected by this: an attacker cannot obtain the common object a from the pre-seed σ alone, and even if he could, the security of the resulting transmission key K system does not depend on the secrecy of the common object a.

[0100] For example, the pre-seed may be transmitted and received over communication interfaces provided in the first device 10 and the second device 20 and used to exchange key agreement protocol communications (e.g., messages) and / or subsequent communications that may be exchanged between the devices in a protected state with a transmission key. In one embodiment, the pre-seed is not sent over these communication interfaces.

[0101] For example, the final seed τ may depend on further information other than the pre-seed and the pre-shared secret. For example, the further information may be included in a hash or key derivation function. For example, the final seed may be further calculated from network configuration data from a network connection between the second cryptographic device and the first cryptographic device. Even if the network configuration data is public data, this is useful for mitigating MitM or spoofing attacks because an attacker needs to track further information.

[0102] For example, the further information may include a network address of the first and / or second cryptographic device, examples of which are an IP address or a MAC address.

[0103] For example, the further information z may include the purpose of the network connection. For example, the purpose of the network connection may be to perform a communication for a particular application. The name of the application may be included in the further communication. The purpose of the connection may be derived from previously derived information. For example, the purpose may be derived using a network port address. The network port itself may also be part of the further information. For example, a key agreement protocol may be performed by reason of a further algorithm that is subsequently executed. An indication of the further algorithm may be used as further information for calculating the final seed and later verified to check whether the further algorithm is actually used or not, or to reject algorithms that do not match the further information.

[0104] For example, the further information z may include a time, and possibly a current date. For example, the first and second devices may first execute a synchronization protocol to synchronize their respective times, and then use the synchronized time as the further information. For example, the current date may be included in the further information.

[0105] For example, the further information z may include an interaction counter. The interaction counter may be maintained by the second cryptographic device 20 and the first cryptographic device 10. For example, the interaction counter may be incremented at least whenever a shared key is derived.

[0106] Further resistance to attacks may therefore be obtained by deriving the final seed τ from three sources: the pre-seed σ, the pre-shared secret p, and further information, which may be shared (e.g., in communication 11.1). In fact, useful protocols with different properties may also be obtained by other choices of the two sources, e.g., deriving the final seed τ from the pre-seed σ and further information z, or, e.g., the pre-shared secret p and further information.

[0107] The network configuration data used in the further information may be from a current network connection between the first cryptographic device and the second cryptographic device and / or the network configuration data used in the further information may be from a previous network connection between the first cryptographic device and the second cryptographic device.

[0108] For example, in one embodiment, if the pre-shared secrets match, then key agreement is successful. For example, the shared secret p can be a PIN or a pre-shared key (PSK). If each party knows the pre-shared secret (e.g., a PIN or PSK), then they can derive a final seed τ, and from there derive a common object a. For example, τ=Hash(p|σ) and a=drbg(τ). After the final seed τ is obtained, the known KEX or KEM protocol using the seed can be run normally. In the case of an attack such as MitM or spoofing, for example, the KEX or KEM protocol will not lead to a shared symmetric key or allow proper decapsulation. Subsequent normal use of the established key will implicitly determine whether both parties shared the same secret p. Implicit authentication can be transformed into explicit authentication. For example, communication 11.1 can include a challenge and communication 21.1 or 21.2 can include the corresponding response. For example, the challenge can be a nonce and the response can be an encryption using the transmission key. After deriving the transmission key, device 10 can verify the response to find out whether device 20 has a secret p that matches its own. The challenge may be implicit, for example, the challenge may be a predefined string.

[0109] The messages of Figures 1 and 2 or subsequent messages may contain a message authentication code or a message authentication tag. If they can be correctly verified, then implicit authentication can be converted to explicit authentication. If they cannot be correctly verified, then the lack of implicit authentication can be converted to the lack of explicit authentication.

[0110] Note that even if a short shared secret is used, for example a PIN consisting of four numbers with only 10000 possible values, this construction ensures that the PIN cannot be easily brute-forced. The reason is that even if the number of secret values ​​p is limited (10000), this value does not pass through the connection, so an attacker cannot derive the PIN used. The values ​​exchanged over the connection, i.e. the public key components b and u, are obtained by multiplying the common object a with s and r. Since both s and r are secret, these public key components cannot be easily related to the shared secret and recovered. In contrast, in traditional algorithms, a hash of the password passes through the connection, which can directly lead to a password leak if the password has low entropy. Another advantage is that neither party learns the other's shared secret, since the common object cannot be derived from knowledge of the public key.

[0111] In one embodiment, the final seed τ is derived from further information z, possibly in addition to the pre-seed σ and the pre-shared secret p. This structure may be utilized in setting up a secure connection between the parties, for example using a network protocol such as IPSec. For example, in one embodiment, the parties establish a connection periodically, in which case the further information may include, for example, the following information: - Information about the current exchange, including (1) the current IP address of the first party, (2) the purpose of the IP connection (e.g., other protocols to be used later), and (3) the time. - Information about previous exchanges, e.g. (1) when a key exchange last took place and (2) the purpose of the exchange. This information may be publicly available, but it means that an attacker may need to track the state between both parties in order to perform a successful spoofing or MitM attack. - A random number from a random number beacon (e.g., the NIST random beacon). If the random number from the last disclosed beacon is used in the further information, the second party knows that this is a new handshake and not a replay. - Information about the current connection (e.g., IP address), so that the corresponding parties can bind the key exchange to that particular IP address, thus avoiding mix-and-match attacks, where parts of the communication are reused in different contexts. - It contains information about the protocol that the first party plans to use later, so that the second party can verify early on whether it is up to the task. Early verification makes DOS attacks more difficult. - Information about previous key exchanges, so that an attacker must track past exchanges to break the protocol.

[0112] Interestingly, if a pre-shared secret p is used, the attacker cannot recover the secret context p based on the public components b and u. In fact, if the space of p, e.g. the size of the security parameter, is large, the security is equivalent to finding a pre-image of the output of the hash function. Thus, if a secure hash function is used, the system is secure. However, even if the secret p has only a limited number of states, in the extreme case only two possible states, the security is still equivalent to the following problem: Given public(a1,a2,b)=(hash(σ,m),hash(σ,1-m),m·A1*s+(1-m)·A2*s) and a public seed, secret m=0 or 1, and secret s, find m, in other words find out whether a1 or a2 was used. In this problem, A1 and A2 are common objects that can be derived in a known way from the seed, e.g. A1=sd(σ,m) can be used.

[0113] The LWE / R assumption states that (A,b=A*s) is hard to distinguish from uniform random. In the above problem, (A1,b=A1*s) and (A2,b=A2*s) are both LWE / R samples that are hard to distinguish from uniform, and therefore hard to distinguish from each other.

[0114] FIG. 3 illustrates a schematic example of one embodiment of a protocol between a first device 10 and a second device 20.

[0115] In Fig. 3, an out-of-bound communication 13 for sharing a pre-shared secret p is shown. The out-of-bound communication 13 may take place during a registration phase 31 of the devices 10 and 20. For example, the out-of-bound communication 13 may be performed during the manufacture of the devices, for example to enable later communication. For example, the out-of-bound communication 13 may be performed partially during the manufacture of the devices, for example to enable later communication. The other device may be provided with the pre-shared secret later. For example, the out-of-bound communication may be performed manually by a user, for example via a user interface on one or both devices. For example, the pre-shared secret may be configured in one device, for example device 20, by setting a switch (for example a dip switch) on the device or by expressing the secret via another interface. The secret may be generated in the other device and configured in the other device.

[0116] In a subsequent key agreement phase 32, the first device 10 and the second device 20 execute a key agreement protocol according to an embodiment (e.g., an embodiment described herein with respect to FIG. 1 or FIG. 2, etc.). In the key agreement protocol, two messages may be exchanged: key agreement protocol message 14 (e.g., as described herein) and key agreement protocol message 15. The key agreement protocol may also include more messages. A pre-shared secret p may be used in the key agreement protocol.

[0117] At the end of the key agreement phase 32, both devices may have a transmission key K that is at least implicitly authenticated with respect to the secret p. If device 10 and device 20 do not have the same agreement, then, at least in most cases, the transmission keys K derived at the two devices will be different.

[0118] In one embodiment, the registration phase 31 and the key agreement phase 32 use different communication channels, for example different communication media, but may also use different frequencies or different frequency bands.

[0119] In a later use phase 33, the transmission key agreed during the key agreement phase may be used. For example, cryptographically protected messages using the transmission key K are exchanged between device 10 and device 20, for example the messages may be encrypted with key K or may include an authentication tag (e.g., a MAC) calculated with key K, or both. The messages may be protected using a key derived from key K. Although FIG. 3 shows two messages 16 and 17, there may be more than two messages, for example four or more, or even just one message. The order of the messages may be in a different order.

[0120] For example, the device 20 may be configured to encrypt a message m with a transmission key K and send the encrypted message to the first cryptographic device 10 (or vice versa). The device 10 may be configured to decrypt the message using the transmission key K.

[0121] The transmission key is a key derived from the raw shared key. For example, the transmission key may be independent from the raw shared key, for example in the KEM protocol. In one embodiment, the key used for encryption may be a hash of the transmission key and the public key. For example, it may be hashed using the recipient's public key, the sender's public key, or both. For example, the transmission key may be derived directly from the raw shared key, for example by hashing the raw key. In one embodiment, the key used for encryption may be a hash of the raw key and the public key.

[0122] The implicit authentication may be converted to explicit authentication in the key agreement phase 32 or in the usage phase 33. For example, a challenge / response protocol may be performed using the transmission key, e.g. directly using the transmission key or using a key derived from the transmission key.

[0123] Interestingly, the challenge / response protocol may be implicit. For example, messages may be authenticated as part of the protection during the use phase 33. If authentication fails, this may mean that the message has been tampered with or that the pre-shared secret p did not match between the devices. In either case, the communication is untrusted and appropriate measures may be taken. Appropriate measures upon detecting a problem may include, for example, aborting the communication, initiating a new key agreement protocol, sending a warning message (e.g., email, alarm, etc.).

[0124] For example, during the use phase 33, messages may be encrypted as part of the protection. If the message contains predictable parts, such as predetermined strings or headers (e.g., counters), the predictable parts may be verified after decryption. If the predictable parts do not match the expectations after decryption, it may be concluded that the message has been tampered with or that the pre-shared secret p did not match between the devices. In this case, appropriate action may be taken.

[0125] An interesting application is to provide a device, for example, with network configuration data. Consider, for example, a device configured to perform network communications. Consider, for example, a device configured to configure the device for network communications. For example, in one embodiment, the device configured to perform network communications may be device 20 and the configuration device may be device 10, although the reverse may also be true. The configuration device may be a smartphone, a laptop, a computer, etc.

[0126] For example, for the registration phase 31, the device 20 may receive a pre-shared secret. The pre-shared secret may be transmitted out-of-bound to the device 10. For example, the pre-shared secret may be provided external to the device and entered by a user or may be scanned (e.g., in the form of scanning a QR code, barcode, etc.). If the pre-shared secret is available at the device 10, e.g., via a suitable interface (e.g., a user interface or a scanning interface). For example, the pre-shared secret may be shared using NFC or Bluetooth. For example, the exchange may be initiated by pressing a button on the device 10 and / or device 20. For example, the pre-shared secret may be randomly generated on the device 10 and / or device 20.

[0127] In a key agreement phase 32, device 10 and device 20 use a pre-shared secret to agree on a transmission key K. For example, the key agreement phase may use another communication channel, such as Wi-Fi.

[0128] During the use phase 33, the device 10 may transmit network configuration data secured (e.g., encrypted) using the transmission key to the device 20. For example, the transmission may use the same communication channel as the key agreement phase 32, such as Wi-Fi. After receiving the network configuration data, the device 20 may use the network configuration data to send and receive data over a computer network. The network configuration data may include network keys, certificates, network addresses, etc. Encryption of a message (e.g., network configuration data) using the transmission key includes direct encryption with the transmission key and indirect encryption where another key used to directly encrypt the message is derived from the transmission key. For example, the device 20 may be a router. Protocols such as those described above may be used to configure lighting elements, such as luminaires.

[0129] Interestingly, embodiments may provide a more secure transmission key than, for example, directly using a pre-shared secret to secure communications: even if the pre-shared secret has low entropy, the transmission key provided by embodiments may have high entropy.

[0130] For example, a pair of Bluetooth® devices may be bonded to establish a secure, authenticated communications link that is secure in terms of the confidentiality strength provided by the key agreement protocol, and authenticated because both use the same pre-shared secret.

[0131] An embodiment may be used to address spoofing attacks. For example, in traditional protocols where common objects are fixed or shared as part of the protocol, an attacker may be able to replay a message from one side. It may take a long time for the second party to realize that something is wrong. However, when the second party receives the message, the second party may want to verify that the message received is indeed from a particular source. In an embodiment, this may be achieved by including a variable element in the message. For example, for encryption or authentication with a transmission key, the second party may send a challenge, e.g., a nonce, in a message, e.g., in message 21.1 or 21.2, to the other party.

[0132] 4 illustrates a schematic diagram of an example cryptographic system 301 according to one embodiment. The system 301 includes a first cryptographic device 300 and a second cryptographic device 350. For example, the first device 300 and the second device 350 may be on a device such as the first device 300 and / or the second device 350. For example, the device 300 may be configured as device 10 and the device 350 may be configured as device 20.

[0133] The first and second devices 300 and 350 are configured to execute a cryptographic protocol, and both devices have the capability to pass data from one device to the other.

[0134] For example, the first and second devices may be configured for a key agreement protocol, e.g., designed to generate a key, typically a symmetric key, that is shared between both devices. The shared key may then be used by the devices for secured communications, e.g., encrypted and / or authenticated communications, e.g., to encrypt a message and / or to compute an authentication tag for the message.

[0135] In one embodiment, device 300 and device 350 may each store a pre-shared secret p. For example, device 300 and device 350 may include a pre-shared secret unit (not separately shown) for obtaining and / or storing the pre-shared secret.

[0136] The first device 300 and the second device 350 may have one or more of a storage interface, a processor, and a memory. The first device 300 and the second device 350 (e.g., various devices of the system 301) may communicate with each other via a computer network 391. The computer network may be the Internet, an intranet, a LAN, a WLAN, etc. The computer network 391 may be the Internet. The computer network may be wholly or partially wired and / or wholly or partially wireless. For example, the computer network may include an Ethernet connection. For example, the computer network may include a wireless connection such as Wi-Fi or ZigBee. The device comprises a connection interface configured to communicate with other devices of the system 301 as needed. For example, the connection interface may include a connector, such as a wired connector (e.g., an Ethernet connector) or a wireless connector (e.g., an antenna (e.g., a Wi-Fi, 4G or 5G antenna)). For example, the first device 300 and the second device 350 may each include a communication interface 305, 355. The computer network 391 may include additional elements, such as routers and hubs.

[0137] The execution of the first device 300 and the second device 350 is implemented in a processor, e.g., a processor circuit, examples of which are given herein. The first device 300, in particular the processor of the first device 300, may implement the functions of the first party 10. The second device 350, in particular the processor of the second device 350, may implement the functions of the second party 20. For example, these functions may be fully or partially implemented as computer instructions stored on the device 300 or 350 (e.g., stored in an electronic memory of the device). The computer instructions are executable by a microprocessor of the device. In a hybrid embodiment, the functional units are implemented partly in hardware, e.g., as a coprocessor, e.g., a cryptographic coprocessor, and partly in software stored and executed on the device 300 or 350.

[0138] Devices 300 and 350 may include a storage interface for storing and / or retrieving messages (possibly encrypted messages). For example, the storage interface may be implemented locally, e.g., in the memory of each device, e.g., as an interface to memory included in the device. The storage interface may also be an interface to offline, e.g., non-local, storage, e.g., cloud storage, e.g., a memory or drive provided in another device. If cloud storage is used, the device may further include local storage (e.g., memory). For example, the memory may be used to store computer programming instructions, temporary files, and the like.

[0139] A communication interface may be selected from a variety of options in various embodiments of devices 300 and 350. For example, the interface may be a network interface to a local or wide area network, such as the Internet, or it may be a storage interface to internal or external data storage, or an application interface (API), etc.

[0140] Devices 300 and 350 may have a user interface that may include well-known elements such as one or more buttons, a keyboard, a display, a touch screen, etc. The user interface may be configured to respond to user interactions to initiate a key agreement protocol, respond to the key agreement protocol, send encrypted messages, etc.

[0141] The storage may be implemented as, for example, electronic memory, such as flash memory, or magnetic memory, such as a hard disk. The storage may comprise multiple individual memories that make up the storage. The storage may be temporary memory, such as RAM.

[0142] Typically, devices 300 and 350 each comprise a microprocessor that executes appropriate software stored in device 300 and 350. For example, the software may be downloaded and / or stored in a corresponding memory, e.g. a volatile memory such as RAM, or a non-volatile memory such as Flash. Alternatively, devices 300 and 350 may be implemented in whole or in part in programmable logic, e.g. as a Field Programmable Gate Array (FPGA). Devices 300 and 350 may be implemented in whole or in part as so-called Application Specific Integrated Circuits (ASICs), e.g. integrated circuits (ICs) customized for a specific application. For example, the circuits may be implemented in CMOS, e.g. using hardware description languages ​​such as Verilog, VHDL, etc.

[0143] In one embodiment, devices 300 and 350 may include one or more circuits for implementing one or more or all of the functions of the respective devices. These circuits may implement corresponding functions described herein. The circuits may be processor circuits and memory circuits, where the processor circuit executes instructions that are electronically represented in the memory circuit.

[0144] The processor circuitry may be implemented in a distributed manner, for example as multiple sub-processor circuits. The storage may be distributed across multiple distributed sub-storages. Some or all of the memory may be electronic memory, magnetic memory, etc. For example, the storage may have volatile and non-volatile portions. Some of the storage may be read-only. The circuitry may also be an FPGA, an ASIC, etc.

[0145] The first device 300 may comprise a public / private key generator 315 configured to generate a first private key (r) and a first public key (b) derived from the first private key. A common object (a) may be used to derive the public key from the private key. For example, generating the public key may include multiplying with a common object and / or introducing some noise (e.g., scaling down the multiplication result, adding a noise term, etc.). The private key and the common object may be polynomials or matrices (e.g., over a finite field or ring).

[0146] The first device 300 and the second device 350 are configured to agree on a common object a. For example, the first device 300 and the second device 350 may be configured to exchange data (e.g., one or more pre-seeds σ) that may be used in the calculation of the final seed, sent to / from the first device 300 and the second device 350. For example, the first device 300 and the second device 350 may be configured to maintain public data, such as counters or network data, that may also be used in the calculation of the final seed. For example, the first device 300 and the second device 350 may be configured to store secret data, such as a pre-shared secret p. For example, the first device 300 and the second device 350 may be configured to obtain common data, for example, from random number beacons. For one or more of these sources, each device calculates a common final seed τ. For an attacker to arrive at the same final seed τ, the attacker needs to have access to or track the same source. Device 300 and device 350 are configured to derive a common object a from a common final seed, where the common object used for key agreement is unknown to an attacker.

[0147] The first private and public keys may be generated temporarily, for example for a key agreement protocol, especially if the first and second devices authenticate each other using another authentication mechanism (e.g., an out-of-band mechanism, such as certificate-based authentication).

[0148] The first public key is transmitted from the first device 300 to the second device 350, for example via the communication interfaces 305 and 355. This may be done by direct communication. Optionally, a pre-seed σ may be transmitted together with the first public key. For example, by sending the pre-seed σ, a final seed may be calculated that may be used to generate the common object (a).

[0149] The second device 350 may comprise a public key obtainer 360. The public key may be obtained directly from the first device (possibly out-of-bound, e.g., by email). The public key may be stored until needed. However, the first public key may also be received for immediate use, e.g., for a key-sharing operation, e.g., in which case the first public key and / or the common object may be generated temporarily.

[0150] The second device 350 may include a public / private key generator 365 configured to generate a second private key(s) and to generate a second public key (u) from the second private key(s). The second public key uses the same common object as the generation of the first public key. The first and second private keys are secrets known only to the respective devices. If desired, they may be shared between trusted parties, e.g., for backup, key escrow, etc. The public keys and the common object do not necessarily have to be secret for security. However, if desired, one or more may be secrets known only to the first and second devices. For example, the first public key may only be shared with the second device, and vice versa.

[0151] Independent generation may be obtained if (for example in the case of a message) the message is generated from an application independent of public key cryptography (such as a financial or communication application). Independent generation may be obtained, for example, by random generation.

[0152] The second device 350 may comprise a raw key generator 375. The raw key generator 375 is configured to generate a second raw shared key (k*) from the first public key (b) and the second private key (s). For example, the raw key generator 375 may be configured to apply a noisy multiplication to the first public key and the second private key. For example, the noisy multiplication may be a multiplication or an exponentiation depending on the underlying mechanism. The second device 350 is configured to transmit its second public key to the first device 300.

[0153] The first device 300 may comprise a raw key generator 325. The raw key generator 325 is configured to generate a first raw shared key (k') from a second public key (u) and a first private key (r), for example by applying noisy multiplication. Unfortunately, in noisy multiplication, the first and second raw keys are not necessarily identical, but may be close to each other. The specific likelihood of this occurring depends on the underlying noisy multiplication. In most applications, it may be acceptable to some extent that the raw keys are different from each other, but how likely it is to be tolerated depends on the application. However, it is usually preferable that this likelihood is low. The raw keys may be of the same mathematical type as the private and public keys, for example polynomials or matrices.

[0154] The adjustment data generator 385 is configured to generate adjustment data (h) for the indicated coefficients of the raw shared key. The adjustment data includes information that allows for reducing the difference between the first and second raw keys derived at the first and second devices. For example, applying the adjustment data reduces the difference (e.g., Lee distance) between the coefficients of the raw keys of the first and second devices, resulting in a higher likelihood that they will generate the same bits. The adjustment data may be calculated on the coefficients in the raw shared key.

[0155] One way to implement the adjustment data is to add one or more bits, e.g., b, following the bits selected as the key bits. h The aim is to obtain the bits of coefficients B, B bits in significance, i.e. h bits. For example, the number of adjustment bits per selected coefficient may be, for example, 1 or 2. A small number of adjustment bits has the advantage of reducing communication overhead, although larger amounts of adjustment bits are also possible.

[0156] The second device 350 may include an encapsulator 390. The encapsulator 390 is configured to encapsulate the key K with the key bits by applying an encapsulation function, for example, XOR. The encapsulation may be a one-time pad encapsulation. For example, an XOR function or one of the other encapsulation functions described herein may be used.

[0157] The second device is configured to transmit the second public key (u), the coordination data (h), and / or the encapsulated data (c), which may occur in response to receiving the first public key (e.g., in the case of key agreement) or not (e.g., in the case of public key encryption).

[0158] The first device 300 is configured to receive the second public key (u), the adjustment data (h), and the encapsulated data (c) from the second device. The first device 300 may include an adjustment unit 335 configured to obtain key bits (k) by applying the adjustment data (h) in an adjustment function to the coefficients of the first raw shared key (k'). For example, the coefficients may be adjusted using the adjustment bits and then sampled to obtain high-reliability bits. The first device 300 includes a decapsulation unit 340 configured to decapsulate the encapsulated data (c) to obtain the key K. In one embodiment, the device 300 and the device 350 include only one of the adjustment unit and the encapsulation / decapsulation unit. In one embodiment, the device 300 and the device 350 include other methods to reduce the distance between the respective raw keys.

[0159] 5a shows a schematic diagram of an example cryptographic method 400 according to one embodiment. For example, the method 400 may be used together with the method 450. For example, the method 400 and the method 450 may be extended or modified according to the embodiments described herein. The second cryptographic method (400) includes: communicating (405) with a first cryptographic device (10); a pre-seed received from the first cryptographic device (10); and Calculating (410) a final seed from a pre-shared secret pre-shared between the second cryptographic device and the first cryptographic device; Computing (415) a common object (a) from the final seeds; obtaining (420) a first public key (b) associated with the first cryptographic device and obtaining a second private key (s) associated with the second cryptographic device; A step (425) of calculating a second public key (u) from the second private key (s), the calculation of the second public key (u) comprising multiplying the second private key (s) by a common object (a); A step (430) of calculating a second raw shared key (k*) from the first public key (b) and the second private key (s), the calculation of the second raw shared key comprising a multiplication between the second private key (s) and the first public key (b); and transmitting (435) the second public key (u) to the first device.

[0160] FIG. 5b shows a schematic diagram of an example cryptographic method 450 according to an embodiment. The first cryptographic method (450) comprises: communicating (455) with a second cryptographic device (20); selecting a pre-seed and sending (460) the pre-seed to a second cryptographic device (20); calculating (465) a final seed from the pre-seed and a pre-shared secret pre-shared between the second cryptographic device and the first cryptographic device; Computing (470) a common object (a) from the final seeds; obtaining a first private key (r) associated with the first cryptographic device, calculating a first public key (b) from the first private key (r) by a calculation including multiplying the first private key (r) with the common object (a), and transmitting (475) the first public key (b) to the second cryptographic device; receiving (480) a second public key (u) from a second cryptographic device; and calculating a first raw shared key (k') from the second public key (u) and the first private key (r), where the calculation of the first raw shared key includes multiplication between the second public key (u) and the first private key (r) (485).

[0161] For example, methods 400 and 450 may be computer-implemented methods. For example, the computational portions of the methods may be computed using a computer, computing circuitry, etc. For example, communication with a cryptographic device may be performed using a communications interface. For example, storage or retrieval of parameters, keys, etc. may be performed from electronic storage, e.g., memory, hard drive, etc. Keys and / or common objects may be represented by data larger than 10 bytes, 50 bytes, 100 bytes, etc.

[0162] As will be apparent to one skilled in the art, there are many different ways of performing the method. For example, the steps may be performed in the order described or illustrated, but it is also possible to change the order of the steps or perform some steps in parallel. Furthermore, other method steps can be inserted between the steps. The inserted steps may represent improvements to the method as described herein or may be unrelated to the method. Furthermore, a step may not be completely completed before the next step is started.

[0163] The method embodiments may be implemented using software including instructions for causing a processor system to perform the method 400 and / or 450. The software may include only steps taken by a particular sub-entity of the system. The software may be stored on a suitable storage medium such as a hard disk, floppy, memory, optical disk, etc. The software may be sent as a signal via wire or wirelessly or using a data network such as the Internet. The software may be downloadable and / or remotely available on a server. The method embodiments may be implemented using a bitstream configured to configure a programmable logic, for example a field programmable gate array (FPGA), to perform the method.

[0164] It will be understood that the subject matter of the present disclosure also extends to computer programs, in particular computer programs on or in a carrier adapted to carry out the subject matter of the present disclosure. The programs may take the form of source code, object code, code intermediate source, object code such as partially compiled form, or any other form suitable for use for implementing the method embodiments. An embodiment relating to a computer program product includes computer executable instructions corresponding to the processing steps of at least one of the above methods. These instructions may be stored in one or more files that may be subdivided into subroutines and / or statically or dynamically linked. Other embodiments relating to a computer program product include computer executable instructions corresponding to devices, units, and / or parts of at least one of the above systems and / or products.

[0165] FIG. 6a shows a computer readable medium 1000 having a writable portion 1010 including a computer program 1020, according to one embodiment, the computer program 1020 including instructions for causing a processor system to execute a cryptographic method. The computer program 1020 may be embodied on the computer readable medium 1000 as a physical mark or by magnetization of the computer readable medium 1000. However, any other suitable embodiment is also contemplated. Furthermore, although the computer readable medium 1000 is shown here as an optical disk, the computer readable medium 1000 may be any suitable computer readable medium such as a hard disk, a solid state memory, a flash memory, etc., and may be non-recordable or recordable. The computer program 1020 includes instructions for causing a processor system to execute said cryptographic method.

[0166] Fig. 6b is a schematic diagram of a processor system 1140 according to an embodiment of a cryptographic device. The processor system comprises one or more integrated circuits 1110. The architecture of the one or more integrated circuits 1110 is shown in Fig. 6b. The circuit 1110 comprises a processing unit 1120 (e.g., a CPU, etc.) for executing computer program components for performing a method according to an embodiment and / or for implementing a module or unit. The circuit 1110 includes a memory 1122 for storing programming code, data, etc. Part of the memory 1122 may be read-only. The circuit 1110 may comprise a communication element 1126, e.g., an antenna or a connector, or both. The circuit 1110 may comprise a dedicated integrated circuit 1124 for performing some or all of the processing defined in the method. The processor 1120, the memory 1122, the dedicated IC 1124, and the communication element 1126 may be interconnected via an interconnect 1130, e.g., a bus. The processor system 1110 may be configured for contact and / or contactless communication using an antenna and / or a connector.

[0167] For example, in one embodiment, the processor system 1140 (e.g., a cryptographic device) comprises a processor circuit and a memory circuit, where the processor is configured to execute software stored in the memory circuit. For example, the processor circuit may be an Intel Core i7 processor, an ARM Cortex-R8, or the like. In one embodiment, the processor circuit may be an ARM Cortex M0. The memory circuit may be a ROM circuit, or a non-volatile memory, such as a flash memory. The memory circuit may be a volatile memory, such as an SRAM memory. In the latter case, the device may comprise a non-volatile software interface (e.g., a hard drive), a network interface, or the like, configured to provide the software.

[0168] Although device 1140 is shown as including one of each of the described components, various components may be duplicated in various embodiments. For example, processing unit 1120 (e.g., processor 1120) may include multiple microprocessors configured to independently perform the methods described herein, or multiple microprocessors configured to cooperatively perform steps or subroutines of the methods described herein to achieve the functionality described herein. Furthermore, when device 1140 is implemented in a cloud computing system, various hardware components may belong to separate physical systems. For example, processor 1120 may include a first processor in a first server and a second processor in a second server.

[0169] It should be noted that the above embodiments are illustrative rather than limiting of the subject matter of the present disclosure, and that those skilled in the art can design many alternative embodiments.

[0170] In the claims, reference signs between parentheses shall not be construed as limiting the claims. Use of the verb "comprise" and its conjugations does not exclude the presence of elements or steps other than those stated in the claims. The singular form of an element does not exclude the presence of a plurality of such elements. Expressions such as "at least one of" following a list of elements represent the selection of all elements or any subset of the listed elements. For example, the expression "at least one of A, B, and C" should be understood to include A only, B only, C only, both A and B, both A and C, both B and C, or all A, B, and C. The subject matter of the present disclosure may be implemented by hardware comprising several distinct elements, and by a suitably programmed computer. In a device claim enumerating several parts, several of these parts may be embodied by one and the same item of hardware. The mere fact that several means are recited in mutually different dependent claims does not indicate that a combination of these means cannot be advantageously used.

[0171] Each numbered section below includes possible non-limiting examples.

[0172] Section 1 A second cryptographic device (20), the second cryptographic device comprising: a communication interface configured to communicate with a first encryption device (10); a processor, the processor comprising: a pre-seed received from the first cryptographic device (10); and Calculating a final seed from a pre-shared secret pre-shared between the second cryptographic device and the first cryptographic device; Calculate the common object (a) from the final seed, obtaining a first public key (b) associated with a first cryptographic device; obtaining a second private key (s) associated with a second cryptographic device; calculating a second public key (u) from the second private key (s), where calculating the second public key (u) comprises multiplying the second private key (s) by the common object (a); calculating a second raw shared key from the first public key and the second private key, where the calculation of the second raw shared key comprises a multiplication between the second private key and the first public key; A second cryptographic device that transmits the second public key (u) to the first device.

[0173] Section 2 A first cryptographic device (10), the first cryptographic device comprising: a communications interface for communicating with a second cryptographic device (20); a processor, the processor comprising: selecting a pre-seed and sending said pre-seed to said second cryptographic device (20); calculating a final seed from the pre-seed and a pre-shared secret pre-shared between the second cryptographic device and the first cryptographic device; Calculate the common object (a) from the final seed, obtaining a first private key (r) associated with the first cryptographic device, calculating a first public key (b) from the first private key (r) by a calculation including multiplying the first private key (r) with the common object (a), and transmitting the first public key (b) to the second cryptographic device; receiving a second public key (u) from the second cryptographic device; A first cryptographic device that calculates a first raw shared key (k') from the second public key (u) and the first private key (r), where the calculation of the first raw shared key includes multiplication between the second public key (u) and the first private key (r).

[0174] Section 3 3. The second cryptographic device (20) or the first cryptographic device (10) of claim 1 or 2, wherein the pre-shared secret comprises a pre-shared password.

[0175] Section 4 The second cryptographic device (20) or the first cryptographic device (10) according to any one of claims 1 to 3, wherein the pre-seed is transmitted and received in plaintext form.

[0176] Section 5 The second cryptographic device (20) or the first cryptographic device (10) described in any one of clauses 1 to 4, wherein the pre-seed is transmitted and received via the communication interface, but the pre-shared secret is not transmitted and received via the communication interface.

[0177] Section 6 The second cryptographic device (20) or the first cryptographic device (10) of any one of claims 1 to 5, wherein the final seed is further calculated from network configuration data from a network connection between the second cryptographic device and the first cryptographic device.

[0178] Section 7 The final seed is a network address of said first and / or second cryptographic device; The purpose of the network connection; time, The second cryptographic device (20) or the first cryptographic device (10) described in any one of clauses 1 to 6, wherein the interaction counter is calculated from an interaction counter maintained by the second cryptographic device (20) and the first cryptographic device (10) and is incremented at least each time a shared key is derived.

[0179] Section 8 The processor of the second cryptographic device (20): Generate a transmission key (K), encapsulating the transmission key with at least a portion of the second raw shared key by applying an encapsulation function to obtain encapsulated data (c); sending the encapsulated data (c) to the first cryptographic device; The processor of the first cryptographic device (10) receiving the encapsulated data (c) from the second device; The second cryptographic device (20) or the first cryptographic device (10) according to any one of clauses 1 to 7, wherein the second cryptographic device (20) or the first cryptographic device (10) obtains a transmission key by decapsulating the encapsulated data (c) using at least a portion of the first raw shared key (k').

[0180] Section 9 The processor of the second cryptographic device (20): generating adjustment data (h) for at least a portion of the coefficients of the raw shared key, wherein the adjustment data comprises information that enables reducing a difference between the first and second raw keys derived at the first and second devices; generating a transmission key (K) from the second raw shared key (k*); sending said adjustment data (h) to said first cryptographic device; The processor of the first cryptographic device (10) receiving adjustment data (h) from the second device; applying said adjustment data (h) in a adjustment function to at least some of the coefficients in said first raw shared key (k'); The second cryptographic device (20) or the first cryptographic device (10) according to any one of clauses 1 to 8, which generates a transmission key (K) from the adjusted first raw shared key (k').

[0181] Section 10 The second cryptographic device (20) or the first cryptographic device (10) according to any one of claims 1 to 9, wherein the multiplication with the common object (a) when calculating the first public key (b) and the second public key (u) is a noisy multiplication.

[0182] Section 11 the processor of the second cryptographic device encrypts a message (m) using the transmission key and sends the encrypted message to the first cryptographic device, and the processor of the first cryptographic device decrypts the encrypted message using the transmission key to verify the message (m); and / or The second cryptographic device or the first cryptographic device described in any one of clauses 1 to 10, wherein the processor of the first cryptographic device encrypts a message (m) using the transmission key and sends the encrypted message to the second cryptographic device, and the processor of the second cryptographic device decrypts the encrypted message using the transmission key to verify the message (m).

[0183] Section 12 The second cryptographic device or the first cryptographic device according to any one of clauses 1 to 11, wherein the transmission key is random and / or temporary and / or symmetric and / or independent of the first public key (b).

[0184] Section 13 the first and second public keys, the first and second private keys, the first and second raw keys, and the common object are matrices over a finite field or ring; 13. The second cryptographic device or the first cryptographic device according to any one of clauses 1 to 12, wherein the first and second public keys, the first and second private keys, the first and second raw keys, and the common object are polynomials over a finite field or ring.

[0185] Section 14 14. The second cryptographic device or the first cryptographic device according to any one of claims 1 to 13, wherein network configuration data is encrypted and sent using the transmission key.

[0186] Section 15 A second cryptographic method (400), comprising: communicating (405) with a first cryptographic device (10); a pre-seed received from the first cryptographic device (10); and Calculating (410) a final seed from a pre-shared secret pre-shared between the second cryptographic device and the first cryptographic device; Computing (415) a common object (a) from the final seeds; obtaining (420) a first public key (b) associated with the first cryptographic device and obtaining a second private key (s) associated with the second cryptographic device; A step (425) of calculating a second public key (u) from the second private key (s), the calculation of the second public key (u) comprising multiplying the second private key (s) by a common object (a); a step (430) of calculating a second raw shared key (k*) from the first public key (b) and the second private key (s), where calculating the second raw shared key comprises a multiplication between the second private key (s) and the first public key (b); and transmitting (435) the second public key (u) to the first device.

[0187] Section 16 A first cryptographic method (450), the first cryptographic method comprising: communicating (455) with a second cryptographic device (20); selecting a pre-seed and sending (460) the pre-seed to a second cryptographic device (20); calculating (465) a final seed from the pre-seed and a pre-shared secret pre-shared between the second cryptographic device and the first cryptographic device; Computing (470) a common object (a) from the final seeds; obtaining a first private key (r) associated with the first cryptographic device, calculating a first public key (b) from the first private key (r) by a calculation including multiplying the first private key (r) with the common object (a), and transmitting (475) the first public key (b) to the second cryptographic device; receiving (480) a second public key (u) from the second cryptographic device; and calculating (485) a first raw shared key (k') from a second public key (u) and a first private key (r), where the calculation of the first raw shared key includes multiplication between the second public key (u) and the first private key (r).

[0188] Section 17 A transitory or non-transitory computer-readable medium (1000) comprising data (1020) representing instructions that, when executed by a processor system, cause the processor system to perform the method of clause 15 and / or clause 16.

[0189] In the claims, reference signs in parentheses refer to the reference signs in the drawings of the exemplary embodiments or to the mathematical formulas of the embodiments, thus enhancing the clarity of the claims, and these reference signs should not be construed as limiting the claims.

Claims

1. A second cryptographic device for performing a lattice-based key exchange or lattice-based key encapsulation key agreement protocol with a first cryptographic device, the second cryptographic device comprising: a communications interface for communicating with the first cryptographic device using the lattice-based key exchange or the lattice-based key encapsulation key agreement protocol; a processor, the processor comprising: calculating a final seed from a pre-seed received from the first cryptographic device, a pre-shared secret pre-shared between the second cryptographic device and the first cryptographic device, and further information; Computing a common object from said final seed using a deterministic random number generator or a pseudorandom number generator; obtaining a first public key associated with the first cryptographic device and obtaining a second private key associated with the second cryptographic device, where the first cryptographic device calculates the common object from the final seed using a deterministic random number generator or a pseudorandom number generator, the first public key being calculated at the first cryptographic device, the calculation comprising a multiplication between the common object calculated by a processor of the first cryptographic device and a first private key of the first cryptographic device; calculating a second public key from the second private key, where calculating the second public key comprises multiplying the second private key by the common object calculated by a processor of the second cryptographic device; calculating a second raw shared key from the first public key and the second private key, where the calculation of the second raw shared key comprises a multiplication between the second private key and the first public key; transmitting the second public key to the first cryptographic device; The further information comprises: a network address of the first cryptographic device; a network address of the second cryptographic device; The purpose of the network connection; Time, and A second cryptographic device including at least one interaction counter maintained by the first cryptographic device and the second cryptographic device and incremented at least each time a shared key is derived.

2. A second cryptographic device as described in claim 1, wherein the pre-shared secret includes a pre-shared password.

3. A second cryptographic device as described in claim 1 or 2, wherein the pre-seed is transmitted and received in plaintext format.

4. A second cryptographic device described in any one of claims 1 to 3, wherein the pre-seed is transmitted and received via the communication interface, but the pre-shared secret is not transmitted and received via the communication interface.

5. A second cryptographic device as described in any one of claims 1 to 4, wherein the final seed is further calculated from network configuration data from a network connection between the second cryptographic device and the first cryptographic device.

6. The processor of the second cryptographic device, Generate a transmission key, encapsulating the transmission key with at least a portion of the second raw shared key by applying an encapsulation function to obtain encapsulated data; The second cryptographic device of claim 1 , configured to transmit the encapsulated data to the first cryptographic device.

7. The processor of the second cryptographic device, generating adjustment data for at least a portion of the coefficients of the raw shared keys, wherein the adjustment data comprises information enabling a reduction in a difference between the first and second raw shared keys derived at the first and second cryptographic devices; generating a transmission key from the second raw shared key; The second cryptographic device of claim 1 , configured to send the adjustment data to the first cryptographic device.

8. A second cryptographic device described in any one of claims 1 to 7, wherein the multiplication with the common object when calculating the second public key is a noisy multiplication. and / or the processor of the second cryptographic device encrypts a message using the transmission key and sends the encrypted message to the first cryptographic device. The second cryptographic device of claim 6 or 7, wherein the processor of the second cryptographic device decrypts the encrypted message using the transmission key to verify the message.

10. A second cryptographic device as described in claim 6 or 7, wherein the transmission key is random and / or temporary and / or symmetric and / or independent of the first public key.

11. The second public key, the second private key, the second raw shared key, and the common object are matrices over a finite field or ring, or 11. The second cryptographic device of claim 1, wherein the second public key, the second private key, the second raw shared key, and the common object are polynomials over a finite field or ring.

12. A second cryptographic device as described in claim 6 or 7, wherein network configuration data is encrypted using the transmission key and sent.

13. 1. A first cryptographic device for performing a lattice-based key exchange or lattice-based key encapsulation key agreement protocol with a second cryptographic device, the first cryptographic device comprising: a communications interface for communicating with the second cryptographic device using the lattice-based key exchange or the lattice-based key encapsulation key agreement protocol; and a processor, the processor comprising: selecting a pre-seed and sending the pre-seed to the second cryptographic device; calculating a final seed from the pre-seed, a pre-shared secret pre-shared between the second cryptographic device and the first cryptographic device, and further information; Computing a common object from said final seed using a deterministic random number generator or a pseudorandom number generator; obtaining a first private key associated with the first cryptographic device; calculating a first public key from the first private key by a calculation that includes multiplying the first private key by the common object; and transmitting the first public key to the second cryptographic device; receiving a second public key from the second cryptographic device; calculating a first raw shared key from the second public key and the first private key, where the calculation of the first raw shared key comprises a multiplication between the second public key and the first private key; The further information comprises: a network address of the first cryptographic device; a network address of the second cryptographic device; The purpose of the network connection; Time, and A first cryptographic device including at least one interaction counter maintained by the first cryptographic device and the second cryptographic device and incremented each time at least a shared key is derived.

14. The first cryptographic device of claim 13 , wherein the pre-shared secret comprises a pre-shared password.

15. The first cryptographic device of claim 13 or 14, wherein the pre-seed is transmitted and received in plaintext form.

16. 16. The first cryptographic device of claim 13, wherein the pre-seed is transmitted and received over the communication interface, but the pre-shared secret is not transmitted and received over the communication interface.

17. 17. The first cryptographic device of claim 13, wherein the final seed is further calculated from network configuration data from a network connection between the second cryptographic device and the first cryptographic device.

18. The processor of the first cryptographic device: receiving encapsulated data from the second cryptographic device; 18. The first cryptographic device of claim 13, further comprising: a first cryptographic device configured to obtain a transmission key by decapsulating the encapsulated data using at least a portion of the first raw shared key.

19. The processor of the first cryptographic device, receiving calibration data from the second cryptographic device; applying the adjustment data in a adjustment function to at least a portion of the coefficients in the first raw shared key; 19. A first cryptographic device according to any one of claims 13 to 18, configured to generate a transmission key from a first raw shared key to which the adjustment data has been applied.

20. 20. The first cryptographic device of claim 13, wherein the multiplication with the common object when calculating the first public key is a noisy multiplication.

21. the processor of the first cryptographic device receives an encrypted message from the second cryptographic device and decrypts the encrypted message using the transmission key to verify the message; and / or 20. The first cryptographic device of claim 18 or 19, wherein the processor of the first cryptographic device encrypts a message using the transmission key and sends the encrypted message to the second cryptographic device.

22. 20. The first cryptographic device of claim 18 or 19, wherein the transmission key is random and / or ephemeral and / or symmetric and / or independent from the first public key.

23. the first public key, the first private key, the first raw shared key, and the common object are matrices over a finite field or ring; or 23. The first cryptographic device of claim 13, wherein the first public key, the first private key, the first raw shared key, and the common object are polynomials over a finite field or ring.

24. 20. The first cryptographic device of claim 18 or 19, wherein network configuration data is sent encrypted using the transmission key.

25. 1. A cryptographic method for performing a lattice-based key exchange or lattice-based key encapsulation key agreement protocol with a first cryptographic device, the cryptographic method comprising: calculating a final seed from a pre-seed received from the first cryptographic device, a pre-shared secret pre-shared between a second cryptographic device and the first cryptographic device, and further information; Computing a common object from said final seed using a deterministic random number generator or a pseudorandom number generator; obtaining a first public key associated with the first cryptographic device and a second private key associated with the second cryptographic device, the first cryptographic device calculating the common object from the final seed using a deterministic or pseudo-random number generator, the first public key being calculated at the first cryptographic device, the calculation comprising a multiplication between the common object calculated by a processor of the first cryptographic device and a first private key of the first cryptographic device; calculating a second public key from the second private key, where calculating the second public key comprises multiplying the second private key by the common object calculated by a processor of the second cryptographic device; calculating a second raw shared key from the first public key and the second private key, where calculating the second raw shared key comprises a multiplication between the second private key and the first public key; transmitting the second public key to the first cryptographic device; The further information comprises: a network address of the first cryptographic device; a network address of the second cryptographic device; The purpose of the network connection; Time, and The cryptographic method includes at least one interaction counter maintained by the first cryptographic device and the second cryptographic device and incremented each time at least a shared key is derived.

26. 1. A cryptographic method for performing a lattice-based key exchange or lattice-based key encapsulation key agreement protocol with a second cryptographic device, the cryptographic method comprising: selecting a pre-seed and sending the pre-seed to the second cryptographic device; calculating a final seed from the pre-seed, a pre-shared secret pre-shared between the second cryptographic device and the first cryptographic device, and further information; Computing a common object from said final seed using a deterministic random number generator or a pseudorandom number generator; obtaining a first private key associated with the first cryptographic device, calculating a first public key from the first private key by a calculation that includes multiplying the first private key by the common object, and transmitting the first public key to the second cryptographic device; receiving a second public key from the second cryptographic device; calculating a first raw shared key from the second public key and the first private key, where calculating the first raw shared key comprises a multiplication between the second public key and the first private key; The further information comprises: a network address of the first cryptographic device; a network address of the second cryptographic device; The purpose of the network connection; Time, and The cryptographic method includes at least one interaction counter maintained by the first cryptographic device and the second cryptographic device and incremented each time at least a shared key is derived.

27. A non-transitory computer-readable medium comprising data representing instructions for causing a processor system to perform the cryptographic method of claim 25.

28. A non-transitory computer-readable medium comprising data representing instructions for causing a processor system to perform the cryptographic method of claim 26.

Images