This question already has an answer here:

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:


Thank you in advance for your help. Cheers.

marked as duplicate by AndrolGenhald, ThoriumBR, forest, Steffen Ullrich, S.L. Barth Sep 24 '18 at 12:03

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 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
  • 3
    if they are all the same length, it's more likely a hash than encyption – dandavis Sep 19 '18 at 18:21

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.

  • 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

Not the answer you're looking for? Browse other questions tagged or ask your own question.