LU100142B1 - Electronic communication and access-control method - Google Patents

Abstract

A communication method, comprising receiving or generating, by a first communication terminal, a proof-of-work test, the proof-of-work test being compliant to a proof-of-work protocol agreed upon within a network comprising, at least, the first communication terminal and a second communication terminal. The method further comprises producing a proof-of-work associated with the proof-of-work test by solving the proof- of-work test according to a privileged-user strategy. The privileged-user strategy comprises a meet-in-the-middle search using a secret key associated with the proof- of-work test. In addition, the method comprises transmitting, broadcasting or multicasting the produced proof-of-work on the network for verification of the produced proof-of-work by the second communication terminal

Description

I ELECTRONIC COMMUNICATION AND ACCESS-CONTROL METHOD

Field of the Invention [0001] The invention generally pertains to a communication method and an accesscontrol method for communication networks. More particularly, the method comprises producing a proof-of-work associated with a received or self-imposed proof-of-work test according to a privileged-user strategy and transmitting, broadcasting or multicasting the same over the network for verification by one or more other network members.

Background of the Invention [0002] Proof-of-works (PoWs) have historically been introduced in the nineteen hundred nineties for combating spam and denial of service attacks [1-3]. A PoW is a piece of data that is hard (costly, time-consuming) to produce but easy (cheap, fast) to verify.

[0003] Since then, PoWs have attracted more and more attention, especially because they are used as core building blocks in the most recognized and widely used digital currency: Bitcoin [4]. PoWs are used in Bitcoin for producing blocks (which are recording the transactions, a block comprises a plurality of transactions). The so-called miners must produce a PoW which covers all of the data in current block and some data of one or more preceding blocks in order for a block to be accepted by network participants. One miner manages to generate a proof-of-work in approximately 10 minutes and communicates (transmits) it to the network participants for verification of the validity of the generated PoW. If the block is accepted, it is added to the chain of other blocks for bookkeeping, effectively increasing the size of the so-called blockchain.

[0004] Currently, three categories of PoWs are on the market, each of them aiming at a different type of hardness: CPU-bound PoWs, memory-bound PoWs and networkbound PoWs. CPU-bound PoWs are PoWs that require many computations (so-called computational hardness) to generate [4], memory-bound PoWs are PoWs that are memory intensive [5-8] (so-called memory hardness) and network-bound PoWs are PoWs that are network intensive (so-called bandwidth hardness). I [0005] Document US 7149801 relates to the field of distributed computing and more particularly, but not exclusively, to systems and methods for reducing spam and/or other unwanted behavior on a computer network, such as the Internet. US 7149801 proposes a system in which a memory bound function is employed to formulate a computational puzzle type of "challenge" for reducing spam and/or other unwanted behavior on a computer network.

[0006] Document US 2010/0031315 relates to a systems and methods for using client puzzles to protect against denial-of-service attacks. The puzzles are placed at the network layer level and/or application layer level to protect against denial-of-service attacks. Further, document US 2010/0031315 claims to provide a robust and flexible solution to support puzzle issuance at arbitrary points in the network, including end hosts, firewalls, and routers and thereby a defense against denial-of-service attacks.

General Description [0007] As used herein, the term “PoW protocol” designates a protocol or set of rules that define the generic structure of well-shaped PoW tests and the verification method of the PoWs. The term “PoW test” designates a specific instance of a computational puzzle or challenge within the class of all puzzles or challenges that are compliant with the PoW protocol. Given a PoW test, a PoW is a solution of the test that results in a successful verification under the verification method. The verification method uses a verification function that returns “True” or “False” for a given PoW test and a candidate solution. A PoW thus is a solution for which the verification function returns “True”.

[0008] A first aspect of the invention pertains to a communication method (for electronic communication). The method comprises receiving or generating, by a first communication terminal, a PoW test. The received or generated PoW test is compliant with a PoW protocol agreed upon within a communication network comprising, at least, the first communication terminal and a second communication terminal. The method further comprises producing a PoW associated with the PoW test by solving the PoW test according to a privileged-user strategy. The privileged-user strategy comprises a meet-in-the-middle search, the meet-in-the-middle search using a secret key associated with the PoW test. The produced PoW is transmitted, broadcast or multicast over the network for verification by the second communication terminal. The transmission of the PoW on the network may be effected via one or more point-to-point I communication links between the first communication terminal and the second communication terminal, via broadcast or via multicast. Direct reception of the PoW by the second communication terminal may be desirable or even necessary for some applications but is not necessary in general. For instance, transmission on the network could comprise making available the PoW for inspection (by the general public or only the network members) on a server or other network resource.

