0

I have a bunch of encoded strings and I am trying to figure the encryption algorithm behind it. I would appreciate if you could help me find which encryption algorithm it is, or if you could point me in a direction. Here's what I know so far:

  • The output is always 22 characters long.
  • The output only contains [a-zA-Z0-9_-].
  • There's a high chance that the encryption occurred within PHP (not 100% sure).

Here are some examples of the encrypted strings:

t_PLJfnXRPS0HzZ_gKdaQg
V-FBHyLcTn6GVCtKvBOFrg
8T148uQ_TCWtOfMar03Y_Q
1Z20Bh3LQG2bMRlS9CvOjQ
bpxt8O4PShW7pqWotIrxKw
oJpqsNvpRPeCHhcObyhhww
VY3LJhnKS9iF9bSzN9qAWA
DK3Z5kjiRTeBpfDLrdfGyA
GUetaVQkRmWWVJluyezR9w

Thank you in advance for your help. Cheers.

Alexandre Barfuhok
  • 103
  • 1
  • 3
  • 2
    It's 16 bytes encoded with base64url, that's about all anyone can say without more info. – AndrolGenhald Sep 19 '18 at 16:57
  • base64url encoding generate other kind of characters, such as =, which are not part of the generated strings here. – Alexandre Barfuhok Sep 19 '18 at 17:04
  • 1
    '=' is padding that can be safely stripped. Some decoders support strings without padding, and for those that don't it can easily be added back. – AndrolGenhald Sep 19 '18 at 17:11
  • And note of the two standard and common post-uuencode base64 alphabets (A-Za-z0-9+/ and A-Za-z0-9-_) the latter is used by JSON standards (JWS, JWE) without padding. – dave_thompson_085 Sep 19 '18 at 17:31
  • @AndrolGenhald Tne trailing "=" sign(s) can be stripped but will need to be added back on decoding the Base64. It really is best to leave them. – zaph Sep 19 '18 at 17:52
  • 3
    if they are all the same length, it's more likely a hash than encyption – dandavis Sep 19 '18 at 18:21

1 Answers1

0

The encoding seems to be a form of URL-base64 encoding without padding. That's pretty commonly used. The character set allows it to be used in URI parameters like ?enc=....and such contexts.

The result after decoding is then 16 bytes (every 3 bytes becomes 4 characters, so we get 20 from the first 15 bytes and 2 characters more to encode the last byte; you'll note that the final character has fewer options than the other ones, because it really encodes 2 trailing bits (so we'd expect 4 different ones, including A for 00 etc.). Read up on base64 encoding if you want the nitty gritty.

This suggests that a hash of some sort is used. It could be MD4, MD5, MD2 and truncated variants of longer hashes etc. Or if it's sure to be reversible it could be a single block of say AES encrypted data. Without access to more info it's speculation.

Henno Brandsma
  • 1,156
  • 6
  • 6
  • I just got it. It was a mix of unicode encoding and URL-base64. Thanks for the help. – Alexandre Barfuhok Sep 26 '18 at 20:56
  • @AlexandreBarfuhok after decoding it looks pretty random to me, not like Unicode strings (not UTF8 anyway). – Henno Brandsma Sep 26 '18 at 20:59
  • Take the following string: 2cfNlD0JQtaeYgf5JjKXcg If you base64 decode you get this: ÙÇÍ= BÖbù&2r Then you decode each character with unicode and you take the 2 last characters. For instance, Ù gives \u00d9, so you take d9. If you do this with all characters, it gives you an uuid, which I was looking for. – Alexandre Barfuhok Sep 27 '18 at 16:05
  • @AlexandreBarfuhok You actually get the raw bytes (hex) `d9 c7 cd 94 3d 09 42 d6 9e 62 07 f9 26 32 97 72` which you might see (using iso-latin-1 maybe) as those characters. But it's not a clearly valid encoding of any Unicode. The most common standard for that would be UTF8, which this is not, for sure. iso-latin-1 is arbitrary and unlikely. You have to do something directly with those bytes. You seem to want to use the hexified bytes as uid, which is one way to go. – Henno Brandsma Sep 28 '18 at 21:50
  • @AlexandreBarfuhok to get the bytes do (on a UnixLinux command line) `echo 2cfNlD0JQtaeYgf5JjKXcg== | base64 -d | od -tx1 -An` e.g. Better: do it in Python for urlsafe decoding, e.g. – Henno Brandsma Sep 28 '18 at 21:54