-1

I have these 2 different encrypted texts 

+j+hnQx9Wl83MWeM92tyZA==

and 

E4NEi092gWbppbpNR0JUAw==

They should both be long numbers, like 19732832, but I don't know how to decrypt them. Does anyone know how to help me? I would be very glad if anyone could tell me either the encryption method or just the decrypted text.

If it can help somehow, this is another example: 

lJsFziTUF4LtFzww7d2tVw==
schroeder
  • 129,372
  • 55
  • 299
  • 340
Tommaso
  • 1
  • 1
  • not that much, it just says it's impossible, but I'm wondering whether there's a way – Tommaso Apr 19 '20 at 20:08
  • @Tommaso I will illustrate what you are asking. I am imagining a random number, then divide that by 7. I tell you that the remainder is 2. I ask you, what is the original number? You say, "it's impossible, but I'm just wondering if there's a way to know". –  Apr 19 '20 at 20:57
  • The reason that it's impossible to answer this question is because there are an infinite number of answers. See https://security.stackexchange.com/questions/3989/how-to-determine-what-type-of-encoding-encryption-has-been-used/227718#227718. – mti2935 Apr 19 '20 at 21:15
  • No, I don't know the original numbers. By the way I'm sure that if the numbers are encypted using a key it impossible to decipher them. But I was thinking of encryptions like base64,.base16, md5 that don't require keys – Tommaso Apr 19 '20 at 21:36
  • 1
    @Tommaso Those are not encryptions, those are encodings. So you actually don't know whether or not it's encrypted. – David Schwartz Apr 19 '20 at 21:49

1 Answers1

1

This is obviously an unanswerable question. We can imagine an unlimited number of possible ways you could encode long numbers into those strings. Just given the string, there's no way to know.

For an obvious example, imagine if you see "4","3","2". That could obviously encode 432, but it could equally obvious encode 234. There is absolutely no way to know which of those two is correct, if either.

If it helps, it does appear to be nearly certain that each of those strings contains 16 bytes of data encoded in base64. Here's the 16-byte data for the three strings you supplied converted into hexadecimal:

lJsFziTUF4LtFzww7d2tVw== -> 94 9b 05 ce 24 d4 17 82 ed 17 3c 30 ed dd ad 57
E4NEi092gWbppbpNR0JUAw== -> 13 83 44 8b 4f 76 81 66 e9 a5 ba 4d 47 42 54 03
+j+hnQx9Wl83MWeM92tyZA== -> fa 3f a1 9d 0c 7d 5a 5f 37 31 67 8c f7 6b 72 64

David Schwartz
  • 4,283
  • 25
  • 21
  • David, your byte order is swapped from mine. Probably a function of the tools used. echo lJsFziTUF4LtFzww7d2tVw== | base64 -d | hexdump -C 00000000 94 9b 05 ce 24 d4 17 82 ed 17 3c 30 ed dd ad 57 |....$.....<0...W| --- same for the other two. – user10216038 Apr 19 '20 at 23:30
  • @user10216038 Thanks. I flipped them. – David Schwartz Apr 19 '20 at 23:53
  • I see! The -C dumps it out in byte order 0 1 2 3 ... but not using the Connical is a 2 byte string order of 1 0 3 2 .... – user10216038 Apr 20 '20 at 00:06
  • I've actually found the decoded text. Would it be possible to find how the text was encoded now? – Tommaso Apr 21 '20 at 18:39
  • @Tommaso It is at least theoretically possible with a few encoded/decoded pairs. But that assumes it's not encrypted. – David Schwartz Apr 21 '20 at 18:41
  • I don't know. If I post some 2 pairs of encoded decoded text do you think you would be able to help me? – Tommaso Apr 21 '20 at 18:58