[0009] The fact that a meet-in-the-middle search can be applied using a secret key implies that the verification function uses two or more cryptographic functions, at least one of which is a trapdoor function that is invertible using the secret key. The meet-in-the-middle search reduces, on average, the computational effort a privileged user (possessing the secret key) needs to perform in comparison to a common (nonprivileged) user (not possessing the secret key) in order to find a valid solution to the PoW test. The meet-in-the-middle search relies on storing intermediate values obtained by applying the first cryptographic function(s) to test inputs and to look for a match with intermediate values obtained by applying the inverse of the trapdoor function(s) to test outputs. When a match is found, a valid solution of the PoW test is deduced from the corresponding test input and test output. It should be noted that the terms “test input” and “test output” both designate candidate starting values. Different designations have been used merely to distinguish between candidate starting values within the domain ofthefirst of the cryptographic functions (“test inputs”) and candidate starting values within the range of the last of the cryptographic functions (“test outputs”).

[0010] Preferably, the communication method comprises determining, by the first communication terminal, whether the secret key associated with the PoW test is known to the first communication terminal. The secret key is known to the first communication terminal if it is stored in a memory of the first communication terminal or in a memory the first communication terminal has access to. The method further comprises producing a PoW associated with the PoW test by solving the PoW test according to a common-user strategy instead of the privileged-user strategy if the secret key is not known. The common-user strategy may comprise a brute-force search of a PoW associated with the PoW test. A “brute-force search” is a trial-and-error search, wherein candidate PoWs are generated (e.g. using a random number generator) and tested using the verification function until verification is successful. I [0011] An interesting advantage of the invention resides in the fact that verification ol PoW is very easy (computationally cheap) for all network members (for both privileged and non-privileged ones.) The method used to perform this verification may be identical for checking the solutions found by both privileged users and common ones. In other words, no special resources or knowledge is needed to verify the PoWs of privileged users. Therefore, the second communication terminal that verifies the PoW generated by the first communication terminal need not be itself a privileged user. In case of an application of the invention, in which PoWs are made available to all network members for verification (this may be the case, for instance, in applications where the PoWs document successful mining), there may be several network members that take the role of the second communication terminal.

[0012] According to an embodiment, the meet-in-the-middle search comprises: a) generating a plurality of test input bit strings; b) applying a cryptographic function to each of the plurality of test input bit strings to generate a plurality of image bit strings; c) storing the image bit strings in a memory; d) generating a test output bit string; e) applying the inverse of a trapdoor function to the test output bit string, the application of the inverse of the trapdoor function using the secret key associated with the PoW test; f) comparing the stored image bit strings to the image of the test output bit string under the inverse of the trapdoor function, wherein the comparison checking if the image of the test output bit string under the inverse of the trapdoor function and any of the stored image bit strings present a matching bit pattern (i.e. the same bits on predefined bit positions, e.g. an identical substring); and g) repeating steps d) to f) with different test output bit strings until the comparison yields a match.

[0013] According to an alternative embodiment, the meet-in-the-middle search comprises: a) generating a plurality of test output bit strings; b) applying the inverse of a trapdoor function to the test output bit strings to generate a plurality of image bit strings, the application of the inverse of the I trapdoor function using the secret key associated with the proof-of-work test; c) storing the image bit strings; d) generating a test input bit string e) applying a cryptographic function to the test input bit string; f) comparing the stored image bit strings to the image of the test input bit string under the cryptographic function, wherein the comparison comprises checking if the image of the test input bit string under the cryptographic function and any of the stored image bit strings present a matching bit pattern; and g) repeating steps d) to f) with different test input bit strings until the comparison yields a match.

[0014] As used herein, a bit string designates a sequence of bits, which may be organized as any suitable data structure. Bits may be represented as “0”s and “1”s. Bit strings may also be written in hexadecimal (base 16 or hex) notation, which is regarded as particularly convenient for long bit strings.

