I need to decrypt c and I was given only n, e and c and computing p and q or phi(n) would be close to impossible so what other alternatives do I have? I tried calculating p and q but I made very little progress with the search in the last 24 hours of continuous running the program.
These are the values I was given:
n: 58900433780152059829684181006276669633073820320761216330291745734792546625247
e: 65537
c: 56191946659070299323432594589209132754159316947267240359739328886944131258862
Also, in another challenge only c and n were given and the values were a lot bigger. Do you have any suggestions for that too?
Well, it seems that this question is CTF related, because the patterns of n, e, and c are weak numbers.
You can solve it with RsaCtfTool:
python RsaCtfTool -n 58900433780152059829684181006276669633073820320761216330291745734792546625247 -e 65537 --uncipher 56191946659070299323432594589209132754159316947267240359739328886944131258862
timctf{CENSORED}
https://www.dcode.fr/rsa-cipher
Try this one but it need p and q. So I use the hand calculator to find p and q.
Using Fact(n), ex: Fact(91)= 7x13, so p=7, q=13
Related
I want to use cryptographic function that returns the initial input or something related to it like its hash,
the function should work like Encrypting some data, then Encrypt the output of the data, and encrypt it again another time, and the loop continue to specific number of iterations and finally it can produce the first input after iterating it.
assuming that we can use any different keys or same key if required in encryption and the function can only go in one way it can't be reversible so i can't run this process from the back loop and finally it should return the first input or something related to its first input by checking the hash of it or something like that.
thanks for help
rsa has this property if you only look at the encryption...
this is because of how rsa works:
n = p * q
e * d = 1 mod phi(n)
x = (x^e)^d = x^(e * d) mod n
if you are calculating mod n, all exponents are mod phi(n), hence d is the multiplicative inverse of e (fermat's little theorem)
since that's a cyclic group and e and d are choosen to generate that group, there's your cyclic property
if phi(n) is secret, calculating d from e is seemingly a hard problem (that's what makes it hard to break RSA)
to reverse the cycle you need the inverse exponent.
but here's the catch: you won't have control over the size of the cycle, and by trying to create small cycles, you will end up with weak keys that can potentially be bruteforced to get the inverse element which will break the one way property
and speaking about cycle sizes... with sufficiently sized rsa keys the cycle sizes are probably too large for you... like not-within-your-lifetime large... phi(n) ... with phi being eulers phi function ... n being p * q ... and p and q being primes with like 1200 digits
I'm creating an encryptor/decryptor for ascii strings where I take the ascii value of a char, add 1 to it, then mod it by the highest ascii value so that I get a valid ascii char out.
The problem is the decryption.
Let's say that (a + b) % c = d
I know b, c, and d's values.
How do I get the a variables value out from that?
This is exactly the ROT1 substitution cipher. Subtract 1, and if less than lowest value (0 I assume, given how you're describing it), then add the highest value.
Using terms like "mod," while accurate, make this seem more complicated than it is. It's just addition on a ring. When you go past the last letter, you come back to the first letter and vice-versa. Once you put your head around how the math works, the equations should pop out. Basically, you just add or subtract as normal (add to encrypt, subtract to decrypt in this case), and at the end, mod "normalizes" you back onto the ring of legal values.
Use the inverse formula
a = (b - d) mod c
or in practice
a = (b - d + c) % c.
The term + c needs to be added as a safeguard because the % operator does not implement a true modulo in the negatives.
Let's assume that c is 2, d is 0 and b is 4.
Now we know that a must be 2... Or 4 actually.. or 6... Or any other even number.
You can't solve this problem, there are infinite solutions.
For the below quardratic formula, I have multiple a but fixed b and c.
I wish to write a partial application function, which execute efficiently, i.e., my function doesn't recompute fixed values (because of b and c).
Here is my solution
let r b c = let z = b *. b in fun a -> (-.b +. sqrt (z-.4.0*.a*.c))/.(a*.2.0);;
I guess this solution can work, but I am not sure whether it is efficient enough. I just made b^2 to be fixed as I saw other parts are all with a.
Anyone can give me a better solution?
Yeah, that's a correct way to deal with the situation at hand. The alternate form doesn't help much (as long this obtains the accuracy you require). You may want to move the 4*c out as well,
let r b c = let z = b *. b and c4 = 4.0 *. c in
fun a -> (-.b +. sqrt (z-.a*.c4))/.(a*.2.0);;
I've been trying to trace Dijkstra's shortest path algorithm for the following undirected graph:
(B)
/ \
/ \
6 / \ 9
/ \
/ \
/ \
(A)- 5 -(C)- 1 -(F)----2----(I)
\ /
\ /
4 \ / 2
\ /
\ /
\ /
(D)
For clarification:
(N) will represent nodes, numbers with no formatting will represent weights.
the edge between A and C has a weight of 5,
the edge between C and F has a weight of 1.
I'll outline my process here:
Since A is my initial node, the algorithm begins here. Since D is the cheaper path, the algorithm traverses to D. A is now marked as visited, meaning we cannot traverse to it again.
At D it is easy to see that we will move to F.
F is where I start having trouble. Since the shortest path will lead me to C, I'm stuck between two visited nodes with no way to get to I. Can anyone help me?
EDIT: Sorry about the graph guys, this question was originally asked from a phone. I'll get that fixed asap.
The way you are working on it is wrong. "At D it is easy to see that we will move to F" that is not true. You first visit D, then C, not F. Take a careful look at the algorithm and what it does.
At first you visit A so you have the following cost: 6 to B, 5 to C, 4 to D and INFINITE for the rest of the nodes.
You first go to D. You now update your cost to go from A to F (passing through D) to 6. Your next node to visit is not D, it is C as it has the lowest cost (5) of all the unvisited nodes. The cost of going from A to F passing through C is 6 which is already the cost you have so there is not need to update.
From there you have a tie of 6 between B and F. Let's say you first go to B, then nothing happens since the shortest path to F is already 6, while passing through B to go to F would cost 15, which is more expensive than the cost you already have so don't update the cost. Then you visit F since it has the lowest cost of all the unvisited nodes. From there you update your path to I which it won't be INFINITE anymore but 8.
As result, your shortest path from A to I is the following sequence: A - D - F - I .
From C you still cannot go back to A and you cannot return to F so this path is false.
You need to remove the C from the graph at next iteration if it gives you dead-end, or ignore last step and move from F to I as you would expect.
http://en.wikipedia.org/wiki/Dijkstra's_algorithm - you remember that it processes ALL of a vertex's neighbours before moving on to another vertex, right?
Before moving on to D, it processes C and B (calculates their distances). And judging from your graph, there is no route between D and F..
Dijkstra's algorithm uses a priority queue. It's not a walk on the graph, and it is possible to visit vertices in order that does not resemble a path. For example, this tree:
A -> B -> C
\
> D -> E -> F
with all weights 1 is explored in order A,B,D,C,E,F. Each iteration you visit the vertex with smallest cost and pop it; initially you pop A, the cost of B and D is updated to 1; you visit B, the cost of C is updated to 2; you visit D, the cost of E is updated to 2; you visit E; and finally F.
MathWorld page gives a simple numeric formula for e that's allegedly correct for first 10^25 digits. It states that e is approximately
(1 + 9^-4^(7*6))^3^2^85
Any idea how to check whether this formula is correct even for the first 10 digits?
Here's another way of writing the right hand side
Power[Plus[1, Power[9, Times[-1, Power[4, Times[7, 6]]]]], Power[3, Power[2, 85]]]
This problem does not need Mathematica at all. First, it is easy to show that 9^(4^(7*6)) is exactly equal to 3^2^85, since
9^(4^(7*6)) = 3^(2*4^(7*6)) = 3^(2^(1+2*(7*6))) = 3^2^85
Then, we know that one of the ways to represent e is as a limit
e = lim (1+1/n)^n, n->infinity
The only question is what is the error given that n is very large but finite. We have
(1+1/n)^n = e^log((1+1/n)^n) = e^(n*log(1+1/n)) = e^(1-1/(2n)+O(1/n^2)) = e + O(1/n),
Given the n = 3^2^85, i we take the log(10,n) = 2^85 log(10,3) ~ 1.85 *10^25, we get an estimate
similar to the quoted one
Repeatedly taking logs is a nice (usually) generally-applicable solution to problems of this sort. Here's a more special-case approach to this problem: recall that e = lim(n->infinity, (1+1/n)^n). So to be a good approximation to e, all we need is for 9^(4^(42)) (the denominator of the fractional part) to be sufficiently close to 3^(2^85) and big.
In this case, they're identical, so we have n=3^(2^85), and it's going to be a very good approximation to e. These are big numbers, but not unworkably so:
>>> from mpmath import *
>>> iv.dps = 50 # let's use interval arithmetic, just for fun
>>> x = mpi(9)**(-(4**(42)))
>>> up = (mpi(3)**(2**85))
>>> x
mpi('1.4846305545498656772753385085652043615636250118238876e-18457734525360901453873570',
'1.4846305545498656772753385085652043615636250118238899e-18457734525360901453873570')
>>> 1/x
mpi('6.7356824695231749871315222528985858700759934154677854e+18457734525360901453873569',
'6.7356824695231749871315222528985858700759934154678156e+18457734525360901453873569')
>>> up
mpi('6.7356824695231749871315222528985858700759934154678005e+18457734525360901453873569',
'6.7356824695231749871315222528985858700759934154678156e+18457734525360901453873569')
>>> 0 in (1/x-up)
True
Working out the exact error bounds on e is left as an exercise for the reader ;-) -- hint: compare the number of digits of accuracy the mathworld page claims and the above numbers, and ask why that might be, thinking of the series of approximations (1+1/1)^1, (1+1/2)^2, etc.