CA3146196A1 - Method and system for key agreement utilizing plactic monoids - Google Patents

Abstract

A method for key agreement between a first party and a second party over a public communications channel, the method including selecting, by the first party, a first value "a"; multiplying the first value "a" by a second value "b" using Knuth multiplication to create a third value "d", the third value "d" being a sem istandard tableau; sending the third value "d" to the second party; receiving, from the second party, a fourth value "e", the fourth value being a second sem istandard tableau comprising the second value "b" multiplied by a fifth value "c" selected by the second party; and creating a shared secret by multiplying the first value "a"
with the fourth value "e" using Knuth multiplication, wherein the shared secret matches the third value "d" multiplied by the fifth value "c" using Knuth multiplication.

Description

METHOD AND SYSTEM FOR KEY AGREEMENT UTILIZING PLACTIC
MONOIDS
FIELD OF THE DISCLOSURE
[0001] The present disclosure relates to cryptography, and in particular relates to key agreement for cryptography.
BACKGROUND

[0002] In cryptography, key agreement schemes define a set of rules for how two parties may each choose a secret, and then compute a shared secret based on such choice. Key agreement schemes are sometimes referred to as key exchange or key establishment schemes.

[0003] The most famous form of key agreement is referred to as the Diffie-Hellman (DH) key agreement. Various forms of Diffie-Hellman key agreements exist, including elliptic curve forms, which are commonly used on many websites.

[0004] However, quantum computers are emerging as a potential computing platform. Quantum computers use "quantum bits" rather than binary digits utilized in traditional computers. Such quantum computers would theoretically be able to solve certain problems much more quickly than classical computers, including integer factorization, which is the strength behind the Diffie-Hellman key agreement scheme.

[0005] In particular, Peter Shor formulated Shor's quantum algorithm in 1994.
This algorithm is known to attack the Diffie-Hellman key agreement if a sufficiently powerful quantum computer can be built. Utilizing such algorithm, the risk of a quantum computer discovering the secret for one or both parties in a Diffie Hellman key agreement scheme is nonzero. Therefore, counter measures to Shor's algorithm are needed.

Date Recue/Date Received 2022-01-19 BRIEF DESCRIPTION OF THE DRAWINGS

[0006] The present disclosure will be better understood with reference to the drawings, in which:

[0007] Figure 1 is a dataflow diagram showing a key agreement scheme.

[0008] Figure 2 is dataflow diagram showing a key agreement scheme utilizing sem igroups.

[0009] Figure 3A is a block diagram showing a Young diagram in English notation.

[0010] Figure 3B is a block diagram showing a Young diagram in French notation.

[0011] Figure 4 is dataflow diagram showing a key agreement scheme utilizing plactic key agreement.

[0012] Figure 7 is a block diagram of a simplified computing device capable of being used with the embodiments of the present disclosure.
DETAILED DESCRIPTION OF THE DRAWINGS

[0013] The present disclosure provides a method for key agreement between a first party and a second party over a public communications channel, the method comprising: selecting, by the first party, a first value "a"; multiplying the first value "a" by a second value "b" using Knuth multiplication to create a third value "d", the third value "d" being a semistandard tableau; sending the third value "d" to the second party; receiving, from the second party, a fourth value "e", the fourth value being a second semistandard tableau comprising the second value "b" multiplied by a fifth value "c" selected by the second party; and creating a shared secret by multiplying the first value "a" with the fourth value "e" using Knuth multiplication, wherein the shared secret matches the third value "d" multiplied by the fifth value "c" using Knuth multiplication.

Date Recue/Date Received 2022-01-19

[0014] The present disclosure further provides a computing device configured for key agreement between a first party and a second party over a public communications channel, the computing device comprising: a processor; and a communications subsystem, wherein the computing device is configured to:
select a first value "a"; multiply the first value "a" by a second value "b" using Knuth multiplication to create a third value "d", the third value "d" being a semistandard tableau; send the third value "d" to the second party; receive, from the second party, a fourth value "e", the fourth value being a second semistandard tableau comprising the second value "b" multiplied by a fifth value "c" selected by the second party; and create a shared secret by multiplying the first value "a"
with the fourth value "e" using Knuth multiplication, wherein the shared secret matches the third value "d" multiplied by the fifth value "c" using Knuth multiplication.

[0015] The present disclosure further provides a computer readable medium for storing instruction code for key agreement between a first party and a second party over a public communications channel, the instruction code, when executed by a processor of a computing device cause the computing device to: select a first value "a"; multiply the first value "a" by a second value "b" using Knuth multiplication to create a third value "d", the third value "d" being a semistandard tableau;
send the third value "d" to the second party; receive, from the second party, a fourth value "e", the fourth value being a second semistandard tableau comprising the second value "b" multiplied by a fifth value "c" selected by the second party; and create a shared secret by multiplying the first value "a" with the fourth value "e"
using Knuth multiplication, wherein the shared secret matches the third value "d"
multiplied by the fifth value "c" using Knuth multiplication.

[0016] In accordance with the present disclosure, semigroups, which are a category of mathematical objects in algebra, may be used as a basis for key agreement schemes. In particular, in accordance with the embodiments of the present disclosure, one sem igroup, namely a plactic monoid, may be used as part of a key agreement scheme.

Date Recue/Date Received 2022-01-19

[0017] Plactic monoids, and their use in key agreement, are described below.

[0018] Key Agreement