[0015] As used herein, the term “cryptographic function” designates a function that obscures the relationship between input values and their images under the function. If a part of the bits of an output value under such a function is given, then the only way to find a corresponding input, certain bits of which are constrained, is proceeding by trial-and-error or knowledge of the trapdoor (secret), if any. Examples of cryptographic functions are hash functions, pseudorandom permutations (PRP) and one-way functions (including trapdoor functions). Cryptographic one-way functions are cryptographic functions that are easy to compute on a given input but very hard (prohibitively costly in terms of computational resources) to invert. In other words, given a randomly selected image, it is very hard and costly to find the input that yields the image under the function. Preferably, the cryptographic function comprises a hash function, a random oracle or a pseudo-random permutation (e.g. a permutation from the SHA-3 standard). A trapdoor function is a cryptographic one-way function, which can (only) be inverted easily if a special piece of information (the secret key) is known. Preferably, the trapdoor function is a RSA trapdoor function having a private key. The RSA trapdoor function is inverted using the private key as the secret key. Trapdoor I functions based on Rabin’s cryptosystem, Schmidt-Samoa cryptosystem or others car be used as well.

[0016] In one embodiment, the test input bit strings and/or the test output bit string are generated using a random or pseudorandom number generator, a cryptographic function (e.g. a hash function) and/or a counter.

[0017] Preferably, the generation of the test input bit string and/or the test output bit string is constrained; the constraint(s) comprising a subset of bits of the test input bit string and/or of the test output bit string being fixed to a predefined value. For instance, the PoW protocol may specify that a part of each test input bit string and/or test output bit string must correspond to a certain value. The protocol may define the rules as to how this value or these values have to be calculated. The PoW protocol could, for example, specify that the value(s) must be derived from some parameters of the communication network, e.g., previously published PoWs, geographic location, current time, etc. A possibility to derive such value(s) would be to assemble the needed parameters in a way specified by the PoW protocol and then apply a hash function. Alternatively, the PoW protocol could specify that the constraints are fixed by a network member requesting the PoW.

[0018] An interesting advantage of the proposed invention is that difficulties of finding PoW for the privileged and non-privileged users can be adjusted separately and without impacting the ease of PoW verification.

[0019] As the verification function may be regarded as a composition of two or more cryptographic functions followed by a Boolean-valued function returning “True” (or 1) or “False” (or 0), the constraint preferably includes that the test output bit string is within the preimage of “True” (or 1).

[0020] In an embodiment, the predefined value of the subset of bits comprises a signature indicative of the use of the privileged-user strategy for producing the PoW.

[0021] Preferably, the method further comprises transmitting the signature to the second communication terminal.

[0022] A second aspect of the invention pertains to an access-control method for a communication network, wherein a first communication terminal requests a service to a second communication terminal, the second communication terminal being configured to grant or deny the request of access to the service based upon a I transmission of a PoW by the first communication terminal. Moreover, the firsl communication terminal carries out the communication method according to firsl aspect of the invention. In addition, the first communication terminal receives a granl or denial of access to the requested service from the second communication terminal. If access is granted by the second communication terminal, the first communication terminal accesses the service.

[0023] The service may comprise making available a website, a mail server, a game, a (distributed) database, or making a publicly (or privately) verifiable record in a (distributed) ledger.

[0024] In one embodiment, the access-control method is a part of a spam mitigation method, e.g. a spam mitigation method for emails.

[0025] A third aspect of the invention pertains to computer program comprising instructions, which, when executed by a computer, cause the computer to carry out the method according to the first or the second aspect of the invention.

[0026] A further aspect of the invention pertains to a computer program product comprising a computer readable medium (volatile or non-volatile memory, e.g. hard disk, flash drive, solid-state drive, etc.) having stored thereon a computer program according to the third aspect of the invention.

Brief Description of the Drawings [0027] By way of example, preferred, non-limiting embodiments of the invention will now be described in detail with reference to the accompanying drawings, in which:

Fig. 1: depicts an access-control method according to an embodiment of the invention;

Fig. 2: depicts an access-control method according to another embodiment of the invention;

Fig. 3; illustrates a first example of a cryptographic function used by a proof-of-work system;

Fig. 4: illustrates an example of a meet-in-the-middle search procedure;

Fig. 5: illustrates a second example of a cryptographic function used by a proof-of-work system; and

Fig. 6: illustrates an embodiment of a communication method.

