Privacy-preserving data permutation
Patent Information
- Authority / Receiving Office
- EP · EP
- Patent Type
- Applications
- Current Assignee / Owner
- ROSEMAN GRP BV
- Filing Date
- 2024-08-06
- Publication Date
- 2026-06-24
AI Technical Summary
Existing cryptographic techniques for privacy-preserving permutation of a set of values are limited in functionality and efficiency, particularly in multi-party computation scenarios where the privacy and security of data need to be maintained.
The use of cryptographic secure multi-party computation (MPC) protocols to achieve efficient and privacy-preserving permutation of a set of values, where only a single party knows which permutation was applied, and multiple applications of this technique can result in a re-ordering that no single party or set of parties can determine.
This approach enables efficient and privacy-preserving permutation of data, reducing the risk of data breaches and ensuring compliance with privacy regulations, while maintaining the security and privacy of the data throughout the computation process.
Smart Images

Figure EP2024072197_20022025_PF_FP_ABST
Abstract
Description
[0001] PRIVACY-PRESERVING DATA PERMUTATION
[0002] FIELD OF THE INVENTION
[0003] The invention relates to cryptographic systems for applying a permutation to a set of values, using cryptographic secure multi-party computation. The invention further relates to a cryptographic devices for use in such a system; to a corresponding computer- implemented method; and to a computer-readable medium.
[0004] BACKGROUND OF THE INVENTION
[0005] There is a growing demand for privacy enhancing technologies (PETs), i.e., data processing techniques that intrinsically protect the privacy of the data they operate on. For example, with the cryptographic technique of secure multiparty computation (MPC), multiple parties can perform a computation on their joint input using a distributed cryptographic protocol, such that each party learns nothing beyond the output of computation and his own (private) input.
[0006] One reason for the growing demand for PETs is that citizens are becoming increasingly dependent on the digital information stored about them by various companies and institutions. Because of this increasing dependence, the consequences of a breach of personal data are getting increasingly severe. And due to the worldwide surge of cybercrime and nation-state-sponsored cyber espionage, the risk of a data breach has increased sharply in recent years.
[0007] Also, data-based collaborations between separate entities (like companies, hospitals, local governments) usually implies that personal data is copied between the entities, which poses the risk of uncontrolled spreading of data, in particular personal information. PETs can enable data collaboration between entities without the need for sharing the data in cleartext form.
[0008] Another factor driving demand for PETs is the emergence of legal frameworks for data protection, such as the European GDPR and the Californian CCPA legislation, and their mandatory compliance. In the context of such frameworks, PETs are valuable as technical safeguards, and typically provide concrete instantiations of abstract legal notions. An important functionality in PETs is to permute, in other words shuffle, a set of values. Apart from being relevant as a functionality per se, such permuting is also often used as a sub-protocol for larger operations, such as grouping and sorting.
[0009] It is known to privately permute a set of values by using a randomizable encryption scheme, e.g., using Paillier encryption or another homomorphic encryption scheme. One party receives encryptions of the set of values, shuffles them, and rerandomizes them, e.g., by adding an encryption of zero. If this is done by several parties, then no strict subset of this set of parties knows the shuffled order of the values. It is also known to permuting a set of values in secret-shared form, as disclosed in S. Laur et al., "Round-efficient Oblivious Database Manipulation", eprint 2011 / 429. According to this method, if a value is secret-shared such that two parties can reconstruct, then such a pair of two parties can each apply the same permutation on the data, and re-share. If this is done for example by each pair of a group of three parties, then the result is a reordering of the set of values that is not known by any individual party.
[0010] SUMMARY OF THE INVENTION
[0011] It would be desirable to provide improved cryptographic techniques for privacy-preserving permutation of a set of values, in terms of functionality and / or efficiency.
[0012] In accordance with a first aspect of the invention, a cryptographic system for performing a permutation is provided, as defined by claim 1. In accordance with further aspects of the invention, cryptographic devices for use in a cryptographic system for permutation; and cryptographic methods of performing a permutation are provided, as defined by claims 11-12 and 13-14, respectively. In accordance with an aspect of the invention, a computer-readable medium is provided, as defined by claim 15.
[0013] The techniques described herein make use of cryptographic secure multiparty computation (MPC). As is known per se, MPC is a cryptographic technique in which a computation is performed in a distributed way between multiple cryptographic devices in such a way that the inputs, intermediate values, and / or outputs of the computation remain hidden from the parties performing the computation. Such values that remain hidden from the parties may be referred to as the secret values of the MPC. In general, a secret value of the MPC may have the property that a limited number of parties, up to a given threshold, does not know the secret value. However, a number of parties that exceeds the threshold may be able to derive the secret value.
[0014] A secret value can for example be a threshold encryption, of which the decryption key is distributed among the parties; or a secret sharing, also referred to herein simply as a sharing. A sharing may be defined as a distributed representation of a value into shares of the respective parties such that a limited number of the shares, up to the given threshold, does not allow to derive the represented value. Although the term "secret share" is most commonly used for MPC techniques using so-called arithmetic secret sharing, also other MPC techniques such as garbled circuits are considered herein to operate on secret shares. In multi-party computation, through the use of secret values and of various protocols that allow to perform operations on secret values, e.g., in secret-shared or threshold encrypted form, various computations can be performed, while keeping the underlying values hidden from the parties that perform them, thus providing privacy-preserving computation. The design of efficient MPC protocols for specific operations is the topic of a significant amount of research.
[0015] The techniques herein provide efficient MPC protocols for permuting a set of values. A technique is provided to obtain a secret sharing of a permutation of the set of values, such that only a single party knows which permutation was applied. This is per se an interesting primitive; and by applying this technique multiple times, a re-ordering can be achieved that no single party, or even no set of parties smaller than a given size, knows how the values were re-ordered.
[0016] The technique may by applied by a first, second, and third cryptographic device. The first cryptographic device may obtain first secret-shares of the set of values, and the second cryptographic device may obtain second secret-shares of the set of values. For example, respective first and second secret-shares may be additive secret-sharings of the respective set of values, e.g., adding the first and second secret share of a value, possibly modulo a given modulus, may result in the value.
[0017] A permutation may be applied to the values, known to the second cryptographic device. To this end, the first device may encrypt the first secret-shares of the set of values; and send the encrypted first secret-shares to a second cryptographic device. The second device may receive the encrypted first secret-shares such that it has encrypted first secret-shares, and it also has the second secret-shares of the set of values. The second cryptographic device may apply the permutation both to the encrypted first secret shares, and to the second secret-shares. The second cryptographic device may provide the permuted encrypted first secret-shares to a third cryptographic device. The third cryptographic device may receive the permuted encrypted first secret-shares, and decrypt the encrypted first secret-shares.
[0018] As a result, the second and third cryptographic device may hold an additive sharing of a permutation of the set of values, that is only known by the second party. Such an application of a permutation known by a party may occur as a sub-protocol in various multi-party computation protocols, and can be performed efficiently and using little communication as described herein. Moreover, by letting the first or third cryptographic device apply a further permutation, a re-ordering of the set of values can be obtained that is not known by any individual device. E.g., by applying two random permutations, an overall random permutation may be applied that is not known to any party. Also this is a primitive that is useful for a wide range of applications of multi-party computation, and can be applied efficiently using the techniques described herein.
[0019] For example, the provided techniques may be applied in the context of multiparty computation on Shamir secret shares. For example, the additive shares that are permuted, may be converted from Shamir shares of the set of values, for example resulting from a previous multi-party computation operation, or from inputting by an input party. As is known per se, this can for example be done by the first and second cryptographic devices locally multiplying their shares by a Lagrange interpolation coefficient. Preferably, a rerandomization is applied prior to to the permuting, e.g., the first device subtracts random values from its shares and the second device adds the same random values. This way, the association between the shares and their values is lost and the third device cannot use this association to learn information from the encrypted shares it receives.
[0020] Similarly, after the permuting, the second and third parties can convert the permuted additive shares to permuted Shamir shares, for example, for use in a next multiparty computation operations, or for opening by a result party. For example, the parties can secret-share their respective additive shares, and the secret-shared additive shares can be added to obtain secret shares of the permuted values per se.
[0021] The encryption according to which the shares are encrypted, can be a symmetric encryption scheme. The key may be known to the first and third cryptographic device, but not the second. For example, AES can be used; this allows a particularly efficient implementation, e.g., using hardware acceleration available on modern computer chips. To decrease the size of the ciphertexts and thus reduce communication, ciphertext stealing can be used.
[0022] It will be appreciated by those skilled in the art that two or more of the above- mentioned embodiments, implementations, and / or optional aspects of the invention may be combined in any way deemed useful.
[0023] Modifications and variations of any system and / or any computer readable medium, which correspond to the described modifications and variations of a corresponding computer-implemented method, can be carried out by a person skilled in the art on the basis of the present description, and the other way round as well. BRIEF DESCRIPTION OF THE DRAWINGS
[0024] These and other aspects of the invention will be apparent from and elucidated further with reference to the embodiments described by way of example in the following description and with reference to the accompanying drawings, in which:
[0025] Fig. 1 shows a cryptographic device;
[0026] Fig. 2 shows a cryptographic system;
[0027] Fig. 3 shows a detailed example of permuting a set of values;
[0028] Fig. 4 shows a computer-implemented method;
[0029] Fig. 5 shows a computer-implemented method;
[0030] Fig. 6 shows a computer-readable medium comprising data.
[0031] It should be noted that the figures are purely diagrammatic and not drawn to scale. In the figures, elements which correspond to elements already described may have the same reference numerals.
[0032] DETAILED DESCRIPTION OF EMBODIMENTS
[0033] Fig. 1 shows a cryptographic device 100 for use in a cryptographic system as described herein, e.g., in to Fig. 3. The cryptographic system may be for performing a permutation of a set of values. The permutation may be performed in a privacy-preserving way as a cryptographic secure multi-party computation (MPC) between multiple cryptographic devices, including device 100.
[0034] The device 100 may comprise a data interface 120 for accessing data 030 representing values as private values of the MPC. For example, the number of values can be at most or at least 1000, at most or at least 10000, or at most or at least 1000000. The values can in general have various types, e.g., can be numeric data (e.g., integral, fixed- point, or floating point), textual, etc. In general, a respective value may be represented as private representations, e.g., secret-shares, of one or more elementary values of the multiparty computation system, e.g., field elements (for Shamir secret sharing); ring elements (for replicated secret sharing); bits (for garbled circuits); etc.
[0035] For example, as also illustrated in Fig. 1 , the input interface may be constituted by a data storage interface 120 which may access the data 030 from a data storage 021. For example, the data storage interface 120 may be a memory interface or a persistent storage interface, e.g., a hard disk or an SSD interface, but also a personal, local or wide area network interface such as a Bluetooth, Zigbee or Wi-Fi interface or an ethernet or fibreoptic interface. The data storage 021 may be an internal data storage of the system 100, such as a hard drive or SSD, but also an external data storage, e.g., a network- accessible data storage. The device 100 may further comprise a processor subsystem 140.
[0036] The device 100 may be for use as a first cryptographic device in the cryptographic system. In such a case, the processor subsystem 140 may be configured to obtain the first secret-shares 030 of the set of values; encrypt the first secret-shares of the set of values; and send the encrypted first secret-shares to a second cryptographic device.
[0037] The device 100 may, instead or in addition, be for use as a second cryptographic device in the cryptographic system. In such a case, the processor subsystem 140 may be configured to receive the encrypted first secret-shares; obtain second secretshares 030 of the set of values; apply a permutation to the encrypted first secret shares and to the second secret-shares; and provide the permuted encrypted first secret-shares to a third cryptographic device.
[0038] The device 100 may, instead or in addition, be for use as a third cryptographic device in the cryptographic system. In such a case, the processor subsystem 140 may be configured to receive the permuted encrypted first secret-shares, and decrypt the encrypted first secret-shares 030.
[0039] As also discussed with respect to Fig. 3, the device 100 may be further configured to provide inputs to the multi-party computation, e.g., to obtain the values 030 in plain form and input them to the multi-party computation, e.g. by secret-sharing, encrypting, or otherwise masking them. Instead or in addition, the device 100 may be further configured to obtain outputs from the multi-party computation, e.g., to obtain the permuted values, e.g., by receiving one or more secret shares and recombining the outputs from the secret shares.
[0040] The system 100 may also comprise a communication interface 180 configured for communication 126 with at least one further cryptographic device of the cryptographic system, e.g., to exchange encrypted shares. Communication interface 180 may internally communicate with processor subsystem 140 via data communication 125. Communication interface 180 may be arranged for direct communication with the other devices, e.g., using USB, IEEE 1394, or similar interfaces. As illustrated in the figure, communication interface 180 may also communicate over a computer network 099, for example, a wireless personal area network, an internet, an intranet, a LAN, a WLAN, etc. For instance, communication interface 180 may comprise a connector, e.g., a wireless connector, an Ethernet connector, a Wi-Fi, 4G or 4G antenna, a ZigBee chip, etc., as appropriate for the computer network. Communication interface 180 may be an internal communication interface, e.g., a bus, an API, a storage interface, etc.
[0041] In general, each device described in this specification, including but not limited to the system 100 of Fig. 1, may be embodied as, or in, a single device or apparatus, such as a workstation or a server. The device may be an embedded device. The device or apparatus may comprise one or more microprocessors which execute appropriate software. For example, the processor subsystem of the respective system may be embodied by a single Central Processing Unit (CPU), but also by a combination or system of such CPUs and / or other types of processing units. The software may have been 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, the processor subsystem of the respective system may be implemented in the device or apparatus in the form of programmable logic, e.g., as a Field-Programmable Gate Array (FPGA). In general, each functional unit of the respective system may be implemented in the form of a circuit. The respective system may also be implemented in a distributed manner, e.g., involving different devices or apparatuses, such as distributed local or cloud-based servers.
[0042] Fig. 2 shows a cryptographic system 010 for applying a permutation to a set of values. The permutation may be performed in a privacy-preserving way as a cryptographic secure multi-party computation between multiple cryptographic devices, e.g., as described with respect to Fig. 3. The cryptographic system 010 may in general comprise multiple input devices, multiple different cryptographic devices, and at least one result device, where the sets of input, cryptographic, and result devices may overlap with each other. As illustrated, the devices typically communicate over a computer network 099, e.g., the internet or a local network.
[0043] In particular, shown in the figure are three cryptographic devices CP1 , 201 ; CP2, 202; and CP3, 203. The cryptographic devices may be based on cryptographic device 100 of Fig. 1. The provided techniques can also be used with more cryptographic device, s e.g., five or more. The cryptographic devices CPi may be configured to perform a secure multi-party computation (also known per se as multi-party computation, secure computation, or MPC). Generally, a multi-party computation may be a distributed protocol between the cryptographic devices for performing a computation in a privacy-preserving way. Depending on the specific technique used, MPC may ensure privacy and / or correctness of the computation against an attacker that eavesdrops or controls one or more (but typically not all) of the cryptographic devices. As known per se, any computation can be performed as a multi-party computation (in other words, “under the multi-party computation”), but concrete computational and communication efficiency can in general greatly depend on how exactly the computation is performed.
[0044] In particular, the multi-party computation can be performed based on secret sharing, in particular arithmetic secret sharing such as Shamir secret sharing, replicated secret sharing, or additive secret sharing. For example, the multi-party computation can be based on the techniques described in Shamir, “How to Share a Secret”, Communications ACM, 1979; Ben-Or, Goldwasser, Wigderson, “Completeness Theorems for NonCryptographic Fault-Tolerant Distributed Computation (Extended Abstract)”, Proceedings of the 20th Annual ACM Symposium on Theory of Computing, 1988; Chaum, Crepeau, Damgaard, “Multiparty Unconditionally Secure Protocols (Extended Abstract)”, Proceedings of the 20th Annual ACM Symposium on Theory of Computing, 1988; Ito, Saito, Nishizeki, “Secret sharing scheme realizing general access structure”, Electronics and Communications in Japan (Part III: Fundamental Electronic Science), 1989; Damgaard, Pastro, Smart, Zakarias, “Multiparty Computation from Somewhat Homomorphic Encryption”, proceedings CRYPTO 2012.
[0045] Various higher-level operations such as sorting and integer comparison can be performed based on such basic multi-party computation protocols as discussed e.g. in M. Keller, "MP-SPDZ: A Versatile Framework for Multi-Party Computation", proceedings ACM CCS 2020; or as implemented in MPyC, see https: / / github.com / lschoe / mpyc.
[0046] The multi-party computation may be configured to perform operations on so called sharings, or secret shares, of values. A secret share may be a distributed representation of an input, intermediate, or output value of the MPC. A limited number of shares, up to a certain threshold T, may not allow to derive the represented value. The threshold may be configurable, with different techniques supporting different possible threshold. For example, the multi-party computation may be an honest majority MPC, where the threshold T is strictly smaller than the number of parties N, e.g., N = 2T + 1. Or, the multi-party computation can be a full-threshold MPC, where the threshold can be higher, e.g., T = N - 1. Examples of sharings are arithmetic sharing, such as Shamir secret sharing or replicated secret sharing; XOR sharing; or Yao sharing. It is stressed that the term secret sharing in this specification also includes Yao sharings, e.g., secret values of an MPC computation performed using garbled circuits, as also done in “ABY - A Framework for Efficient Mixed- Protocol Secure Two-Party Computation”. For example, the number of parties may be three, and the threshold may be one.
[0047] A value that is computed on by the MPC but that is represented among the parties in such a way that no single party, more generally no unqualified set of parties, can derive the value from that representation, is referred to as a secret value, or private value, of the MPC. A secret value can be a secret sharing, but it is also possible e.g. to use a threshold encryption. For example, a secret value can be a secret input, a secret output, or a secret intermediate value. Here, a secret input may be known in the plain by the party inputting it, and known only in a secret representation by the cryptographic devices CPi; and similarly, a secret output may be learned in the plain by the party receiving it as output, but may be known only in a secret representation by the cryptographic devices CPi. A private intermediate value may be known only to the cryptographic devices CPi, and only as a secret representation. By processing values using secret representations, the data can be kept secret, at least as long as the underlying assumptions of the multi-party computations (e.g., in terms of the number and / or type of corruptions of the cryptographic devices) are satisfied.
[0048] Also shown in the figure are a number of input devices INP1, 101; INP2, 102; up to INPk, 103. The input devices may input the values to which a permutation is performed, or data from which these keys and values are computed under MPC, e.g., by performing one or more database operations on the input under MPC.
[0049] The input devices 101-103 may use the hardware configuration discussed in Fig. 1. The number of input devices can be two, at most or at least three, or at most or at least five, for example. In many cases, the sets of inputs devices INPi and cryptographic devices CPi may wholly or partially overlap. For example, the set of input devices may be a subset or a superset of the set of cryptographic devices, or may be exactly the same.
[0050] Further shown is a result device RES. The result device RES may obtain a result of the MPC based on a computed permutation. For example, the result device RES may obtain one or more of the permuted values; or values based on this. It is also possible for multiple respective result devices to obtain multiple respective results of the multi-party computation based on the performed permutation. Although illustrated as a separate device in the figure, the result device(s) RES can be the same devices as an input device INPi and / or cryptographic device CPi. Generally, the result device may be implemented using the hardware configuration discussed with respect to Fig. 1.
[0051] Many known multi-party computation techniques are defined per se for the case where the input and result devices INPi and RES form a subset of the set of cryptographic devices CPi that perform the MPC. To use such techniques in a setting where an input and / or result device does not perform the MPC itself, an input device can for example determine a secret representation, e.g., a secret sharing, and distribute it among the computation devices. Similarly, a result device can for example receive a secret representation, e.g., respective secret shares, of an output from the computation devices and derive the output from the secret representation. It is also possible to use specific techniques for letting an external party provide inputs to and / or obtain outputs from a multiparty computation. For example, the techniques from the following reference can be used: T. P. Jakobsen, J. B. Nielsen, and C. Orlandi. “A framework for outsourcing of secure computation”, proceedings CCSW’14. Fig. 3 shows a detailed, yet non-limiting, example of applying a permutation to a set of values. For example, this example can be based on the example of Fig. 2. By way of illustration, a permutation of two values v1, v2 is shown, where the permutation swaps the two values.
[0052] The figure shows three cryptographic devices P1, 321; P2, 322; P3, 323, e.g., corresponding to the three cryptographic devices CPi of Fig. 2.
[0053] Initially, parties P1 and P2 may hold an additive sharing of the set of values. For example, party P1 may hold [v1]i,[v2]i , 341 and party P2 may hold [v1]2,[v2]2, 342. For example v1=[v1]i+[v1]2and V2=[V2]I+[V2]2, e.g., modulo a power of two such as 2A32 or 2A64, or modulo a prime number.
[0054] While not shown in the figure, the parties may obtain the additive shares from Shamir shares. As known per se for Shamir sharing, the parties P1, P2 can do this by multiplying the shares by the respective Lagrange coefficients for Shamir reconstruction.
[0055] The figure shows a re-randomization operation Reran, 370, in which parties P1 , P2 re-randomize their shares to obtain randomized shares [v1]i',[v2]i', 343 and [v1]2',[v2]2'. The randomized shares may again add up to the original values. The rerandomization may be performed by one party adding respective random numbers and the other party subtracting the respective random numbers; e.g., to limit communication, both parties may derive the random numbers from a seed to a cryptographic pseudo-random number generator.
[0056] The figure further shows party P1 encrypting its (in this case, re-randomize) respective shares to obtain encryptions E([v1]i’),E([v2]i’), 351 , and sending the shares in encrypted form to party P2. For example, an AES encryption can be used, optionally with ciphertext stealing to limit the size of the ciphertexts, e.g., if the shares are smaller than 128 bytes.
[0057] The figure further illustrates that party P2 may permute the received encrypted additive shares 351, as well as its own shares, e.g., re-randomized shares 344.
[0058] The permutation may be according to a randomly generated permutation, or to another permutation chosen by party P2, for example. The same permutation may however be applied to both sets of shares. In this example, the permutation constitutes a swapping of the two values, but it will be understood that any permutation may be applied; for example, the permutation may or or not be the identity permutation; and may or may not be a rotation of the values.
[0059] By permuting, party P2 may obtain permuted second secret-shares [v2]2’,[v1]2’, 361. Party P2 may send the permuted encryptions E([v2]i’),E([v1]i’), 352, to party P3, who may decrypt the permuted encryptions to obtain permutations [v2]i’,[v1 ] , 362, of the first secret shares. Interestingly, respective shares 361, 362 may represent an additive sharing of the same set of values as shares 341 , 342, but without party P1 or P3 knowing which permutation was applied to the set of values.
[0060] While not shown in the figure, the additive shares 361 , 362, can be converted to another type of sharing, such as a Shamir sharing, e.g. by parties P2, P3, inputting their shares to the multi-party computation, e.g., Shamir sharing the values, and adding the inputs to each other under the multi-party computation.
[0061] By repeating the encrypting, permuting, and decrypting, a permutation of the input values may be obtained such that no individual party Pi knows the permutation.
[0062] For example, party P3 may perform the further permutation. In this case, party P2 may encrypt its shares 361 (preferably, after a further re-randomization) and provide them to party P3. This can be done together with the sending of encrypted shares 352 to reduce round complexity.
[0063] Party P3 may permute these encrypted shares as well as its own shares 362 (preferably re-randomized with shares 361), and send the encrypted shares to P1 for decryption. This way, an additive sharing between P1 and P3 may be obtained of a permutation of the input values, such that no party Pi knows the permutation.
[0064] It is however also possible that party P1 performs the further permutation. In this case, for example, party P2 may provide shares 361 to party P1 and party P3 may provide an encryption of shares 362 to party P1 (preferably, after a re-randomization), or the other way round. Party P1 may permute both the shares and the encryptions, and send the encryptions to the party that did not send them.
[0065] Accordingly, an efficient technique is obtained for permuting values according to a secret permutation. The round complexity is relatively low, e.g., only three rounds of communication may suffice for three parties, and also the amount of communication is relatively low, e.g., approximately four times the original dataset.
[0066] Fig. 4 shows a block-diagram of a cryptographic method 900 of applying a permutation to a set of values. The permutation may be applied in a privacy-preserving way as a cryptographic secure multi-party computation between multiple cryptographic devices. Method 900 may be carried out by a cryptographic device, e.g., device 100 of Fig. 1. However, this is not a limitation, in that the method 900 may also be performed using another system, apparatus or device. The method 900 may further comprise the other cryptographic devices carrying out the secure multi-party computation. For example, the method 900 may be carried out by a cryptographic system, e.g., cryptographic system 010 of Fig. 3. The method 900 may be computer-implemented.
[0067] The method 900 may comprise, in an operation titled "RE-RANDOMIZE", with a further cryptographic device, performing 920 a re-randomization on secret-shares of a set of values. The method 900 may comprise, in an operation titled "RECEIVE", prior to the rerandomization, receiving 910 the secret shares in encrypted form from the further cryptographic device and decrypt the encrypted secret shares. As an alternative, in an operation titled "ENCRYPT" carried out after the re-randomization, the method may comprise encrypting 930 the secret shares and send the encrypted secret shares to the further cryptographic device.
[0068] Fig. 5 shows a block-diagram of a cryptographic method 1000 of applying a permutation to a set of values. The permutation may be applied in a privacy-preserving way as a cryptographic secure multi-party computation between multiple cryptographic devices. Method 1000 may be carried out by a cryptographic device, e.g., device 100 of Fig. 1. However, this is not a limitation, in that the method 1000 may also be performed using another system, apparatus or device. The method 1000 may further comprise the other cryptographic devices carrying out the secure multi-party computation. For example, the method 1000 may be carried out by a cryptographic system, e.g., cryptographic system 010 of Fig. 3. The method 1000 may be computer-implemented.
[0069] The method 1000 may comprise, in an operation titled "OBTAIN ENCRYPTION", obtaining 1010 encrypted first secret-shares of the set of values.
[0070] The method 1000 may comprise, in an operation titled "OBTAIN SHARE", obtaining 1020 second secret-shares of the set of values.
[0071] The method 1000 may comprise, in an operation titled "PERMUTE", applying 1030 a permutation to the encrypted first secret shares and to the second secret-shares.
[0072] The method 1000 may comprise, in an operation titled "OUTPUT", outputting 1040 the permuted encrypted first secret-shares.
[0073] It will be appreciated that, in general, the operations of method 900 of Fig. 4 and / or method 1000 of Fig. 5 may be performed in any suitable order, e.g., consecutively, simultaneously, or a combination thereof, subject to, where applicable, a particular order being necessitated, e.g., by input / output relations. The methods can be combined; e.g. the combined method may be performed by a cryptographic system in which respective cryptographic devices carry out the respective methods 900, 1000. The method(s) may be implemented on a computer as a computer implemented method, as dedicated hardware, or as a combination of both. As also illustrated in Fig. 11, instructions for the computer, e.g., executable code, may be stored on a computer readable medium 1100, e.g., in the form of a series 1110 of machine-readable physical marks and / or as a series of elements having different electrical, e.g., magnetic, or optical properties or values. The medium 1100 may be transitory or non-transitory. Examples of computer readable mediums include memory devices, optical storage devices, integrated circuits, servers, on-line software, etc. Fig. 11 shows an optical disc 1100.
[0074] The instructions may be instructions for one or more particular devices of the cryptographic system. In particular, the instructions may comprise instructions for a cryptographic device to perform a permutation as described herein.
[0075] Examples, embodiments or optional features, whether indicated as nonlimiting or not, are not to be understood as limiting the invention as claimed.
[0076] It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. Use of the verb "comprise" and its conjugations does not exclude the presence of elements or stages other than those stated in a claim. The article "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. Expressions such as “at least one of” when preceding a list or group of elements represent a selection of all or of any subset of elements from the list or group. For example, the expression, “at least one of A, B, and C” should be understood as including only A, only B, only C, both A and B, both A and C, both B and C, or all of A, B, and C. The invention may be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In the device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.
Claims
CLAIMS1 . A cryptographic system (010) for applying a permutation to a set of values, wherein the permutation is applied in a privacy-preserving way as a cryptographic secure multi-party computation between multiple cryptographic devices (200, 201-203), wherein a first cryptographic device (201) is configured to: obtain first secret-shares of the set of values; encrypt the first secret-shares of the set of values; and send the encrypted first secret-shares to a second cryptographic device; wherein the second cryptographic device (202) is configured to: receive the encrypted first secret-shares, and obtain second secret-shares of the set of values; apply a permutation to the encrypted first secret shares and to the second secret-shares; and provide the permuted encrypted first secret-shares to a third cryptographic device; wherein the third cryptographic device (203) is configured to: receive the permuted encrypted first secret-shares, and decrypt the encrypted first secret-shares.
2. The cryptographic system (010) of claim 1, wherein the first secret-shares and the second secret-shares form an additive secret-sharing.
3. The cryptographic system (010) of claim 2, wherein the first and second cryptographic device are configured to obtain Shamir shares of the set of values and convert the Shamir shares to the additive secret shares.
4. The cryptographic system (010) of claim 2 or 3, wherein the second and third cryptographic device are configured to convert the permuted additive shares to permuted Shamir shares.
5. The cryptographic system (010) of any preceding claim, wherein the first and second cryptographic device are configured to re-randomize the secret sharing of the set of values prior to the applying of the permutation.RECTIFIED SHEET (RULE 91) ISA / EP6. The cryptographic system (010) of any preceding claim, wherein the first or third cryptographic device is configured to apply a further permutation to permuted secret shares of the set of values and to permuted encryptions of secret shares of the set of values.
7. The cryptographic system (010) of any preceding claim, wherein the first, second, and third cryptographic devices are different.
8. The cryptographic system (010) of any preceding claim, wherein the encryption is according to a symmetric encryption scheme, preferably AES.
9. The cryptographic system (010) of any preceding claim, wherein the encryption uses ciphertext stealing.
10. The cryptographic system (010) of any preceding claim, wherein the second cryptographic device is configured to randomly generate the permutation.
11. A cryptographic device (100, 200, 321 , 323) for use in the system according to any one of claims 1-10, wherein the cryptographic device is for applying a permutation to a set of values, wherein the permutation is applied in a privacy-preserving way as a cryptographic secure multi-party computation between multiple cryptographic devices (100, 200, 321-323), wherein the cryptographic device comprises: a communication interface (280) configured for communication with a further cryptographic device (322) of the cryptographic system; a processor subsystem (240) configured to: with the further cryptographic device, perform a re-randomization on secret-shares of a set of values, and prior to the re-randomization, receive the secret shares in encrypted form from the further cryptographic device and decrypt the encrypted secret-shares, or, after the re-randomization, encrypt the secret shares and send the encrypted secret shares to the further cryptographic device.
12. A cryptographic device (100, 200, 322) for use in the system according to any one of claims 1-10, wherein the cryptographic device is for applying a permutation to a set of values, wherein the permutation is applied in a privacy-preserving way as a cryptographic secure multi-party computation between multiple cryptographic devices (100, 200, 321-323), wherein the cryptographic device comprises:RECTIFIED SHEET (RULE 91) ISA / EPa communication interface (280) configured for communication with at least a first and second further cryptographic device (321, 323) of the cryptographic system; a processor subsystem (240) configured to: receive, from the first further cryptographic device (321), encrypted first secret-shares of the set of values; obtain second secret-shares of the set of values; apply a permutation to the encrypted first secret shares and to the second secret-shares; send the permuted encrypted first secret-shares to the second further cryptographic device (323).
13. A cryptographic method (900) of applying a permutation to a set of values, wherein the permutation is applied in a privacy-preserving way as a cryptographic secure multi-party computation between multiple cryptographic devices, wherein the method comprises: with a further cryptographic device, performing (920) a re-randomization on secret-shares of a set of values; and prior to the re-randomization, receiving (910) the secret shares in encrypted form from the further cryptographic device and decrypt the encrypted secret shares; or, after the re-randomization, encrypting (930) the secret shares and send the encrypted secret shares to the further cryptographic device.
14. A cryptographic method (1000) of applying a permutation to a set of values, wherein the permutation is applied in a privacy-preserving way as a cryptographic secure multi-party computation between multiple cryptographic devices, wherein the method comprises: obtaining (1010) encrypted first secret-shares of the set of values; obtaining (1020) second secret-shares of the set of values; applying (1030) a permutation to the encrypted first secret shares and to the second secret-shares; and outputting (1040) the permuted encrypted first secret-shares.
15. A transitory or non-transitory computer-readable medium (1100) comprising data (1110) representing instructions which, when executed by a processor system, cause the processor system to perform the cryptographic method of claim 14.RECTIFIED SHEET (RULE 91) ISA / EP