[0019] In key agreement schemes, two parties wish to create a secure communication utilizing a secret key, where both parties have made a contribution to such secret key.

[0020] Reference is made to Figure 1, which shows a generalized key agreement scheme between two parties. In particular, in the embodiment of Figure 1, two parties, namely Alice and Charlie in the embodiment of the present disclosure, are the parties that are participating in the key agreement scheme.

[0021] In the embodiment of Figure 1, Alice generates a secret "a", as seen at block 110. Similarly, Charlie generates a secret "c", as seen at block 112.

[0022] Based on the generated secret "a" at block 110, Alice then computes a value "d" utilizing an algorithm P1 and the secret "a", as seen at block 120.

[0023] Similarly, Charlie computes a value "e" utilizing an algorithm P2 and the secret "c", as shown at block 122.

[0024] Alice then delivers the value "d" to Charlie, as shown by message 130.
Similarly, Charlie delivers the value "e" in message 132 to Alice. For both messages 130 and 132, delivery is considered to be reliable and authenticated using some mechanism.

[0025] Based on the receipt of value "e", Alice may then compute a value "f"
utilizing an algorithm P3, the generated secret "a" from block 110, and the received public value "e" from message 132, as seen at block 140.

Date Recue/Date Received 2022-01-19

[0026] Similarly, Charlie may compute a value "g" using an algorithm P4 with the secret generated at block 112, along with the value "d" received at message 130, as shown at block 142.

[0027] The computations used in the key agreement are such that f=g using algorithm P4, and therefore Alice and Charlie now share a secret, namely f=g.
Such shared secret has contributions by both parties.

[0028] Such shared secret may then be used, for example, as a symmetric key for both encryption and authentication of content and messages in future communications.

[0029] The embodiment of Figure 1 describes an asynchronous key agreement scheme, which provides a set of rules on how Alice and Charlie choose their secrets "a" and "c", and how they can compute the values d, e, f, g. Such schemes are sometimes called key exchange, to reflect the fact that public values d and e are exchanged. Similarly, they are sometimes called key distribution or key establishment. However, in accordance with the present disclosure, the term key agreement is typically used below to describe the fact that both parties contribute to the shared secret.

[0030] While the embodiment of Figure 1 above describes a key agreement scheme in which the keys of one party are not dependent on the other, in other cases, communications may need to be synchronized and ordered. For example, if the embodiment of Figure 1 was modified to make Charlie's public value "e"
depend on Alice's public value "d", then Charlie would not be able to send "e"
until "d" had been received. In this case, the model may not be considered to be asynchronous.

[0031] However, in the embodiments described below, all key agreement schemes are asynchronous. One example of such asynchronous scheme may be the Date Recue/Date Received 2022-01-19 Internet Engineering Task Force (IETF) protocol Transport Layer Security (TLS), which protects the HyperText Transport Protocol Secure (HTTPS) connections between clients and servers. The TLS protocol has two phases, namely a handshake and a record layer. The handshake is done first and uses public key cryptography in the form of a key agreement, and other aspects such as digital signatures for authentication.

