question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

How does secret sharing work with one source

See original GitHub issue

Hello in the following example, x is encrypted though we have only one source. How is that possible, don’t we need at least two sources? else how does it work?

x = torch.tensor([1.0, 2.0, 3.0])

x_enc = crypten.cryptensor(x)

thank you in advance

Issue Analytics

  • State:closed
  • Created 3 years ago
  • Comments:6 (4 by maintainers)

github_iconTop GitHub Comments

2reactions
gmurarucommented, Nov 4, 2020

Hello! This is an answer based on my understanding of how CrypTen works! - someone from the CrypTen team can correct me if I am wrong 😄

More than 1 Party In the usual scenario, you should have more than 1 party in a SMPC. CrypTen is using PRZS (Pseudo Random Zero Share) when sharing a value. For doing this, each “party” holds 2 generators and one of them is “shared” with the previous party.

party_1

Then the parties generate shares (one of the shares is not, hmm…let’s say “final”, you will see down below why I say that) using those two generators. party_2

Where: exp As you can see the shares would have the sum 0 (hence the name Pseudo-Random Zero Share) Now, the party that shares the secret, adds this value to its personal share. When you combine the shares (the reconstruction of the initial data) - you will get back the secret.

1 Party In the case there is only one party: sg_share

The constructed share would be simply: 0 + secret. ^^ The zero value is because you have the same “generator” (more exactly you initialized the 2 generators using the same seed). The “next party”, from which we should have gotten one of the seeds is “party 1” (so we get the exact same seed ==> the generators would generate the same series of random numbers) You need to take into consideration that the secret, is “transformed” using a FixedPointEncoder.

CrypTen uses as default precision 16 bits --> which gives us a constant of 2^16 that would play the role of a scale.

Example Let’s say you have:

x = torch.tensor([1.0, 2.0, 3.0])
x_enc = crypten.cryptensor(x)

With the generators, we created a “zero value” that we add with the fixed-point representation of our tensor. It would simply result in a single share that is exactly our fixed-point number: x_enc = [1.0 * 2^16, 2.0 * 2^16, 3.0 * 2^16] (where 2^16 is the scale).

So you should get back: [65536, 131072, 196608]

TL;DR: You get back only the fixed-point representation of that tensor.

0reactions
louislouislouislouiscommented, Jun 15, 2022

Hello! This is an answer based on my understanding of how CrypTen works! - someone from the CrypTen team can correct me if I am wrong 😄

More than 1 Party In the usual scenario, you should have more than 1 party in a SMPC. CrypTen is using PRZS (Pseudo Random Zero Share) when sharing a value. For doing this, each “party” holds 2 generators and one of them is “shared” with the previous party.

party_1

Then the parties generate shares (one of the shares is not, hmm…let’s say “final”, you will see down below why I say that) using those two generators. party_2

Where: exp As you can see the shares would have the sum 0 (hence the name Pseudo-Random Zero Share) Now, the party that shares the secret, adds this value to its personal share. When you combine the shares (the reconstruction of the initial data) - you will get back the secret.

1 Party In the case there is only one party: sg_share

The constructed share would be simply: 0 + secret. ^^ The zero value is because you have the same “generator” (more exactly you initialized the 2 generators using the same seed). The “next party”, from which we should have gotten one of the seeds is “party 1” (so we get the exact same seed ==> the generators would generate the same series of random numbers) You need to take into consideration that the secret, is “transformed” using a FixedPointEncoder.

CrypTen uses as default precision 16 bits --> which gives us a constant of 2^16 that would play the role of a scale.

Example Let’s say you have:

x = torch.tensor([1.0, 2.0, 3.0])
x_enc = crypten.cryptensor(x)

With the generators, we created a “zero value” that we add with the fixed-point representation of our tensor. It would simply result in a single share that is exactly our fixed-point number: x_enc = [1.0 * 2^16, 2.0 * 2^16, 3.0 * 2^16] (where 2^16 is the scale).

So you should get back: [65536, 131072, 196608]

TL;DR: You get back only the fixed-point representation of that tensor.

@gmuraru When generating Share1, Share2 and Share3, what is the function next, involved in next(G1),next(G2) and next(G3). Is the next function a this function a PRF, like HMAC?

Read more comments on GitHub >

github_iconTop Results From Across the Web

Secret sharing - Wikipedia
In one type of secret sharing scheme there is one dealer and n players. The dealer gives a share of the secret to...
Read more >
Secret Sharing, Part 1 - Cryptography and Machine Learning
More generally, this scheme is known as additive sharing and works for any N number of shares by picking T = N -...
Read more >
3 Secret Sharing - Oregon State University
The goal of secret sharing is for all authorized sets of users/shares to be able to reconstruct the secret, while all unauthorized sets...
Read more >
How to Share and Own a Secret - Cryptology ePrint Archive
1. Prepositioned shared secret schemes in which the holders of the private pieces of information are unable to recover the secret information, even...
Read more >
High-Volume Secret Sharing. and an open source Rust library
More generally, the scheme works for any N shares by picking N - 1 random values and offers privacy as long as at...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found