Problem description
I am interested in a solution to the following problem:
There is some secret information that
a group of n people would like to
lock away until some minimum number
1<=m<=n of them agrees to release it. For example, say, the names of all
participants in the group.
How can we encrypt this information
and distribute n 'keys' to it so
that the information remains private
forever, unless at some point at least
m submit their keys to unlock the information?
Constraints
It is crucial that for any k<m (even m-1), there should be an extremely low probability of successfully retrieving the information with only k keys. Equally crucially, for any k>=m, the probability of success should be extremely high.
And optimally (but not necessarily), I would like a solution that has these properties:
is functionally scalable (solves problem for any m,*n*).
is speed/memory scalable (takes a reasonable amount of time to encrypt/decrypt).
Initially, I thought that a good solution might involve simply encrypting the information and giving away the (private) key in pieces, but I can't figure out a good way to split up the key.
In particular, the problem seems to get harder when both m and n become really large, since the line between having and not having >=m willing group member becomes thinner and thinner (so to speak).
If you know a solution, a nudge in the right direction would be preferable to a complete answer.
For key splitting, look up Shamir's Secret Sharing. This is a classical method (published in 1979).
You could use the XOR based splitting, here is how it works:
You provide the required number of pieces - n, and the secret key – K. To generate n pieces of your key, you need to create (n – 1) random numbers: R1, R2, R3, . . . , Rn−1. For that you can use a SecureRandom number generator, which will prevent us from duplicates.Then you operate XOR function on these Rn-1 pieces and your key - K:
Rn = R1 ⊕ R2 ⊕ R3 ⊕ . . . ⊕ Rn−1 ⊕ K
Now you have your n pieces: R1, R2, R3, …, Rn-1, Rn and you may destroy the K. Those pieces can be spread in your code or sent to users.
To reassemble the key, we use XOR operation on our Rn pieces:
K = R1 ⊕ R2 ⊕ R3 ⊕ . . . ⊕ Rn−1 ⊕ Rn
With the XOR function (⊕) each piece is inherently important in the reconstruction of the key, if any bits in any of the pieces are changed, then the key is not recoverable.
For more Info you can take a look at the Android Utility I wrote for that purpose:
GitHub Project: https://github.com/aivarsda/Secret-Key-Split-Util
Also you can try the Secret Key Splitter demo app which uses that Utility :
GooglePlay: https://play.google.com/store/apps/details?id=com.aivarsda.keysplitter
Related
N is p*q while totient(N) is a product of (p-1)(q-1) and (P-1),(Q-1) will not be prime after taken 1 from them. For an example N is 51. 51 = p*q while Totient(N) is a product of pq -p -q + 1. So the totient(N) = 51-p-q+1. What should I do after this? How to get p,q from N value (RSA)?
The only analytic (non-implementation) way of obtaining p,q from n is to factor n. For a toy value like 51, this is easy; just try possible values of p until you find p=3 q=17 (or swap to p=17 q=3 if you like). For the sizes of n used in practice -- until a few years ago usually 1024 bits which is about 308 decimal digits, now at least 2048 bits (616 digits) and sometimes more -- there is no known way to factor in less than thousands of years, and that is why RSA is considered generically secure, because knowing p,q enables you to trivially recover the private exponent and decrypt and/or forge data.
Particular implementations sometimes choose the RSA primes badly when generating keys, or leak information about them through side channels, or leak information about the resulting private exponent (d). These attacks are specific to an implementation, and depend on a lot of details and a much higher level of knowledge than exhibited in your question. Knowing d plus the public key allows you to compute p,q; this has been asked and answered many times on other stacks which I'll dig up later. Note that your question is really about the mathematics behind RSA not any program code or language(s), although if there were a method it could well be embodied in code, so it is less suitable here and would be more suitable (but trivial or duplicate) on https://crypto.stackexchange.com or https://security.stackexchange.com .
It is believed that if and when research into quantum computers is successful they will be vastly more efficient at factoring, enough to make RSA insecure. If and when this happens you can expect to see it on every news channel and site in the world.
I'm not learning cryptography yet, and this exercise - in the form it was delivered as a homework, was more of an exercise on reading composite functions and the like. Either way, I took a look at some part of the source code and didn't understand this.
For RSA encryption, the source code manipulated the string in such a way:
Message is being hashed into an integer list. (int1, int2, int3...)
Encrypt int1
Subtract result from int2 ( int2 - e(int1))
Modulo with the modulo key (n)
RSA transform with a key.
However, the RSA decryption method is done by:
1) RSA_transform
2) Result is added
3) Modulo with n
The part that puzzles me about the RSA decryption is the need for modulo after the adding and rsa_transform. If it's needed, shouldnt it be used in reverse order of how the chain of operations was carried out in RSA encryption?
Also, an "invert_modulo" was provided in the source code. I originally believed this to be a key in decrypting the message, but it wasn't so. What could "invert_modulo" be used for?
I cannot understand the first part of your question as the steps to hash the string is not clear also i don't get 3rd part of your encryption step. As for the Second question invert_modulo is the "MODULAR MULTIPLICATIVE INVERSE".
While working with modular airthmetic we always want our answer to be in the integer range 0 to M-1(where M is the number we modulo with) simple operations like addition , multiplication and subtraction are easy to perform : like (a+b) MOD M, it is well defined for the constraints of modular airthmetic.
Problem arises wen we try to divide : (a/b) MOD M
as you can see here a/b may not always always give an integer, therefore (a/b) does not lie in the integer range 0 to M-1. so to overcome this we try to find an inverse of b that we would rather multiply a with, i.e : (a*b_inverse) MOD M.
b_inverse can be defined as : (b*b_inverse) MOD M = 1.
i.e b_inverse is a number in the range 0 to M-1, which when multiplied with b, modulo M yields 1.
Note : also note that modular inverse of some numbers might not exist we can check that by taking the GCD of M and the number concerned(in our example "b") if GCD is not equal to 1 the the modular inverse does not exist.
I am working on some security stuff and am trying to implement a basic form of RSA encryption. I am working with Maple to compute some values, but I am struggle with being able to compute this:
These are the values I have: e, p, q
I need to compute which value for 'd' will work in the following equation:
d*e ≡ 1 mod (p-1)*(q-1)
Notation note: If a - b is a multiple of the number c, we write "a ≡ b mod c".
I was told I could use some sort of Power(a,b) mod c functionality in Maple, but I am not sure how to do it. Shed any light on how I can calculate the a value for 'd' in Maple? In my case, e = 65537, and both p and q are really large prime numbers (100+ digits each).
It's as simple as d:= 1/e mod (p-1)*(q-1);
You need the gcdex function, compute s and t such that s*e + t*(p-1)*(q-1) = 1 and use d=s.
I feel bad not pointing this out: If this has anything at all to do with actual security (as opposed to learning about the theory), do not write your own code without spending a lot of time reading about attacks on implementations (as opposed to the math). RSA is very simple (and beautiful) mathematically, but surprisingly tricky to implement securely.
Note that there is a special StackExchange site for security, which you may be interested in.
I have a table with an auto-increment 32-bit integer primary key in a database, which will produce numbers ranging 1-4294967295.
I would like to keep the convenience of an auto-generated primary key, while having my numbers on the front-end of an application look like randomly generated.
Is there a mathematical function which would allow a two-way, one-to-one transformation between an integer and another?
For example a function would take a number, and translate it to another:
1 => 1538645623
2 => 2043145593
3 => 393439399
And another function the way back:
1538645623 => 1
2043145593 => 2
393439399 => 3
I'm not necessarily looking for an implementation here, but rather a hint on what I suppose, must be a well-known mathematical problem somewhere :)
Mathematically this is almost exactly the same problem as cryptography.
You: I want to go from an id(string of bits) to another number (string of bits) and back again in a non-obvious way.
Cryptography: I want to go from plaintext (string of bits) to another string of bits and back again (reversible) in a non-obvious way.
So for a simple solution, can I suggest just plugging in whatever cryptography algorithm is most convenient in your language, and encrypt and decrypt your id?
If you wanted to be a bit cleverer you can do what is called "salting" in addition to cryptography. Take your id as a 32 bit (or whatever) number. Concatenate it with a random 32 bit number. Encrypt the result. To reverse, just decrypt, and throw away the random part.
Of course, if someone was seriously attacking this, this might be vulnerable to known plaintext/differential cryptanalysis attacks as you have a very small known plaintext space, but it sounds like you aren't trying to defend against serious attacks.
First remove the offset of 1, so you get numbers in the range 0 to 232-2. Let m = 232-1.
Choose some a that is relative prime to m. Since it is relatively prime it has an inverse a' so that a * a' = 1 (mod m). Also choose some b. Choose big numbers to get a good mixing effect.
Then you can compute your desired pseudo-random number by y = (a * x + b) % m, and get back the original by x = ((y - b) * a') % m.
This is essentially one step of a linear congruential generator (LCG) for pseudo-random numbers.
Note that this is not secure, it is only obfuscation. For example, if a user can get two numbers in sequence then he can recover a and b easily.
In most cases web apps use a hash of a randomly generated number as a reference to a table row. This hash can be stored as a number and displayed as a string for the end user.
This hash is unique and it is identifier and the id is only used in the application itself, never shown to the outside world.
Is possible to calculate average of three encrypted integer? No constrain on the method of encrypting. The point of this is just to hide the three numbers and find average.
What you seem to be looking for is called Homomorphic Encryption: an encryption scheme which allows you to perform operations on encrypted data, with the encrypted result as the outcome.
Such a scheme would allow you to give encrypted data to a 3rd party, which could then do computations on it for you without knowing what they were computing.
In your case, you need two operations: addition and division. Until recently, homomorphic encryption schemes typically supported only 1 operation. But in september 2009 IMB announced the first fully homomorphic cryptosystem. Other researches published another system soon after that.
These cryptosystems might be be able to do what you want, but it is all cutting edge computer science research.
Decrypt the numbers, then calculate their average.
I don't see any simple ways to do what you ask, apart from decrypting the numbers first.
Taking the average (or the "arithmetic mean") requires adding the numbers. Now if you wanted to multiply the numbers, then you could do that neatly with RSA encryption. If p is the plaintext, c is the ciphertext, and e is the encryption key, then in RSA, c = p^e. If you have 3 separate integers, p1, p2, p3, and the product is pp then
pp^e = (p1 * p2 * p3)^e = p1^e * p2^e * p3^3 = c1 * c2 * c3 = cp
That is, you can either multiply the three plaintext integers together and then encrypt, or you can just multiply the three ciphertexts together, and get the same answer. This would get you some way towards the "geometric mean", where you multiply all the numbers together, and then take the cube-root (or nth root for n numbers). Unfortunately, calculating a cube root in modular arithmetic is non-trivial.
With ideal encryption methods: No.
With most real-world encryption methods: No.
With some stupidly simple to undo obfuscation method especially designed to allow averaging: Yes.
Calling the latter method "encryption" really would be using the wrong term.
If you could calculate the average of encrypted numbers without decrypting them, that would make decrypting the original numbers quite a lot easier, so I would be very surprised if this works with any serious encryption algorithm.
In general three encrypted numbers shouldn't maintain the same order if encrypted, so I'm pretty sure you have to decrypt them and calculate the avarage.
If, and only if, the method of encryption is a one-to-one mathematical function, then it is possible to do so while the numbers are encrypted.
For example, if my very unsecure method of encryption is to multiply every number of 2, then I would do the following:
function encrypt($number){
return $number*2;
}
$a=encrypt(3); // a= 9
$b=encrypt(5); // b= 15
$c=encrypt(6); // c= 18
$average = ($a+$b+$c)/6; // We divide by 6 because first we divide by 3 to get the average, then by 2 to do the decryption. The method will vary based on the mathematical function.
The only other possibility is to decrypt the numbers first.