+- Forums - Open Redstone Engineers (https://forum.openredstone.org)
+-- Forum: Off-Topic (https://forum.openredstone.org/forum-4.html)
+--- Forum: General computing and engineering (https://forum.openredstone.org/forum-66.html)
+--- Thread: Try decrypt this! Private key included! (/thread-3866.html)
Pages:
1
2
Try decrypt this! Private key included! - gtaguy235 - 06-25-2014
Private Key:
100100010001000100000100010000100010010010001010
Encrypted Message:
EnCt2de09c0a99e4bb09e8c3c73b648c2f059403b6b41de09c0a99e4bb09e8c3c73b6Dl7byQHowAH
1QK43q1MyqB/OTjT7SFF14E32FS+Otvd3aCE=IwEmS
RE: Try decrypt this! Private key included! - Apuly - 06-25-2014
It sais '"I'm a giant ass maggot." I'm sure of it.
RE: Try decrypt this! Private key included! - gtaguy235 - 06-26-2014
(06-25-2014, 11:07 PM)paulydboy Wrote: It sais '"I'm a giant ass maggot." I'm sure of it.
Lol
RE: Try decrypt this! Private key included! - tha_cre8er - 06-29-2014
i am probably a noob, because i do not know what this is...where do i even input the private key?
hexa-something i know that much!
xD
RE: Try decrypt this! Private key included! - Jmking80 - 06-30-2014
Okay here is my say on this.
Quote:hexa-something i know that much!
First off all the encrypted messsage is clearly not hexadecimal,
because it seams to use all letters of the alphabet both capital and non capital. furthermore it also uses "+", "/" and "="
I think this is a clear indication of base64 encoding.
But the "=" close to the end confuses me, it should only be on the end.
Added as padding if the message is too short.
Anybody having studied RSA will know that both the private key and the public key consist of 2 parts, the exponent and the modulus. I only see one here. Judging by it size, I think it's the exponent. (also gtaguy confirmed this to me in game.)
He doesn't explicitly state whether he encrypted the message with his public key or his private key. But the public and private exponent are interchangeable, when encrypting data. But only the opposide key can decrypt it. Really what is the public and what is the private is decided when you decide which to use to encrypt.
He says he gives us his private key, so I'm assuming he encrypted it using his public key. I don't think there would be a reason to state it so specificly that he gives us his (incomplete) private key.
I think decrypting is impossible because the encrypted message is not right in the first place. But lets just for the sake of argument assume we had a good encrypted message. Then we still have the question, did he split his message into parts before encrypting and did he just append them all?
I'm assuming he didn't, just because he doesn't state it. He also doesn't state whether he encoded his message base64 before encrypting.
Then the normal way to decrypt it would be :
(encrypted message^private exponent) mod (modulus) = plaintext
Since we don't know the modulus we have a problem.
But we do know something more we know that the modulus is probably greater then the exponent. What we do know for sure is that the public exponent is smaller then the modules. The public exponent is most of the time 65537. Because this makes encryption easier and has some nice properties.
This makes it possible to verify we have the right modulus.
If we had the right modules, we could just decrypt his message.
Then encrypt it again using the public key. If and only if they are the same we have the right exponent.
So in theory we could brute force his modulus if we have a correct encrypted message.
I'm requesting that gtaguy makes his original post more clear.
And corrects his base64 encoding.
For me he doesn't have to give his modulus, but confirming he used 65537 as public exponent would be nice.
-Jmking80
P.s. I'm going to get cracking the moment he updates
RE: Try decrypt this! Private key included! - jxu - 07-01-2014
Jmking is correct. The message, based on the inclusion of numbers and letters is consistent with base 64. The result is probably a number that was encoded with ASCII or UTF-8.
However since you mentioned a private key I assume that means there's a public key too. For RSA this would be hard to determine for large numbers but we could probably brute force it. As for jmking's point about how the messsage was split, we would need to know the padding scheme (maybe it's a well known implementation)
RE: Try decrypt this! Private key included! - tyler569 - 07-03-2014
See, I think you're all looking at this a tad wrong.
1. I'll bet there's some fanciness going on with his "Private Key," the consistent pattern of 1s and 0s implies to me wither that's not binary encoded or there's something else fishy going on.
2. The encrypted message is more than just a base64 string. I say this because if you take a moment and break it up, there appears to be a hex-encoded SHA256 hash inside it, look:
either
Code:
EnCt2
de09c0a99e4bb09e8c3c73b648c2f059403b6b41de09c0a99e4bb09e8c3c73b6
Dl7byQHowAH1QK43q1MyqB/OTjT7SFF14E32FS+Otvd3aCE=
IwEmSCode:
EnCt
2de09c0a99e4bb09e8c3c73b648c2f059403b6b41de09c0a99e4bb09e8c3c73b
6Dl7byQHowAH1QK43q1MyqB/OTjT7SFF14E32FS+Otvd3aCE=
IwEmSboth of which contain a valid hexadecimal encoded SHA256 hash and a valid Base64 encoded string. I couldn't find any reverse of either hash in rainbow tables and neither of those b64s make a ton of sense, but I think this is progress.
EDIT: I'll make clear, the hex section does not *have* to be a hash, that was my initial impression, but both simply represent 256 bits of information encoded in hex.
Clarification: I also cannot explain the significance of the start and end sections, however the fact that both alternate between capital and lowercase suggest some special significance is placed there
RE: Try decrypt this! Private key included! - jxu - 07-05-2014
Good point tyler, if his private key is not based on a standard method, then the problem becomes much harder. the hash is not a valid MD5 hash and it is not possible to reverse SHA1 or SHA2 (unless I went through with rainbow tables, which I will not do).
Whatever it is, the problem is poorly posed and not worth my effort.
RE: Try decrypt this! Private key included! - tyler569 - 07-05-2014
tyler569 Wrote:I couldn't find any reverse of either hash in rainbow tables
͝ ͟ ͜ Wrote:unless I went through with rainbow tables, which I will not do
mmhmm XD
RE: Try decrypt this! Private key included! - gtaguy235 - 07-08-2014
(06-30-2014, 08:57 PM)Jmking80 Wrote: Okay here is my say on this.Hi, yes that is the public exponent.
Quote:hexa-something i know that much!
First off all the encrypted messsage is clearly not hexadecimal,
because it seams to use all letters of the alphabet both capital and non capital. furthermore it also uses "+", "/" and "="
I think this is a clear indication of base64 encoding.
But the "=" close to the end confuses me, it should only be on the end.
Added as padding if the message is too short.
Anybody having studied RSA will know that both the private key and the public key consist of 2 parts, the exponent and the modulus. I only see one here. Judging by it size, I think it's the exponent. (also gtaguy confirmed this to me in game.)
He doesn't explicitly state whether he encrypted the message with his public key or his private key. But the public and private exponent are interchangeable, when encrypting data. But only the opposide key can decrypt it. Really what is the public and what is the private is decided when you decide which to use to encrypt.
He says he gives us his private key, so I'm assuming he encrypted it using his public key. I don't think there would be a reason to state it so specificly that he gives us his (incomplete) private key.
I think decrypting is impossible because the encrypted message is not right in the first place. But lets just for the sake of argument assume we had a good encrypted message. Then we still have the question, did he split his message into parts before encrypting and did he just append them all?
I'm assuming he didn't, just because he doesn't state it. He also doesn't state whether he encoded his message base64 before encrypting.
Then the normal way to decrypt it would be :
(encrypted message^private exponent) mod (modulus) = plaintext
Since we don't know the modulus we have a problem.
But we do know something more we know that the modulus is probably greater then the exponent. What we do know for sure is that the public exponent is smaller then the modules. The public exponent is most of the time 65537. Because this makes encryption easier and has some nice properties.
This makes it possible to verify we have the right modulus.
If we had the right modules, we could just decrypt his message.
Then encrypt it again using the public key. If and only if they are the same we have the right exponent.
So in theory we could brute force his modulus if we have a correct encrypted message.
I'm requesting that gtaguy makes his original post more clear.
And corrects his base64 encoding.
For me he doesn't have to give his modulus, but confirming he used 65537 as public exponent would be nice.
-Jmking80
P.s. I'm going to get cracking the moment he updates