Detailed Description of Preferred Embodiments [0028] Fig. 1 shows an access-control method 10 for an electronic communication network, according to an embodiment of the invention. A client terminal 12 sends a service request 14 to a server terminal 16. Upon receiving the request 14, the server terminal 16 generates a PoW test compliant to a PoW protocol implemented by both the client terminal 12 and the server terminal 16. The server terminal 16 then responds to the service request 14 by transmitting (a message containing) the PoW test 18 to the client terminal 12. The client terminal 12 solves the received PoW test, thereby producing 20 a PoW, and sends back (a message containing) the solution 22 (the PoW) to the server terminal 16. The client terminal may also send back other information (described hereinafter) produced when solving the PoW test. The server terminal 16 verifies that the PoW received from the client terminal 12 is valid, i.e. that the PoW actually solves the PoW test. Finally, the server terminal 16 grants or denies 24 the client terminal 12 access to the service depending on the outcome of the verification.

[0029] Fig. 2 shows another access-control method 26. A client terminal 28 attempts to have access to a service. To this end, the client terminal 28 generates 30 a selfimposed PoW test compliant with a PoW protocol implemented by the client terminal 28 and the server terminal 32 (which controls access to the desired service). The client terminal 28 then solves 34 the PoW test and transmits a message 36 containing the PoW test and the corresponding PoW to the server terminal 32 for verification. As in the previous embodiment, the client terminal 28 may also send other information produced when solving the PoW test. The server terminal 32 then verifies if the self-imposed PoW test complies with the PoW protocol and if the received PoW is a valid solution of the PoW test. Finally, the server terminal 32 grants or denies 38 the client terminal 28 access to the requested service depending on the verifications of the PoW test and the PoW.

[0030] In the embodiments depicted in Fig. 1 and Fig. 2, the service to which the client terminal attempts to gain access to may be hosted on the server terminal or on a different terminal. The service could be establishing any kind of electronic communication, e.g. email service. I [0031] According to an embodiment of the invention, an asymmetric proof-of-work system is defined using a function, hereinafter denoted VerifCore(i,x), where i is an input parameter and x is an a priori unknown value. The aim for the users is, given i, to recover a value x such that VerifCore(i,x) is in some subset (hereinafter denoted subset Ύ”) of the range of the function VerifCore. Users can be privileged, in which case they know a secret shortcut, hereinafter denoted “k”. Otherwise, they are common users. Common users may use a procedure Long(i), which allows them to find a suitable x. Privileged users can use a special procedure Short(k,i), which allows them to find a suitable x with, on average, less computational effort, i.e., Short(k,i) has less computational complexity than Long(i), which is typically a brute-force search.

[0032] The function VerifCore and Y generically define a class of puzzles. When VerifCore is given, the parameter i defines a puzzle instance, i.e. a specific puzzle in this class. In this document, a puzzle instance is also referred to as PoW test. While VerifCore is typically defined in the PoW protocol, i is typically generated ad hoc, i.e. at runtime. A solution x of a PoW test i is valid if VerifCore(i,x) is in Y, i.e., if 1 YoVerifCore(i,x) = 1, where “o” designates function composition and 1 γ is the indicator function of Y. The function lYoVerifCore(i,x) is the verification function and is denoted Verif(i.x) below.

[0033] In the embodiments of the invention discussed hereinafter, VerifCore uses two cryptographic functions, the second of which is a trapdoor permutation. The following definitions will be used: o R designates a trapdoor permutation operating on n bits. It could for example be based on RSA. o k is the secret key that allows the inversion of R. o R'1 is the functional inverse of R. It can only be evaluated by users who know k. o F is a cryptographic function that operates on n bits. F could operate, for instance, as a random oracle or as a pseudo-random permutation. ο H is a hash function operating on n-bit strings and producing a C-bit output. It could, e.g., be obtained by truncating the output of a 512-bit hash function. I o A puzzle instance is defined by a pair i=(s,t) where s and t are bit strings of length ns and P, respectively. o A candidate solution (or candidate PoW) x is composed of two parts xo and xi of length n-ns and n-C, respectively, x may be written as the pair (xo, xi). o S is the set of all possible candidate solutions x. The set S is the set SoxSi where So is the set of all bit strings of length n-ns and Si is the set of all bit strings of length n-C. o The concatenation of two strings yo and yi is denoted “yo || yi”.

[0034] In the embodiments described in detail below, it will be assumed that R is RSA encryption under public key Z, denoted RZ for brevity. The inverse operation, “decryption” necessitating k, is denoted RZ'1. Generalisation to any other trapdoor permutation can be obtained by dropping the letter Z in the examples below.

