I think you don't know how the indention actually works in Python. The only indention requirement is blocks must be indented to be recognized as such.
So you can indent a block with 1, 2,... spaces or TABs. You can even mix and match as you choose, and you can change your mind from one block to another.
The following code runs fine:
if 10 < 20: print "Hello" else: print "Goodbye"
Here the "then" branch of the if-statement is indented with a single TAB character (that might not survice in the comment, but it was a TAB in the file I tested with). The "else" branch is indented with three spaces.
All in all there is *nothing* to worry about with indention in Python -- you only have to be consistent within a single block and you really hope you would do that anyway:-)
I can not explain to you how a comparison is done without leaking information (that is pretty involved), but I can understand the much simpler operation of addition.
Imagine three millionaires in a room who wants to compute the sum of their incomes. Let us say that the millionaires can agree in advance that the sum can be represented by an integer in the range 0..100. They just need some upper limit, so the number could denote billions, trillions or whatever. Each millionaire then chooses three numbers a random from the interval 0..100 with the only condition that they sum up to the millionaires own income. The sum must be calculated modulo 100, which simply means that the numbers wrap around when they reach 100. So 75 + 50 = 25 and so on.
If the three millionaires are worth M1, M2, and M3, respectively, then the first millionaire chooses numbers r11 + r12 + r13 = M1, the second chooses r21 + r22 + r23 = M2, and so on. This is a simple secret sharing which hides M1, M2, M3 perfectly. Seeing any two shares (the random numbers) reveal nothing about the target value because depending on the third share, the target could be anything.
They send their first number to the first millionaire, the second number to the second millionaire and so on. These numbers are send securely. Each millionaire now has three shares: the first millionaire has r11, r21, and r31, and likewise for the other two millionaires.
If each millionaire adds their shares, they end up with shares of the correct sum! So the first millionaire computes s1 = r11 + r21 + r31, the second computes s2 = r12 + r22 + r32, and so on. They then publish these shares and now they can all compute the correct sum S:
Voila!:-) In this computation no information was leaked at any point, and yet the three parties were able to correctly calculate the sum.
The secret sharing scheme used here is a simple one that requires the cooperation of all involved partie There also exists threshold schemes in which only a subset of the parties is needed to open a shared secret. Shamir's scheme is most famous and relies on the simple fact that you need two points on a straight line to determine it. So encode your secret s as the point (0, s) and pick a random straight line that goes through (0, s). Then hand out other points on the line to the other players. As long as each player only knows his own point, he cannot determine the y-axis intersection (the secret), but when any two players get together, then they can easily determine the secret. This scheme generalizes naturally to polynomials of higher degrees, which require more players to get together to reconstruct the secret.
You are talking about the SIMAP project which I am part of. SIMAP is short for Secure Information Management and Processing, see http://simap.dk/ (Danish only). An English article will soon be up on Eprint.
The Danish government that was not involved in the auction -- it was an auction where sugar beet farmers traded their production quotas for producing beets for Danisco, the only company producing sugar in Denmark.
The auction finished last month and was a great success for all involved parties. It was possible to run the auction because of modern protocols that require only a logarithmic number of rounds (by "round" I mean a network round-trip). The logarithm is in the bit-length of the input numbers, so for 32-bit inputs you will need ~5 rounds. The auction used the comparison by Tomas Toft, available in his PhD Progres Report: http://www.daimi.au.dk/~tomas/publications/progress.pdf
The SIMAP code is not (yet) online -- instead I can point you to a library for multi-party computation made by myself: http://viff.dk/. VIFF implements the same comparison protocol that was used in the SIMAP auction, as well as other primitives allowing you to do general MPC. VIFF is written in Python and is available under the GPL.
Slashdot Mirror
I think you don't know how the indention actually works in Python. The only indention requirement is blocks must be indented to be recognized as such.
... spaces or TABs. You can even mix and match as you choose, and you can change your mind from one block to another.
:-)
So you can indent a block with 1, 2,
The following code runs fine:
if 10 < 20:
print "Hello"
else:
print "Goodbye"
Here the "then" branch of the if-statement is indented with a single TAB character (that might not survice in the comment, but it was a TAB in the file I tested with). The "else" branch is indented with three spaces.
All in all there is *nothing* to worry about with indention in Python -- you only have to be consistent within a single block and you really hope you would do that anyway
I can not explain to you how a comparison is done without leaking information (that is pretty involved), but I can understand the much simpler operation of addition.
:-) In this computation no information was leaked at any point, and yet the three parties were able to correctly calculate the sum.
Imagine three millionaires in a room who wants to compute the sum of their incomes. Let us say that the millionaires can agree in advance that the sum can be represented by an integer in the range 0..100. They just need some upper limit, so the number could denote billions, trillions or whatever. Each millionaire then chooses three numbers a random from the interval 0..100 with the only condition that they sum up to the millionaires own income. The sum must be calculated modulo 100, which simply means that the numbers wrap around when they reach 100. So 75 + 50 = 25 and so on.
If the three millionaires are worth M1, M2, and M3, respectively, then the first millionaire chooses numbers r11 + r12 + r13 = M1, the second chooses r21 + r22 + r23 = M2, and so on. This is a simple secret sharing which hides M1, M2, M3 perfectly. Seeing any two shares (the random numbers) reveal nothing about the target value because depending on the third share, the target could be anything.
They send their first number to the first millionaire, the second number to the second millionaire and so on. These numbers are send securely. Each millionaire now has three shares: the first millionaire has r11, r21, and r31, and likewise for the other two millionaires.
If each millionaire adds their shares, they end up with shares of the correct sum! So the first millionaire computes s1 = r11 + r21 + r31, the second computes s2 = r12 + r22 + r32, and so on. They then publish these shares and now they can all compute the correct sum S:
S = s1 + s2 + s3
= (r11 + r21 + r31) + (r12 + r22 + r32) + (r13 + r23 + r33)
= (r11 + r12 + r13) + (r21 + r22 + r23) + (r31 + r32 + r33)
= M1 + M2 + M3
Voila!
The secret sharing scheme used here is a simple one that requires the cooperation of all involved partie There also exists threshold schemes in which only a subset of the parties is needed to open a shared secret. Shamir's scheme is most famous and relies on the simple fact that you need two points on a straight line to determine it. So encode your secret s as the point (0, s) and pick a random straight line that goes through (0, s). Then hand out other points on the line to the other players. As long as each player only knows his own point, he cannot determine the y-axis intersection (the secret), but when any two players get together, then they can easily determine the secret. This scheme generalizes naturally to polynomials of higher degrees, which require more players to get together to reconstruct the secret.
If you can read Python, then you might be interested in my Python code here: http://viff.dk/api/viff.shamir-pysrc.html. This code is part of a larger project for MPC called VIFF, see http://viff.dk/
You are talking about the SIMAP project which I am part of. SIMAP is short for Secure Information Management and Processing, see http://simap.dk/ (Danish only). An English article will soon be up on Eprint.
The Danish government that was not involved in the auction -- it was an auction where sugar beet farmers traded their production quotas for producing beets for Danisco, the only company producing sugar in Denmark.
The auction finished last month and was a great success for all involved parties. It was possible to run the auction because of modern protocols that require only a logarithmic number of rounds (by "round" I mean a network round-trip). The logarithm is in the bit-length of the input numbers, so for 32-bit inputs you will need ~5 rounds. The auction used the comparison by Tomas Toft, available in his PhD Progres Report: http://www.daimi.au.dk/~tomas/publications/progress.pdf
The SIMAP code is not (yet) online -- instead I can point you to a library for multi-party computation made by myself: http://viff.dk/. VIFF implements the same comparison protocol that was used in the SIMAP auction, as well as other primitives allowing you to do general MPC. VIFF is written in Python and is available under the GPL.