[0032] For example, Diffie and Hellman first introduced a key agreement scheme.
Alice delivers d = ba mod p to Charlie. and Charlie delivers e = bc mod p to Alice.
Alice computes the agreed key as ea mod p. Charlie computes the agreed key as d c mod p. (Usually: p is a large prime, b is a fixed number, a and c are secret random numbers.) The agreed keys are equal because ea = (b9 = b(ca) = b(ac) =
(ba)c = dc, working modulo p throughout.

[0033] The agreed secret key can then be used to secure messages (by encrypting and authenticating).

[0034] Elliptic curve Diffie-Hellman key agreement is a variant of the original Diffie-Hellman key agreement, except that it replaces exponentiation modulo a large prime, by scalar multiplication over an elliptic curve.
Despite the extra complication, ECDH is faster and smaller than DH, because the best attacks against ECDH are slower than attacks against DH. The slower attacks on ECDH
allows keys in ECDH to be smaller and faster.

[0035] A quite different type of key agreement, Supersingular Isogeny-based Diffie-Hellman (SIDH), uses an even more complicated type of mathematics.
Isogenies are special maps between elliptic curves. No practical attacks on SIDH
have yet been published, even given quantum computers. A variant of SIDH key agreement (called SIKE) is under consideration as a Round 3 alternative in the NIST post-quantum cryptography project.

Date Recue/Date Received 2022-01-19

[0036] The TLS handshake has an elliptic curve Diffie-Hellman (ECDH) key agreement as an option, and TLS 1.3 requires some form of Diffie-Hellman key agreement, which may be either EDCH or classic DH.

[0037] The DH parts of a TLS handshake are asynchronous. For example, a server Alice and client Charlie use the handshake to agree on a master key. The master key is in used to derive session keys which are used in the TLS record layer to protect subsequent content data such as downloaded and uploaded webpages and similar web traffic.

[0038] Semigroups

[0039] Sem igroups are a category of mathematical objects in algebra. Each sem igroup S has a set of elements, and a binary operation defined on the set.
The binary operation must be associative. This means that:
a(bc) = (ab)c (1)

[0040] In equation 1 above, a, b and care in the sem igroup S. Equation 1 indicates that when computing the product abc of three elements a, b and c, it does not matter if one multiplies a and b first, getting some value d=ab, and then multiplying d by c to get abc=dc, or if one first multiplies b and c to get a value e=bc and then multiplying a and e to get abc=ae.

[0041] Any set equipped with an associative binary operation is a sem igroup.

[0042] When discussing a general semigroup S, it is often assumed that the operation is written as multiplication. Furthermore, when a and b are variables represented with values in S, the product is written as ab, omitting any multiplication sign. However, in particular specific sem igroups, such as positive integers under addition, a symbol "+" for a binary operation is used and the operation may be written as a+b instead of ab.

Date Recue/Date Received 2022-01-19

[0043] Associativity means that in the product abc, the order in which the two multiplications are carried out does not matter. Thus, either ab or bc could be computed first, but the final result is the same.

[0044] In accordance with the present disclosure, sem igroups have a multiplication operator.

[0045] Semigroups are however not required to have a division operator. In some cases, a division operator may be formed, and is written as "/". A division operator is a binary operator having left and right input. If / is a binary operator on sem igroup S, / may be defined as a strong divider if:
(ab)/b = a (2)

[0046] Where equation 2 above is valid for all a,b in S.

[0047] The operator / may be defined as a partial strong divider if equation 2 above only holds for a subset of a,b values within S.

[0048] In semigroup nomenclature, the operation is generally written as ab/b instead of (ab)/b, which means that multiplications are done before divisions.

[0049] Further, a weak divider may also be defined for a semigroup. In particular, sometimes a semigroup has multiplication in which ab=db for many different values of d. In this case, there cannot be a strong divider. A "I" is a weak divider if:
(ab/b)b = ab (3)

[0050] In equation 3, the weak divider is defined for all a, b and S.

Date Recue/Date Received 2022-01-19

[0051] A partial weak divider utilizes equation 3, but is only valid for a subset of values a, b within S.

[0052] In equations 2 and 3 above, the divider / is also called a right divider.
Similarly, a binary operation "V' is called a left divider. The operator \ is a strong left divider if b\ba=a. Further, the binary operator \ is a weak left divider if b(b\ba) = ba.

[0053] In various sem igroups, a divider operation may be known. For example, for positive integers under multiplication, it is the usual Euclidean division algorithm.
For positive integers under addition, the division may become subtraction.
Dividers are known for some matrix subgroups, where Bareiss elimination can be used.

[0054] Converting A Semigroup into a Key Agreement Scheme

[0055] Any semigroup may be converted into a key agreement scheme. Indeed, such construction allows for every key agreement scheme to be constructed in this way, including existing schemes such as DH key agreements and SIDH key agreements.

[0056] Based on the above, if a secure, post quantum resistant key agreement scheme is possible, it can be created utilizing the methods and systems in accordance with the present disclosure, along with some subgroup.

[0057] Reference is now made to Figure 2. In the embodiment of Figure 2, two parties wish to create a secret key through a key agreement scheme. In particular, as with Figure 1, Alice and Charlie communicate with each other.

[0058] In accordance with the embodiment of Figure 2, S is a semigroup. Alice, at block 210, chooses a secret code "a" within the semigroup S.

[0059] Similarly, at block 212, Charlie chooses a secret "c" found within the semigroup S.

Date Recue/Date Received 2022-01-19

[0060] Further, as seen at block 220 and 222, both Alice and Charlie choose a value "b" found within the semigroup S. The value b can be a public fixed value, or a prearranged secret value such as something derived from a password shared between Alice and Charlie. Other options for determining b are possible. Based on this, the value "b" can be a public value or can be a weak shared secret in some cases.

[0061] At block 230 Alice computes a value d=ab. Similarly, at block 232, Charlie computes a value "e" where e=bc.

[0062] Thereafter, as seen by message 240, Alice delivers the value "d" to Charlie.
Similarly, in message 242, Charlie delivers the value "e" to Alice.

[0063] At block 250, Alice computes f=ae. At block 252, Charlie computes g=dc.

[0064] Since S is a semigroup, multiplication is associative. Therefore, f =
ae =
a(bc) = (ab)c = dc = g.

[0065] Based on this, both Alice and Charlie compute the same value f=g.

[0066] In the embodiment of Figure 1, the variables a, c, d, e, f and g were used.
These variables are similarly used in Figure 2 to illustrate that the construction is a key agreement scheme.

[0067] Comparing the embodiments of Figure 1 and Figure 2, the embodiment of Figure 2 uses the semigroup S. Further, it uses an extra variable b, which is a shared or pre-shared element of S.
Date Recue/Date Received 2022-01-19

[0068] In the embodiment of Figure 2, the value that is shared over the public channel is computed through multiplication. In Figure 1, it was not specified how the values of d and e were computed from a and c respectively.

[0069] Further, the embodiment of Figure 2 uses semigroup multiplication to compute the shared secret f=g. The embodiment of Figure 1 did not specify how the shared secrets were computed.

[0070] Further, the associativity of the semigroup is used to ensure that f=g.

Conversely, in Figure 1, the algorithm used to compute f and g were not defined to allow that Alice and Charlie could ensure that they agree on the same shared secret.

[0071] Using the embodiment of Figure 2 above, any key agreement scheme can be created. However, the semigroup chosen determines the security of the key agreement scheme.

[0072] For example, various paraments of the semigroup may indicate a lack of security. In particular, a semigroup S that is used for key agreement must not have an efficient divider operator. If it did, then an adversary could compute Alice's secret a as a =d/b when b is public or if b is a weak secret such as a password.
Once the attacker figures out the secret a, the attacker can copy Alice's computations at block 250 to obtain the shared secret f = ae.

[0073] Similarly, no efficient left divider should exist within the semigroup S to avoid security issues.

[0074] Other elements to be considered when choosing the secure semigroup S
are provided below.

[0075] The Plactic Monoid Date Recue/Date Received 2022-01-19

[0076] One semigroup that may be used for the embodiments of the present disclosure is a plactic monoid. A monoid is any semigroup with identity element.
When clear from context, the identity element is written as 1. Being an identity element means la = a = al for all a in the monoid.

[0077] A tableau consists of rows of symbols, sorted by length. For example, Alfred Young in 1900 defined a set of boxes or cells arranged in a left-justified form, now known as a Young diagram. Figure 3A shows a Young diagram 310 in which the cells are sorted by length from the top down, with the top being the longest. This is referred to as English notation. Figure 3B shows a Young diagram 312 sorted by length with the bottom being the longest. This is referred to a French notation. The embodiments of the present disclosure could use either notation, but French notation is used as an example in the present disclosure.

[0078] A Young tableau comprises filling the boxes in the Young diagram with symbols from some ordered set. If the ordered set has no duplicates, this is referred to as a standard tableau. If the symbols in the ordered set are allowed to repeat, this may create a semistandard tableau. Specifically, in a semistandard tableau, each is row is sorted from lowest to highest (left to right), with repeats allowed. Also, in a semistandard tableau, each is column is sorted, but with no repeats allowed. In French notation, the columns are sorted lowest-to-highest (bottom-to-up).

[0079] An example of a semistandard tableau with single-digit symbols is shown with regards to Table 1 below.

Date Recue/Date Received 2022-01-19 TABLE 1: Example semistandard tableau with single-digit symbols

[0080] Knuth (1970) defined an associative binary operation applicable to semistandard Young tableaus via algorithms of Robinson (1938) and Schensted (1961). Schutzenberger and Lascoux (1980) studied the resulting algebra, naming it the plactic monoid.

[0081] Multiplication can occur on a symbol by symbol basis. An example is shown in Table 2 below, which shows the creation of a plactic monoid based on the string chelloworld using a single-symbol tableau. In Table 2, each row must be sorted.
In this case, when the next symbol can be added to the end of bottom row and leave the row sorted, it is added to this row. When the symbol cannot be added to the end of the bottom row, it replaces the symbol in that row which would leave the row sorted, and the replaced symbol is added to the row above in a similar fashion.
If there is no row above a symbol, then a new row is created.
Symbol Tableau Notes Since no row existed, h, forms the first row Since ce' is before ch', it replaces this symbol and the ch' is moved to the row above h dl can be added to the end of the last row el h dl can be added to the end of the last row ell co' can be added to the end of the last row ello Date Recue/Date Received 2022-01-19 cw can be added to the end of the last ellow row o hw "o" cannot be added to the end of the last elloo row, so it replaces the cw', and the cw' moves up to the next row.
hw cr' can be added to the end of the last row elloor w dl replaces the co' in the bottom row. co' ho replaces cw' in the second row. cw' moves elllor up and creates a new row.
cd' replaces the ce' in the first row. ce' replaces the ch' in the second row. ch' eo replaces the cw' in the third row. cw' moves dIllor up and creates a new row.
TABLE 2: Example Knuth multiplication

[0082] As seen from Table 2, multiplication is achieved through repeated insertion of symbols in a semistandard tableau.

[0083] In some embodiments, a string equivalence may be created from the tableau of Table 2. Specifically, instead of considering the plactic monoid as the set of semistandard tableaus, the set of all string forms may be considered up to equivalence relation. Two strings are equivalent if they generate the same semistandard tableaus. In this form, each tableau has alternate representation as strings,

[0084] From the last row of Table 2 for the "helloworld" string, the row reading string is "wheodIllor and the column reading string is "whedolllor". These two strings, and several others, will generate the same tableau as "helloworld" generates.

Date Recue/Date Received 2022-01-19

[0085] The "helloworld" and "wheodIllor strings are equivalent because they both generate the same tableau. Thus they are both alternative representations of the same sem istandard tableau.

[0086] A simplified example of a C program to implement such multiplication is shown with regards to Table 3 below.
#include <stdio.h>
#define T(a,b)(a^=b, b^=a,a^=b, 1 ) enum{L=1000000};typedef charks,S[L];typedef int i;typedef void _;
i knuth(i i,s w){return(w[2]<w[i-1])&(w[0]<=w[i])&&T(w[1],w[(i+1)%3]);}
_ robinson(s w,i j){i i; for(j>=2&&w[j]<w[j-1];j--) for(i=1; i<=2; i++) for(j>=2&&knuth(i,w+j-2);j--) ; }
_ get(s w){i i=0,c; while(i<L && (c=getchar())!=E0F) if(0!=c && '\n' !=c) w[i]=c, robinson(w,i++);}
_ put(s w){char o=0; for(;*w;w++) o>*w?puts(m):0, putchar(*w), o=*w;}
i main(_){S w=aget(w); put(w);puts(");}
TABLE 3: Example C program for Knuth multiplication

[0087] In the example code in Table 3, the program input is any text, with each ASCII character except nulls and newlines representing a generator element of the plactic monoid. The output of the program is a product of these, according to Knuth's version of the Robinson-Schensted algorithm, represented as a sem istandard tableau, as shown for example in Table 2.

[0088] While the examples of Tables 2 and 3 use ASCII characters as the ordered set for single-symbol tableaus, in practice any ordered set may be used as long as it is agreed to by both parties in a key agreement situation, as described below.
Further, while single-symbol tableaus are provided in the examples, in practice multi-symbol tableaus could equally be used.
Date Recue/Date Received 2022-01-19

[0089] Each element of the plactic monoid is therefore a product of symbols (also called generators). Products of symbols are considered equivalent if they can be related by a sequence of Knuth transformations as described above.

[0090] Elements of the plactic monoid are therefore equivalence classes of such products of symbols.

[0091] Key Agreement using Plactic Monoids

[0092] As a plactic monoid is a semigroup, it can be used for key agreement, referred to herein as plactic key agreement. Further, as the plactic monoid does not seem closely related to the DH, ECDH or SIDH, the security of plactic key agreement is independent of security these key agreement schemes. Plactic key agreement is therefore resistant to known quantum attacks.

[0093] Reference is now made to Figure 4. In the embodiment of Figure 4, two parties wish to create a secret key through a plactic key agreement scheme. In particular, as with Figure 1, Alice and Charlie communicate with each other.

[0094] In accordance with the embodiment of Figure 4, Alice, at block 210, chooses a secret code "a" and generates a semistandard tableau. In some embodiments the semistandard tableau can however be created during a multiplication and thus, in some cases Alice may simply choose secret "a".
Specifically, converting "a" to a semistandard tableau can occur either before multiplication with "b", as described below, or the two strings can be concatenated as "ab" and converted to a semistandard tableau.

[0095] Similarly, at block 212, Charlie chooses a secret "c" and may further in some cases create a semistandard tableau using Knuth multiplication as described in Table 2 above.

[0096] In some cases, the generation of 'a and 'c' may be done with a strong entropy source combined with a strong pseudorandom number generator. For Date Recue/Date Received 2022-01-19 example, uniform selection of rows of symbols may not the best for security.
Specifically, the content of the row, meaning the sorted version of the row's symbols, is generally revealed during key agreement, and is not kept secret.
For another example, further security might reveal that some keys are weak, and that these arise often enough to warrant checking for weak keys, and the keys may be re-generated as necessary.

[0097] As seen at block 420 and 422, both Alice and Charlie find a value "b".
The value b can be a public fixed value, or a prearranged secret value such as something derived from a password shared between Alice and Charlie. Other options for determining b are possible. Based on this, the value "b" can be a public value or can be a weak shared secret in some cases. In some cases "b" can be in the form of a sem istandard tableau.

[0098] At block 430 Alice computes a value d=ab using Knuth multiplication to find a sem istandard tableau. For example, to multiply sem istandard tableaus a and b, insert the symbols of b into a successively. As described with regard to Table 2, to insert a symbol, append it to the bottom row if possible (meaning that one still has a semistandard tableau). If not possible, let the inserted symbol replace one symbol of the bottom row. The replaced symbol then gets inserted into the rows above.

[0099] Similarly, at block 432, Charlie computes a value "e" where e=bc using Knuth multiplication to find a sem istandard tableau.

[0100] Thereafter, as seen by message 440, Alice delivers the value "d" to Charlie.
Similarly, in message 442, Charlie delivers the value "e" to Alice.

[0101] As will be appreciated by those in the art, the values "d" and "e" are sent in the clear, so tableau form is necessary for security. If Alice had simply computed d = ab as a concatenation of strings, without applying the tableau form, this raw Date Recue/Date Received 2022-01-19 string a would still be a valid alternative representation of d, but she would leak a, since an attack could find a just be reading from the start of the string.
Putting d in tableau form helps to hide a. The exact ordering of the symbols in "a" get mixed by the tableau computation. So, tableau form is used in d and e, else Alice and Charlie's secrets a and c will leak.

[0102] At block 450, Alice computes f=ae using Knuth multiplication to find a semistandard tableau. At block 452, Charlie computes g=dc using Knuth multiplication to find a semistandard tableau.

[0103] The use of a semistandard tableau created by Knuth multiplication is used for f and g, because the tableau forms used in d and e have scrambled the symbol orderings, so the only way to get agreement is to use a standard form, in this case, the semistandard tableau form.

[0104] As f=abc=g, Alice and Charlie now share a secret, namely f=g. Such shared secret has contributions by both parties. Such shared secret may then be used, for example, as a symmetric key for both encryption and authentication of content and messages in future communications.

[0105] An example simplified bash shell script for implementing the embodiment of Figure 4 is shown below with regards to Table 4. In the example in Table 4, the keys are small for illustration purposes, and are therefore likely insecure.
rand { head -c $1 /dev/urandom I base64 ; }
rand 48 > a # Alice generates individual secret rand 48> b # Base common to Alice and Charlie rand 48 > c # Charlie generates individual secret cat a b I ./mult > d # Alice delivers to Charlie cat b c I ./mult > e # Charlie delivers to Alice cat a e I ./mult > f # Alice computes agreed secret cat d c I ./mult > g # Charlie computes agreed secret Date Recue/Date Received 2022-01-19 sha256sum f g # Derive hashed keys, etc.
TABLE 4: Example Script Demonstrating Plactic Key Agreement

[0106] While the script shown is implemented on one machine, in practice parts of the script would be performed on two machines and delivered between the machines as provided in the embodiment of Figure 4.

[0107] In one example of running the script, 'a is chosen as:
BHmHUO5KZJWcEUvGuJ37skC3+wDn71Ri6Gi/ZBhZg4sZGzVxQruaQ61vJ1d2y2 xe. Also, cb' is chosen as:
2imJOKAzptz0LfjKzCZtSmY94TT6AckfThalOh4TQa0ghD4R3SuRtvgYLbT5pmz and 'c' is chosen as:
Fwhh27JmGwabMe3TMa6B9WDV3YJ/uTRmKrycyLkZV1f4ZiF7Tcpd4WFdOBA
3hw81.

[0108] Using these values, cd' is calculated as cab' and is shown in Table 5 below:
Zwz Wns Uhr KU lx HRcgu EHZaly CGQZipv BBOVYdmxz 7AJQTcijmtuz Date Recue/Date Received 2022-01-19 57DGJLOZekIttz 3669CGJSSZaaffhh 013446ADJKOTTYgghp +/02223445KLQRRTTbfmvz TABLE 5: Example Calculation for 'd'

[0109] Similarly, ce can be calculated from cbc'.

[0110] Alice receives ce' and Charlie receives cd'. Alice calculates T as cae', which is cabc'. Similarly, Charlie calculates Cg' as tic', which is cabc'. An example of T is shown in Table 6 below.
mw ks irz hnx Zlp Wciy Uagu RUdIv KQZcu HOVZmx EHTYhimt CGLWZgjpz BDJQSehktz ABCJKYZflvz 779GGSTbffmt 566DFJOaaabmuz 345ABDJOQRTVYegww Date Recue/Date Received 2022-01-19 133679B GJ KLTVacfhhkr 002244446AJ KM M RRTZh im pvy +//1122333478FFLOTTTVVZcddhw TABLE 6: Example Calculation for 'f'

[0111] When T and Cg' are put through a hash such as a SHA256 hash, both result to: b6f082f051ade15684ac10bdc696f7e84dfd9ad5a20ddd5eefb2a0f24d0837d2, indicating key agreement.

[0112] The embodiments of Figure 4 and Table 4 perform key agreement without any authentication being explicitly described. However, all key agreement, including well-established ECDH key agreement, is vulnerable to a man-in-the-middle attack, if the attacker can replace the delivered values with his own.
Therefore, most security protocols based on (ECDH) key agreement apply some authentication, often a digital signature, to one or both delivered values.
Similar authentication may occur with plactic key agreement to avoid man-in-the-middle attacks.

[0113] Further, the embodiments of Figure 4 and Table 4 perform key agreement using lines of text. However, in some cases, different operating systems use different conventions for line termination. Different languages and different systems have used different rules for sorting characters, and different sets of characters.

[0114] A larger set of symbols may also in some cases be beneficial for security purposes. Specifically, the example of Table 4 limits the set of symbols to 253, by excluding the NULL character and typical new line characters. Accordingly, a different input and output format might be used in some embodiments. For example, symbols might be 32-bit integers, and elements might consist of a fixed length of symbols, say 1000. Using this example, Alice and Charlie would send Date Recue/Date Received 2022-01-19 each other 4000 bytes. Other examples are possible, and the present disclosure is not limited to any character set or set of symbols.

[0115] Based on the above, the key agreement may, in some cases, need to agree on the set of symbols and ordering of the set prior to key agreement.

[0116] Compression

[0117] In some embodiments, the shared elements (ab and bc) during key agreement may be compressed, as the elements may be lines of text.

[0118] Compression and decompression involve no secrets, so they can be applied independently of the actual cryptographic implementation, and essentially independent of the security.

[0119] In this regard, compression and decompression may be applied in some embodiments in order reduce the size of the payload when communicating between Alice and Charlie.

[0120] Optimization

[0121] In some embodiments, other optimizations may be implemented during key agreement. For example, in one case code could be made resistant to buffer overflows.

[0122] For example, inputs may be checked and be properly validated. For example, if inputs are too long, then outputs will be incorrect, likely non-interoperable, and may be insecure. This could lead to a buffer overflow.

[0123] Various other secure programming techniques may also be implemented in some embodiments when implementing plactic key agreement in the real world.
For an example, a real-world implementation could zeroize secrets immediately after use, so that the secrets do not reside in memory or get written to a disk.

Date Recue/Date Received 2022-01-19

[0124] Side channel resistance may also be implemented in some embodiments.
In key agreement, some inputs are secret. An attacker learning the run-times might be thereby learn something about the secret inputs which affect the run-times.

Ideally, implementations should avoid such attacks by running in constant-time, or at least with run-time not correlated to secrets.

[0125] For conditional swaps in particular, there is a well-known general constant-time conditional swaps, which is used in elliptic curve cryptography. The use of constant-time conditional swaps could therefore be implemented in plactic key agreement in some embodiments.

[0126] Further, in some cases optimization may be performed on the code for plactic key agreement to improve the performance of the code. For example, the code in Table 4 repeatedly swaps pairs of elements in an array. A possible optimization might avoid this by placing rows non-contiguously in memory. This would allow rows to grow or shrink without needing to shift the rows in some cases.

[0127] On the other hand, a full two-dimensional array to store a tableau might use too much memory. Less memory can be used by instead storing rows using dynamic memory, known as the heap.

[0128] Further, if dynamic memory is too risky for some reason, such as side channel attacks, then a more special data structure can be used. In this case, a hyperbola can be drawn through the grid marking the only locations where the symbols can occupy a position. Approximately n log(n) memory locations will be needed.

[0129] Other options for optimization are also possible.

[0130] Combination of Plactic Key Agreement with Other Key Agreement Schemes Date Recue/Date Received 2022-01-19

[0131] In some embodiments, plactic key agreement may be the only mechanism used for key agreement. In other embodiments, plactic key agreement may be used in conjunction with other key agreement mechanisms. As different key agreement schemes may not suffer from the same attacks, the combination of key agreement schemes could provide an extra layer of protection.

[0132] Using the embodiment of Figures 2 and 4, Alice may generate two secrets, namely a and a', and Charlie may also generate two secrets, namely c and c'. A

common value b, or two values, namely b and b' could then be used, where Alice could generate ab using a first key agreement mechanism, such as ECDH, and generate a'b' (or a'b) using plactic key agreement, and provide these Charlie.

[0133] Similarly, Charlie could generate bc using a first key agreement mechanism, such as ECDH, and generate b'c' (or bc') using plactic key agreement, and provide these Charlie.

[0134] Alice and Charlie could then generate f and g using ECDH mechanisms and f' and g' using plactic key agreement mechanisms. The values f and f' could be hashed in some embodiments to create a key that would correspond to a hash of g and g'.

[0135] Based on the above, plactic key agreement could be used, either alone, or in combination with other key agreement mechanisms. Plactic key agreement has no known quantum vulnerabilities and could therefore be used to provide additional security to communications.

[0136] The above methods may be implemented using any computing device. One simplified diagram of a computing device is shown with regard to Figure 5. The computing device of Figure 5 could be any fixed or mobile computing device.

[0137] In Figure 5, device 510 includes a processor 520 and a communications subsystem 530, where the processor 520 and communications subsystem 530 cooperate to perform the methods of the embodiments described above.

Date Recue/Date Received 2022-01-19 Communications subsystem 530 may, in some embodiments, comprise multiple subsystems, for example for different radio technologies.

[0138] Processor 520 is configured to execute programmable logic, which may be stored, along with data, on device 510, and shown in the example of Figure 5 as memory 540. Memory 540 can be any tangible, non-transitory computer readable storage medium which stores instruction code that, when executed by processor 520 cause device 510 to perform the methods of the present disclosure. The computer readable storage medium may be a tangible or in transitory/non-transitory medium such as optical (e.g., CD, DVD, etc.), magnetic (e.g., tape), flash drive, hard drive, or other memory known in the art.

[0139] Alternatively, or in addition to memory 540, device 510 may access data or programmable logic from an external storage medium, for example through communications subsystem 530.

[0140] Communications subsystem 530 allows device 510 to communicate with other devices or network elements and may vary based on the type of communication being performed. Further, communications subsystem 530 may comprise a plurality of communications technologies, including any wired or wireless communications technology.

[0141] Communications between the various elements of device 510 may be through an internal bus 560 in one embodiment. However, other forms of communication are possible.

[0142] The embodiments described herein are examples of structures, systems or methods having elements corresponding to elements of the techniques of this application. This written description may enable those skilled in the art to make and use embodiments having alternative elements that likewise correspond to the elements of the techniques of this application. The intended scope of the techniques of this application thus includes other structures, systems or methods that do not differ from the techniques of this application as described herein, and Date Recue/Date Received 2022-01-19 further includes other structures, systems or methods with insubstantial differences from the techniques of this application as described herein.

[0143] While operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be employed. Moreover, the separation of various system components in the implementation descried above should not be understood as requiring such separation in all implementations, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

[0144] Also, techniques, systems, subsystems, and methods described and illustrated in the various implementations as discrete or separate may be combined or integrated with other systems, modules, techniques, or methods. Other items shown or discussed as coupled or directly coupled or communicating with each other may be indirectly coupled or communicating through some interface, device, or intermediate component, whether electrically, mechanically, or otherwise.
Other examples of changes, substitutions, and alterations are ascertainable by one skilled in the art and may be made.

[0145] While the above detailed description has shown, described, and pointed out the fundamental novel features of the disclosure as applied to various implementations, it will be understood that various omissions, substitutions, and changes in the form and details of the system illustrated may be made by those skilled in the art. In addition, the order of method steps are not implied by the order they appear in the claims.

[0146] When messages are sent to/from an electronic device, such operations may not be immediate or from the server directly. They may be synchronously or Date Recue/Date Received 2022-01-19 asynchronously delivered, from a server or other computing system infrastructure supporting the devices/methods/systems described herein. The foregoing steps may include, in whole or in part, synchronous/asynchronous communications to/from the device/infrastructure. Moreover, communication from the electronic device may be to one or more endpoints on a network. These endpoints may be serviced by a server, a distributed computing system, a stream processor, etc.

Content Delivery Networks (CDNs) may also provide may provide communication to an electronic device. For example, rather than a typical server response, the server may also provision or indicate a data for content delivery network (CDN) to await download by the electronic device at a later time, such as a subsequent activity of electronic device. Thus, data may be sent directly from the server, or other infrastructure, such as a distributed infrastructure, or a CDN, as part of or separate from the system.

[0147] Typically, storage mediums can include any or some combination of the following: a semiconductor memory device such as a dynamic or static random access memory (a DRAM or SRAM), an erasable and programmable read-only memory (EPROM), an electrically erasable and programmable read-only memory (EEPROM) and flash memory; a magnetic disk such as a fixed, floppy and removable disk; another magnetic medium including tape; an optical medium such as a compact disk (CD) or a digital video disk (DVD); or another type of storage device. Note that the instructions discussed above can be provided on one computer-readable or machine-readable storage medium, or alternatively, can be provided on multiple computer-readable or machine-readable storage media distributed in a large system having possibly a plurality of nodes. Such computer-readable or machine-readable storage medium or media is (are) considered to be part of an article (or article of manufacture). An article or article of manufacture can refer to any manufactured single component or multiple components. The storage medium or media can be located either in the machine running the machine-readable instructions, or located at a remote site from which machine-readable instructions can be downloaded over a network for execution.

Date Recue/Date Received 2022-01-19

[0148] In the foregoing description, numerous details are set forth to provide an understanding of the subject disclosed herein. However, implementations may be practiced without some of these details. Other implementations may include modifications and variations from the details discussed above. It is intended that the appended claims cover such modifications and variations.

Date Recue/Date Received 2022-01-19

Claims (19)

1. A method for key agreement between a first party and a second party over a public communications channel, the method comprising:
selecting, by the first party, a first value "a";
multiplying the first value "a" by a second value "b" using Knuth multiplication to create a third value "d", the third value "d" being a semistandard tableau;
sending the third value "d" to the second party;
receiving, from the second party, a fourth value "e", the fourth value being a second semistandard tableau comprising the second value "b" multiplied by a fifth value "c" selected by the second party; and creating a shared secret by multiplying the first value "a" with the fourth value "e" using Knuth multiplication, wherein the shared secret matches the third value "d" multiplied by the fifth value "c" using Knuth multiplication.

2. The method of claim 1, wherein the first value "a" comprises a sem istandard tableau.

3. The method of claim 1, wherein the first value "a" is generated from an ordered set of symbols agreed to between the first party and the second party.

4. The method of claim 3, wherein the first value "a" is generated using a strong entropy source combined with a strong pseudorandom number generator.

5. The method of claim 1, wherein the sending of the third value utilizes an authentication mechanism.

6. The method of claim 1, where the sending of the third value uses data compression.

Date Recue/Date Received 2022-01-19

7. The method of claim 1, further comprising:
performing a second key agreement between the first party and the second party, the second key agreement being a key agreement other than a plactic key agreement; and hashing the shared secret with a second shared secret found using the second key agreement.

8. The method of claim 7, wherein the second key agreement is any one of Diffie Hellman key agreement; Elliptic Curve Diffie Hellman key agreement; and Supersingular lsogeny-based Diffie-Hellman (SIDH) key agreement.

9. The method of claim 1, further comprising using multi-symbol tableaus to create the sem istandard tableau.

10. A computing device configured for key agreement between a first party and a second party over a public communications channel, the computing device comprising:
a processor; and a communications subsystem, wherein the computing device is configured to:
select a first value "a";
multiply the first value "a" by a second value "b" using Knuth multiplication to create a third value "d", the third value "d" being a sem istandard tableau;
send the third value "d" to the second party;
receive, from the second party, a fourth value "e", the fourth value being a second sem istandard tableau comprising the second value "b" multiplied by a fifth value "c" selected by the second party; and create a shared secret by multiplying the first value "a" with the fourth value "e" using Knuth multiplication, Date Recue/Date Received 2022-01-19 wherein the shared secret matches the third value "d" multiplied by the fifth value "c" using Knuth multiplication.

11. The computing device of claim 10, wherein the first value "a" comprises a sem istandard tableau.

12. The computing device of claim 10, wherein the first value "a" is generated from an ordered set of symbols agreed to between the first party and the second party.

13. The computing device of claim 12, wherein the first value "a" is generated using a strong entropy source combined with a strong pseudorandom number generator.

14. The computing device of claim 10, wherein the computing device is configured to send the third value using an authentication mechanism.

15. The computing device of claim 10, where the computing device is configured to send the third value using data compression.

16. The computing device of claim 10, wherein the computing device is further configured to:
perform a second key agreement between the first party and the second party, the second key agreement being a key agreement other than a plactic key agreement; and hash the shared secret with a second shared secret found using the second key agreement.

17. The computing device of claim 16, wherein the second key agreement is any one of Diffie Hellman key agreement; Elliptic Curve Diffie Hellman key Date Recue/Date Received 2022-01-19 agreement; and Supersingular lsogeny-based Diffie-Hellman (SIDH) key agreement.

18. The computing device of claim 10, wherein the computing device is further configured to use multi-symbol tableaus to create the sem istandard tableau.

19. A computer readable medium for storing instruction code for key agreement between a first party and a second party over a public communications channel, the instruction code, when executed by a processor of a computing device cause the computing device to:
select a first value "a";
multiply the first value "a" by a second value "b" using Knuth multiplication to create a third value "d", the third value "d" being a sem istandard tableau;
send the third value "d" to the second party;
receive, from the second party, a fourth value "e", the fourth value being a second sem istandard tableau comprising the second value "b" multiplied by a fifth value "c" selected by the second party; and create a shared secret by multiplying the first value "a" with the fourth value "e" using Knuth multiplication, wherein the shared secret matches the third value "d" multiplied by the fifth value "c" using Knuth multiplication.

Date Recue/Date Received 2022-01-19