Example 1: “Katchup” [0035] Fig. 3 illustrates a first example of the function VerifCore. VerifCore((s,t),(xo,xi)) is evaluated as follows: o F is applied to xo || s: F(xo || s). o xi is XORed on n-C bits of F(xo || s). Without loss of generality, the XORed bits may be assumed to be the first n-C bits of F(xo || s). Exclusive OR (XOR) corresponds to bitwise modulo-2 addition, denoted with ®. o RZ is applied on the result of the previous step. This yields a result bit string X2 H t’ = VerifCore((s,t),(xo,xi)).

[0036] VerifCore((s,t),(xo,xi)) is a valid solution (i.e. Verif((s,t),(xo,xi)) = 1 or “True") if the substring t’ of the last P bits of VerifCore((s,t),(xo,xi)) is equal to t.

[0037] Procedure Long could rely on simply trying random values of xo and xi until a working combination is found. That is, in pseudocode: DO (xo,xi) = random values WHILE Verif((s,t),(xo,xi)) = 0 (or “False”).

[0038] Procedure Short can use a time-memory trade-off using the fact that the secret shortcut key k is known. A possible meet-in-the-middle search (see also Fig. 4) works as follows (s and t are given bit strings):

I 1. The client terminal generates M random values xo (step S10) and stores them in a hash table indexed by the last C bits of F(xo || s) (step S12). 2. The client terminal then chooses a random value of X2 (bit string of length n-P) (step S14) and computes RZ’1(X21| t) (step S16). This step is repeated while the last C bits of RZ’1(X21| t) are not found in the hash table obtained in step S12 (step S18). 3. Once a match has been identified in step S18, xi is identified with the first n-C bits of F(xo H s) © RZ'1(X21| t) (step S20) and (xo, x-ι) is returned (step S22). Optionally, X2 is returned as well.

[0039] It should be noted that while in this example, xi is XORed with the first n-C bits of F(xo U s), it is possible to use other operations, such as, e.g., modular addition or subtraction, modular multiplication or division, finite-field multiplication or division, etc. In fact, XOR could be replaced by any operation such that, given bit strings u and V, it is easy to find a bit string w such that u*w = v. It should also be noted that the meet-in-the-middle search could be done in the opposite direction. The client terminal would generate M random values of X2, store them in a hash table indexed by the last C bits of RZ-1(X2 H t) and then iterate a random choice of xi until a match for F(xo || s) is found in the table.

Example 2: “Katchup-H” [0040] Fig. 5 illustrates a second example of the function VerifCore. VerifCore^s.tJXxo.xi)) is evaluated as follows: ο H (hash function with C-bit output) is applied to xo || s to yield C-bit value y = H(xo H s). o An internal state is built by concatenating xi and y: xi || y. o RZ is applied on xi || y. This yields a result bit string X2II t’ = VerifCore((s,t),(xo,xi)). Optionally, X2 is returned as well.

[0041] VerifCore((s,t),(xo,xi)) is a valid solution (i.e. Verif((s,t),(xo,xi)) = 1 or “True”) if the substring t’ of the last P bits of VerifCore((s,t),(xo,xi)) is equal to t.

[0042] As in the previous example, procedure Long could simply rely on trying random values of xo and xi until a working combination is found. That is, in pseudocode: DO (xo,xi) = random values WHILE Verif((s,t),(xo,xi)) = 0 (or “False”). I [0043] Procedure Short can again be a meet-in-the-middle search working as follows (s and t are given bit strings): 1. The client terminal generates M random values xo and stores them in a hash table indexed by H(xo || s). 2. The client terminal then chooses a random value of X2 (bit string of length n-P) and computes RZ’1(X21| t). This step is repeated while the last C bits of RZ'1(X2 II t) do not correspond to one of the values of H(xo || s) in the hash table obtained at step 1. 3. Once a match has been identified in step 2, xi is identified with the first n-C bits of RZ'1(X21| t) and (xo, xi) is returned. Optionally, X2 is also returned.

[0044] In both examples, the running time of Long is dominated by the roughly 2P calls to Verif it requires. Short runs in time T by storing M values xo, where M and T are such that TM=2C and M ST. Therefore, the client terminals are separated into different classes depending on their ownership of the shortcut key k. Privileged users (possessing k) can find a solution using a procedure with a complexity different from that of the brute-force search used by common users.

