Modular arithmetic and semi elgamal encryption - cryptography

I'm implementing a semi ELGamal cryptosystem(from a research paper) function that has been used in PVSS. Unfortunately, I fail to decrypt as it has been described in the algorithm.
Here is the initialisation phase:
Select a secure prime p such that p-1=2q where q is also a prime, then make a cyclic group G and let g be a random generator of this group. Pick a random x(private key) in the group and let y = g^x(public key). I simply initialise the algorithm as following:
p = 233;
g = 131;
x = 139;
y = g ^ x mod 233; //y = 182
Now let s (secret) be 23 and we compute our es (encrypted secret):
s = 23
es = y ^ s mod 233// es = 231
In order to decrypt the es, I raise es to the inverse of x(private key), I should return the g ^ s, assume ds is the deciphered value:
ds = es ^ 1/x mod 233 // 1/x = 57, ds = 116
Problem is here, ds is not equal to g ^ s but in theory it should be because:
recall that we encrypted our s as:
es = y ^ s mod 233
and we know that
y = g ^ x mod 233
so,
es = g ^ x ^ s mod 233
Given that,
ds = es ^ 1/x mod 233
// which means:
ds = g ^ x ^ s ^ 1/x mod 233
therefore, I expect to get same result as of g^s (131 ^ 23 mod 233) which must be 182 while what I get as the ds result is 116.
Is there anything wrong with what I'm doing?

When you have:
x * invX = 1 mod p
the following equality is generally not true:
(g ^ x) ^ invX = g mod p
Above expression means multiplying g*g*....*g a certain number of times, x * invX, which is also k * p + 1 according to first modulo relation.
Say your generator has a size n <= p-1:
g ^ n = 1 mod p
That means that x * invX must be a multiple of n...
In your preamble, you assert that q=(p-1)/2 is prime, but here, it's not the case, q=116...
And in your example g=131 is generating a sequence of length 58=(p-1)/4.
Then, only those x have the property g ^ x ^(1/x) = 1 mod p :
58 116 132 154 174 203 229 231 232
Note that for another generator, g=5, the sequence is of maximal length p-1, and then the sole x satisfying (g ^ x) ^ invX = 1 mod p is x=p-1.
Since y^(p-1) = 1 mod p for any y non multiple of p, x=p-1 is allways working as you expect anyway...

Related

Recommended value for the variable for Linear Congruential Generator

I am trying to generate 48 pseudoraandom number by using linear congruential generator. I am only using alphabet from a to z for my plaintext which will be for mapping 0 to 25.
I am using the algorithm for the linear congruential generator below
Xn+1 = (aXn + c) mod m
where Xn is the sequence of pseudorandom values, and
• Modulus: m, 0 < m
• Multiplier: a, 0 < a < m
• Increment: c, 0 ≤ c < m
• Seed: X0, 0 ≤ X0 < m
I am using the algorithm for the linear congruential generator below
Xn+1 = (aXn + c) mod m
X2 = (7(11) + 11) mod 18 = 16
X3 = (7(16) + 11) mod 18 = 15
X4 = (7(15) + 11) mod 18 = 8
What would be the recommended value for the seed, increment, multiplier and modulus. Keystream need to be from 0 to 26 as I need to map the number to the corresponding letter.
I want unique and less repetition.
Please kindly advise.
Thank you

Rewrite Resurrence Function to the Idea of Dynamic Programming

