I'm using the diffie-hellman key exchange method to securely generate a key for use with the AES cipher (the result will be hashed to make in the ideal length). Assuming the exponent is a prime of length 2^2048 bits, how can i calculate the size of the base and the modulus if i want the decimal result to be of a length in between (2^6)^32 and (2^6)^40 (i.e. a base64 string of length equal to or greater than 32 and less than or equal to 40 characters). The base i want to use is within the range 3
I'm new to Diffie-Hellman exchanges, are there any restrictions on the modulus, the base or the exponents that i should be aware of?
Is there an equation i can use to derive the ideal pair lengths, or do i have to pre calculate it and store it in an array.
Thanks,
I'm not sure what you are asking about.
For Diffie-Hellman you choose a safe or strong prime p between 2^2047 and 2^2048-1 in your case, then choose an element 0 < g < p-1 such that g^(p-1) mod *p*=1 but g^x mod p≠1 for all 0 < x < p-1 . p and g are constant parameters for your implementation. The size of g does not matter for the scheme. Now for a key exchange you sample 0 < a,b < p-1 uniformly and random, exchange g^a mod p and g^b mod p, and calculate g^ab mod p. Because of the random choice of a and b the result g^ab mod p is also random with 0 < (g^ab mod p) < p-1.
As you have already noticed you can then hash g^ab mod p to generate a short key (256 bit with sha256 for example).
Related
I'm learning how to decrypt a message using RSA algorithms by doing this exercises to calculate the message.
The value of C is 2826893841, and public key (n= 5399937593 and e=3203).
I've computed d (equal to 2311305263), two prime numbers p (equal to 63419) and q (equal to 85147), The result of M could be C^(d) mod n = 2104674266.
The problem is that when I tried to verify the value of C = M^(e) mod n = (2104674266)^(3203) mod 5399937593, it's equal to 91392319 instead of 2826893841 as given above.
I use this website to calculate the mod https://www.mtholyoke.edu/courses/quenell/s2003/ma139/js/powermod.html
Maybe I did something wrong to solve this problem, please tell me how to fix it.
Here are two 64-bit (signed) integers
p = 13776308150928489016
q = 16488138731131959619
and their product
n = 112488352363349635896748360565917156710
The bit-length of the product is floor ((log2 n) + 1) or 127.
Now here are another two 64-bit integers
p = 13275629912622491628
q = 16290498985329101221
and their product
n = 179030914337714357408535416678431567970
but this time the bit length is floor ((log2 n) + 1) or 128.
The reason is that there's a leading zero in the first integer, which makes the space needed to represent the integer in memory one bit smaller.
The problem this causes is that I can't determine the bit length of the keys accurately. For example, here are is a very short RSA key pair:
Public key : 7, 8371846783263706079
Private key : 2989945277626202443, 8371846783263706079
The modulus (8371846783263706079) is 63 bits, which the number I'm after is 64. The overcome this issue I have considered the following solutions:
Round up to the nearest 2^n
Store the key size in bits along with the key
Add some kind of padding to ensure all integers take up the same space (not sure how this would work in practice)
Which one is the correct solution?
As #r3mainer notes, the math needed here -- inequalities -- is not exotic. As to what tutorials say, well, they're just tutorials, they're trying to simplify as much as possible so they leave out some details.
What you are observing is the following:
you want two primes, p and q, to have the same bit length k and their product N to have a bit length of 2k.
By the definition of what it means to have a bit length of k, we have the following inequality:
1) 2(k-1) <= p, q < 2k.
However, when we multiply p and q we discover a problem:
2) 2(2k - 2) <= N < 22k
This means that N=p*q may end up having bit length of 2k-1 or 2k, but we don't want 2k-1.
In your example k=64.
To fix it, we need to tighten up the lower bound on p and q to the following:
3) sqrt(2(2k-1)) <= p, q < 2k.
Bearing in mind that all results are integers, we apply the ceiling function and get finally
4) ceiling(sqrt(2(2k-1))) <= p, q < 2k.
For k=64 this works out to:
13043817825332782213 <= p, q < 264
An even simpler formulation is make the bounds dynamic, as in the following:
first find p, of any size. Then we want
2(2k - 1) <= p*q < 22k, so
5) (2(2k - 1))/ p <= q < (22k)/p will do the trick.
For RSA, we actually do want both primes to be sufficiently large and entropic, and yet not be too close to each other. We can do that by choosing p to have length k-1 or k-2 and applying 5).
Just wondering why does the security of RSA depend on the non-factorability of the modulus n?
Cheers!
well ... the non-factorability of the modulus n is not the whole story ...
as vlad already pointed out, you can easily calculate the private exponent if you know the factors of n ...
(p-1)(q-1) ... or more in general... if you know the prime factors P[i] of a number n, then you can calculate the product of all (P[i] - 1)... that is eulers PHI function ... to know the number of invertible multiplicative elements mod n
if you can factorize n, that calculation becomes trivial ... if n consists of only 2 large primes, and that factorization is hard, that isn't really trivial ...
however ... if you come up with another idea of calculating PHI(n) ... the number of elements mod n that have a multiplicative inverse ... factorization would probably no longer be your problem ...
currently there is no other public known way of calculating phi, than eulers way ... prod(P[i] - 1)
so either finding a way to factorize, or calculating PHI(n) a different way, would probably lead to breaking RSA
The public data in RSA is n - the public modulus, and e - the public exponent. The secret is d - the private exponent.
When creating the parameters you first generate two random primes p and q and then compute the public modulus n = p*q. So p and q are the factorization of n. Actually you could use more primes, but most use just two.
Then you choose the public exponent e, which is usually a small prime such as 65537 or 17 or even 3.
Your secret exponent d would then be d = 1/e mod (p-1)(q-1).
So clearly anyone could compute d if they knew p and q, which is the factorization.
I am programming a fixed-point speech enhancement algorithm on a 16-bit processor. At some point I need to do 32-bit fractional multiplication. I have read other posts about doing 32-bit multiplication byte by byte and I see why this works for Q0.31 formats. But I use different Q formats with varying number of fractional bits.
So I have found out that for fractional bits less than 16, this works:
(low*low >> N) + low*high + high*low + (high*high << N)
where N is the number of fractional bits. I have read that the low*low result should be unsigned as well as the low bytes themselves. In general this gives exactly the result I want in any Q format with less than 16 fractional bits.
Now it gets tricky when the fractional bits are more than 16. I have tried out several numbers of shifts, different shifts for low*low and high*high I have tried to put it on paper, but I can't figure it out.
I know it may be very simple but the whole idea eludes me and I would be grateful for some comments or guidelines!
It's the same formula. For N > 16, the shifts just mean you throw out a whole 16-bit word which would have over- or underflowed. low*low >> N means just shift N-16 bit in the high word of the 32-bit result of the multiply and add to the low word of the result. high * high << N means just use the low word of the multiply result shifted left N-16 and add to the high word of the result.
There are a few ideas at play.
First, multiplication of 2 shorter integers to produce a longer product. Consider unsigned multiplication of 2 32-bit integers via multiplications of their 16-bit "halves", each of which produces a 32-bit product and the total product is 64-bit:
a * b = (a_hi * 216 + a_lo) * (b_hi * 216 + b_lo) =
a_hi * b_hi * 232 + (a_hi * b_lo + a_lo * b_hi) * 216 + a_lo * b_lo.
Now, if you need a signed multiplication, you can construct it from unsigned multiplication (e.g. from the above).
Supposing a < 0 and b >= 0, a *signed b must be equal
264 - ((-a) *unsigned b), where
-a = 232 - a (because this is 2's complement)
IOW,
a *signed b =
264 - ((232 - a) *unsigned b) =
264 + (a *unsigned b) - (b * 232), where 264 can be discarded since we're using 64 bits only.
In exactly the same way you can calculate a *signed b for a >= 0 and b < 0 and must get a symmetric result:
(a *unsigned b) - (a * 232)
You can similarly show that for a < 0 and b < 0 the signed multiplication can be built on top of the unsigned multiplication this way:
(a *unsigned b) - ((a + b) * 232)
So, you multiply a and b as unsigned first, then if a < 0, you subtract b from the top 32 bits of the product and if b < 0, you subtract a from the top 32 bits of the product, done.
Now that we can multiply 32-bit signed integers and get 64-bit signed products, we can finally turn to the fractional stuff.
Suppose now that out of those 32 bits in a and b N bits are used for the fractional part. That means that if you look at a and b as at plain integers, they are going to be 2N times greater than what they really represent, e.g. 1.0 is going to look like 2N (or 1 << N).
So, if you multiply two such integers the product is going to be 2N*2N = 22*N times greater than what it should represent, e.g. 1.0 * 1.0 is going to look like 22*N (or 1 << (2*N)). IOW, plain integer multiplication is going to double the number of fractional bits. If you want the product to
have the same number of fractional bits as in the multiplicands, what do you do? You divide the product by 2N (or shift it arithmetically N positions right). Simple.
A few words of caution, just in case...
In C (and C++) you cannot legally shift a variable left or right by the same or greater number of bits contained in the variable. The code will compile, but not work as you may expect it to. So, if you want to shift a 32-bit variable, you can shift it by 0 through 31 positions left or right (31 is the max, not 32).
If you shift signed integers left, you cannot overflow the result legally. All signed overflows result in undefined behavior. So, you may want to stick to unsigned.
Right shifts of negative signed integers are implementation-specific. They can either do an arithmetic shift or a logical shift. Which one, it depends on the compiler. So, if you need one of the two you need to either ensure that your compiler just supports it directly
or implement it in some other ways.
I'm new to cryptography and modular arithmetic. So, I'm sure it's a silly question, but I can't help it.
How do I calculate a from
pow(a,q) = 1 (mod p),
where p and q are known? I don't get the "1 (mod p)" part, it equals to 1, doesn't it? If so, than what is "mod p" about?
Is this the same as
pow(a,-q) (mod p) = 1?
The (mod p) part refers not to the right hand side, but to the equality sign: it says that modulo p, pow(a,q) and 1 are equal. For instance, "modulo 10, 246126 and 7868726 are equal" (and they are also both equal to 6 modulo 10): two numbers x and y are equal modulo p if they have the same remainder on dividing by p, or equivalently, if p divides x-y.
Since you seem to be coming from a programming perspective, another way of saying it is that pow(a,q)%p=1, where "%" is the "remainder" operator as implemented in several languages (assuming that p>1).
You should read the Wikipedia article on Modular arithmetic, or any elementary number theory book (or even a cryptography book, since it is likely to introduce modular arithmetic).
To answer your other question: there is no general formula for finding such an a (to the best of my knowledge) in general. Assuming that p is prime, and using Fermat's little theorem to reduce q modulo p-1, and assuming that q divides p-1 (or else no such a exists), you can produce such an a by taking a primitive root of p and raising it to the power (p-1)/q. [And more generally, when p is not prime, you can reduce q modulo φ(p), then assuming it divides φ(p) and you know a primitive root (say r) mod p, you can take r to the power of φ(p)/q, where φ is the totient function -- this comes from Euler's theorem.]
Not silly at all, as this is the basis for public-key encryption. You can find an excellent discussion on this at http://home.scarlet.be/~ping1339/congr.htm#The-equation-a%3Csup%3Ex.
PKI works by choosing p and q that are large and relatively prime. One (say p) becomes your private key and the other (q) is your public key. The encryption is "broken" if an attacker guesses p, given aq (the encrypted message) and q (your public key).
So, to answer your question:
aq = 1 mod p
This means aq is a number that leaves a remainder of 1 when divided by p. We don't care about the integer portion of the quotient, so we can write:
aq / p = n + 1/p
for any integer value of n. If we multiply both sides of the equation by p, we have:
aq = np + 1
Solving for a we have:
a = (np+1)1/q
The final step is to find a value of n that generates the original value of a. I don't know of any way to do this other than trial and error -- which equates to a "brute force" attempt to break the encryption.