[0045] In both examples, it is possible to make privileged users identify themselves (as privileged in general, as belonging to a certain subset of privileged users or as an individual user) by forcing them to respect a certain constraint on X2, i.e. by fixing a specific value for a subset of bits of X2. In that way, X2 includes a certain signature in form of a bit pattern (e.g. a fixed number of bits equal to 0 at the beginning or end of X2) or a result of a cryptographic function, like a MAC tag (authentication tag).

[0046] The pair (s,t) should not repeat itself and should not be predictable in order to prevent common users from amortizing the cost of finding solutions.

[0047] Asymmetric proof-of-work systems have several advantages. The puzzles solved by both classes of users are identical and the only distinction between the users is the ownership of the secret key. No database of all users is thus needed to make a difference between them. The use of an asymmetric proof-of-work allows a decentralized discrimination of the users. The difficulty of solving a puzzle depends on whether the secret key is known. In the above-described embodiments, Katchup and Katchup-H, the parameters P and C determining the complexity of the puzzles for privileged and common users are independent and can be adjusted separately. P (= length of t) determines the complexity for common users: if P is increased, the computation effort increases for common users; if the length of xi is increased (C is decreased), then the computational effort decreases for privileged users. It is thus possible, for instance, to define (on the level of the PoW protocol) the average computational effort a privileged user has to invest into the resolution of one puzzle without modifying puzzle complexity for common users. Moreover, if the PoW protoco so specifies, C and P could be tuned dynamically, e.g. be changed depending on the workload of the verification server and/or the server providing the requested service and/or other network parameters such as, for instance, the rate at which new PoWs are made available. The verification of PoW is very easy for all users (both privileged and non-privileged) and the method used to perform this verification may be identical for checking the solutions found by both privileged users and common ones.

[0048] Fig. 6 schematically illustrates an embodiment of a communication method, wherein a client terminal is requested by a server terminal to provide a PoW. In step S24, the client terminal receives a PoW test (puzzle instance (s,t)). The client terminal then checks whether the secret key associated with the PoW test to be solved is known (step S26). If it is the case, the client terminal applies a privileged-user strategy comprising a meet-in-the-middle search (step S28). In the opposite case, the client terminal solves the PoW test using a common-user strategy which may comprise or consist of a brute-force search of a PoW (step S30). When a PoW associated with the PoW test has been found, it is returned and transmitted to the server terminal for verification (step S32).

[0049] It will be appreciated that the communication method described herein could be used in the technical infrastructure underlying a cryptocurrency in order to prevent a so-called 51% attack. A supervising authority could control the privileged-user rights, i.e. be in the possession of the secret key. In the event that a group of users could gain control over the network, the supervising authority could prevent that from actually happening, using only a fraction of the computational resources necessary for common users. The sheer possibility of regulatory intervention by the supervising authority would make it unattractive to attempt an attack of that kind.

[0050] While specific embodiments have been described herein in detail, those skilled in the art will appreciate that various modifications and alternatives to those details could be developed in light of the overall teachings of the disclosure. Accordingly, the I particular arrangements disclosed are meant to be illustrative only and not limiting as to the scope of the invention, which is to be given the full breadth of the appended claims and any and all equivalents thereof.

Citation list [1] C. Dwork C.,M. Naor (1993) Pricing via Processing or Combatting Junk Mail. In: Brickell E.F. (eds) Advances in Cryptology — CRYPTO’ 92. CRYPTO 1992. Lecture Notes in Computer Science, vol 740. Springer, Berlin, Heidelberg. [2] M. Jakobsson, A. Juels. "Proofs of Work and Bread Pudding Protocols". Communications and Multimedia Security. Kluwer Academic Publishers: 258-272. (1999). [3] A. Back, "Hashcash - a denial of service counter-measure," 2002. First announced in March 1997. [4] S. Nakamoto, “Bitcoin: A Peer-to-Peer Electronic Cash System”, 2008. [5] C. Dwork, A. Goldberg and M. Naor, “On Memory-Bound Functions for Fighting Spam”. In CRYPTO’03 (2003), vol. 2729 of Lecture Notes in Computer Science, Springer, pp. 426-444. [6] C. Percival, "Stronger key derivation via sequential memory-hard functions". http://www.tarsnap.com/scrypt/scrypt.pdf [7] A. Biryukov, D. Khovratovich, “Equihash: Asymmetric Proof-of-Work Based on the Generalized Birthday Problem”. NDSS 2016 [8] A. Biryukov, D. Dinu, D. Khovratovich, “Argon2: New Generation of Memory-Hard Functions for Password Hashing and Other Applications”, EuroS&P 2016: 292-302.