Can someone help me?
Rewrite the pseudo-code of Count(n) using the idea of Dynamic Programming. And determine the Time Complexity.
Test(n)
If n=1 return 1
Tn=0
For k=1 to n-1
Tn = Tn + Test(k) * Test(n-k)
Return Tn
Add Memoization to get a DP solution from a recursion one:
Python Code:
d = {}
def test(n):
if n == 1:
return 1
if d.get(n) is not None:
return d[n]
ans = 0
for k in range(1, n):
ans += test(k) * test(n - k)
d[n] = ans
return ans
You can check(It's Catalan numbers indeed, learn more about it in OEIS):
for i in range(1, 10):
print str(i) + ' ' + str(test(i))
Output:
1 1
2 1
3 2
4 5
5 14
6 42
7 132
8 429
9 1430
Time Complexity is O(n^2). Because calculate a state is O(n)(for k from 1 to n - 1), and we need calculate n state in total to get test(n).
In fact, we can achieve a O(n) solution since it's Catalan numbers...

RSA crypto - How to choose p, q and e correctly?

Recently I've found some troubles after having those e, n and d value.
I had this set
(p=3, q=11)
so n = 33 and Euler(n)=20.
I choose
e=3, calculated d = 7.
For message x=49, the signature would be
s = x^d mod n = 49^7 mod 33 = 25.
Someone would verify it like ver(s) = s^e mod n = 16 != x (Fake?)
What 've I done wrong.
As the previous answerer rather (too) succinctly put - naive RSA will only recover the exact original value when it is less than the modulus (n). Your message x = 49 is larger than your modulus (n = 33), so you will not be able to decrypt the ciphertext back to the original value of x.
If you were to try again with a smaller message, e.g. x = 25 things will work fine:
Encrypt:
C = xe mod n
= 253 mod 33
= 16
Decrypt:
x = Cd mod n
= 167 mod 33
= 25
This is not wrong:
49=16 mod 33

Haskell Heap Issues with Parameter Passing Style

Here's a simple program that blows my heap to Kingdom Come:
intersect n k z s rs c
| c == 23 = rs
| x == y = intersect (n+1) (k+1) (z+1) (z+s) (f : rs) (c+1)
| x < y = intersect (n+1) k (z+1) s rs c
| otherwise = intersect n (k+1) z s rs c
where x = (2*n*n) + 4 * n
y = (k * k + k )
f = (z, (x `div` 2), (z+s))
p = intersect 1 1 1 0 [] 0
main = do
putStr (show p)
What the program does is calculate the intersection of two infinite series, stopping when it reaches 23 elements. But that's not important to me.
What's interesting is that as far as I can tell, there shouldn't be much here that is sitting on the heap. The function intersect is recursives with all recursions written as tail calls. State is accumulated in the arguments, and there is not much of it. 5 integers and a small list of tuples.
If I were a betting person, I would bet that somehow thunks are being built up in the arguments as I do the recursion, particularly on arguments that aren't evaluated on a given recursion. But that's just a wild hunch.
What's the true problem here? And how does one fix it?
If you have a problem with the heap, run the heap profiler, like so:
$ ghc -O2 --make A.hs -prof -auto-all -rtsopts -fforce-recomp
[1 of 1] Compiling Main ( A.hs, A.o )
Linking A.exe ...
Which when run:
$ ./A.exe +RTS -M1G -hy
Produces an A.hp output file:
$ hp2ps -c A.hp
Like so:
So your heap is full of Integer, which indicates some problem in the accumulating parameters of your functions -- where all the Integers are.
Modifying the function so that it is strict in the lazy Integer arguments (based on the fact you never inspect their value), like so:
{-# LANGUAGE BangPatterns #-}
intersect n k !z !s rs c
| c == 23 = rs
| x == y = intersect (n+1) (k+1) (z+1) (z+s) (f : rs) (c+1)
| x < y = intersect (n+1) k (z+1) s rs c
| otherwise = intersect n (k+1) z s rs c
where x = (2*n*n) + 4 * n
y = (k * k + k )
f = (z, (x `div` 2), (z+s))
p = intersect 1 1 1 0 [] 0
main = do
putStr (show p)
And your program now runs in constant space with the list of arguments you're producing (though doesn't terminate for c == 23 in any reasonable time).
If it is OK to get the resulting list reversed, you can take advantage of Haskell's laziness and return the list as it is computed, instead of passing it recursively as an accumulating argument. Not only does this let you consume and print the list as it is being computed (thereby eliminating one space leak right there), you can also factor out the decision about how many elements you want from intersect:
{-# LANGUAGE BangPatterns #-}
intersect n k !z s
| x == y = f : intersect (n+1) (k+1) (z+1) (z+s)
| x < y = intersect (n+1) k (z+1) s
| otherwise = intersect n (k+1) z s
where x = (2*n*n) + 4 * n
y = (k * k + k )
f = (z, (x `div` 2), (z+s))
p = intersect 1 1 1 0
main = do
putStrLn (unlines (map show (take 23 p)))
As Don noted, we need to be careful so that accumulating arguments evaluate timely instead of building up big thunks. By making the argument z strict we ensure that all arguments will be demanded.
By outputting one element per line, we can watch the result being produced:
$ ghc -O2 intersect.hs && ./intersect
[1 of 1] Compiling Main ( intersect.hs, intersect.o )
Linking intersect ...
(1,3,1)
(3,15,4)
(10,120,14)
(22,528,36)
(63,4095,99)
(133,17955,232)
(372,139128,604)
(780,609960,1384)
...

RSA: why does phi(phi(n)) work?

Apparently an alternative method (to just using the extended Euclidean algorithm) of obtaining the exponent for deciphering is to do d = e**(phi(phi(n))-1) mod(phi(n)). Why does this work?
The general requirement for the RSA operation to function properly is that e*d = 1 mod X, where X is typically (p-1)*(q-1).
In this case, X is phi(n), e is e, and d is e^[phi(phi(n))-1] = e^[phi(X)-1].
Notice that e*d mod X is e*e^[phi(X)-1] mod X = e^phi(X) mod X.
Euler's Theorem states that a^phi(X) = 1 mod X, for any a which is relatively prime to X, thus the requirement holds.