Claims (17)

A method of communication, comprising: receiving or generating, by a first communication terminal, a proof of work test, the proof of work test being in accordance with a protocol of proof of work adopted within a network communication system comprising, at least, the first communication terminal and a second communication terminal; the production of proof of work associated with the proof of work test by resolution of the proof of work test according to a privileged user strategy, the privileged user strategy including a meeting-in-the-middle search, the encounter-at-the-job search middle using a secret key associated with the proof of work test; and transmitting, broadcasting or multicasting the work proof produced on the network for verification by the second communication terminal. 2. The communication method according to claim 1, comprising: the action of determining, by the first communication terminal, whether the secret key associated with the proof of work test is known by the first communication terminal; and the production of proof of work associated with the proof of work test by resolution of the proof of work test according to a common user strategy instead of the privileged user strategy if the secret key is not known. The communication method of claim 2, wherein the common user strategy includes a brute force search of a proof of work associated with the proof of work test. The communication method according to any one of claims 1 to 3, wherein the encounter-in-the-middle search comprises: a) generating a plurality of test input bit strings; b) applying a cryptographic function to each of the plurality of test input bit strings to generate a plurality of image bit strings; c) storage of image bit strings; d) generating a test output bit string; e) applying the inverse of a trap function to the test output bit string, applying the inverse of the trap function using the secret key associated with the proof of work test; f) comparing the image bit strings stored with the image of the test output bit string with the inverse of the trap function, wherein the comparison comprises the act of checking whether the bit string image test output by the inverse of the trap function and any of the stored bit-image strings have a corresponding bit pattern; and g) repeating steps d) to f) with different test output bit strings until the comparison results in a match. The communication method according to any one of claims 1 to 3, wherein the encounter-in-the-middle search comprises: a) generating a plurality of test output bit strings; b) applying the inverse of a trap function to the test output bit strings to generate a plurality of image bit strings, applying the inverse of the trap function using the secret key associated with the proof test working; c) storage of image bit strings; d) generating a test input bit string; e) applying a cryptographic function to the test input bit string; f) comparing the image bit strings stored with the image of the test input bit string with the cryptographic function, wherein the comparison comprises the action of checking whether the image of the input bit string cryptographic function test and any of the stored bit-image strings have a corresponding bit pattern; and g) repeating steps d) through f) with different test input bit strings until the comparison results in a match. The communication method according to claim 4 or 5, wherein the trap function is an RSA trap function having a private key, the RSA trap function being inverted using the private key as a secret key. 7. The communication method according to claim 4 or 5, wherein the trap function comprises a Rabin type flap permutation or a hatch permutation of a Schmidt-Samoa cryptosystem. The communication method according to any one of claims 4 to 7, wherein the cryptographic function is a hash function, a random oracle or a pseudo-random permutation. The communication method according to any one of claims 4 to 8, wherein the test input bit strings and / or the test output bit strings are generated using a random number generator. or pseudo-random, a cryptographic function and / or a counter. The communication method according to any one of claims 4 to 9, wherein the generation of the test input bit string and / or the test output bit string is constrained; the constraint comprising that a subset of bits of the test input bit string and / or the test output bit string are set to a predefined value. The communication method of claim 10, wherein the predefined value of the subset of bits includes a signature indicative of the use of the privileged user policy to produce the work proof. The communication method of claim 11 including transmitting the signature to the second communication terminal. The communication method as claimed in any one of claims 1 to 12, wherein the proof of work attests the validity of the changes introduced in a database or register. 14. An access control method for an electronic communications network in which: a first communication terminal requests a service from a second communication terminal, the second communication terminal being configured to allow or deny the access request to the second communication terminal; service based on the transmission of proof of work by the first communication terminal; the first communication terminal carries out the communication method according to any one of claims 1 to 12; the first communication terminal receives an authorization or refusal of access to the requested service; and the first communication terminal accesses the service if access is allowed by the second communication terminal. The access control method of claim 14 wherein the access control method is part of a spam mitigation method. 16. A computer program comprising instructions, which, when executed by a computer, causes the computer to perform the method as claimed in any one of claims 1 to 15. A computer program product comprising a computer readable recording medium having the computer program of claim 16 stored thereon.