-1

I wonder if there is any kind of publicly known encryption (not hashing) algorithm that generates constant number of characters independent of the input.

I have came across an online platform that generates tokens (27 char Base64 string) depending on user's email and password ,which the user can use to login instead of email and password combination, but for the same email and password user can generate so many number of tokens.

There are two theories in my mind to achieve this.

  • Save all generated tokens along with user's email and password in a specific table in database then use them to check for user's credentials. but this does not seem to be an efficient way, and it's meaningless to save ALL tokens
  • Encrypt user's email and password along with some salt, then decrypt the provided token and use the decrypted credentials to log the user in.

Token Example

nsBpqEYfFFemSvZqE5Sn4dqwrLI

Abood Nour
  • 46
  • 3
  • 1
    The option you think would not be very efficient actually seems to me like it would be significantly more efficient than the option to use encrypted credentials to log the user in. Particularly if password storage is done correctly with a slow hash. – Xander Dec 30 '15 at 23:20
  • @Xander Maybe. But if this is the case I don't find it necessary to keep all generated tokens in the database especially ones generated with old passwords. The thing that makes me guess they use encryption method is that if you have generated a token using password X then changed the password you can not use the same token to login but if you changed your password back to X you can log in without any troubles. – Abood Nour Dec 31 '15 at 00:38
  • @Xander Also I don't find it necessary to save email and password along with token then use them to log user in. They could have simply tied the token column with userID since tokens should be unique. P.S. They use md5 hash to encrypt password, so slow hash theory is not the reason behind this vector. – Abood Nour Dec 31 '15 at 00:39
  • 1
    If you're asking how this specific platform does it, that's an impossible (and not particularly useful) question. Nobody without knowledge of what the platform is, and how it works internally would be able to answer. In general though, the architectural approaches you could take are nearly endless. The password is irrelevant, you only need to tie tokens to the user, which I think is what you're getting at in your last comment. – Xander Dec 31 '15 at 00:45
  • But in that case, whether it decrypts to the UID with a custom IV per token, or whether the token is random and persisted somewhere is somewhat immaterial, although the encryption approach is considerably less flexible as it ties you to a specific key long-term. – Xander Dec 31 '15 at 00:46
  • @Xander I do agree with you. I was just curious to know if the encryption technique is even possible without adjusting email and passwords. I mean if we encrypt emails of different lengths with their hashed passwords (same length of all), Is there an algorithm that would return cipher of the same length for all of them? – Abood Nour Dec 31 '15 at 01:05
  • 1
    Abood, how could any algorithm convert arbitrary sized input to a reversible, fixed size output? Mathematically, it is nonsensical. – Neil Smithline Dec 31 '15 at 02:18
  • Yes, under the conditions that @StackzOfZtuff specifies in his answer. As long as the ciphertext is uniformly padded to a length that accommodates any possible candidate plaintext. No, if the length of a candidate plaintext is unbounded. – Xander Dec 31 '15 at 03:30
  • @NeilSmithline I have no idea, that's why I asked ^_^ – Abood Nour Dec 31 '15 at 09:36
  • @Xander Thank you! You have really been of a great help ^_^ – Abood Nour Dec 31 '15 at 09:38

1 Answers1

1

Sure. All block ciphers encrypt a full block of input to a full block of output. (E.g. in all 3 versions of AES the block size is 128 bits, or 16 octets/ASCII characters.)

And if you have less than the full 16 bytes in your last input block then you just the input through one of the many padding schemes before you encrypt and again after you decrypt.

Using padding you can blow up the input and correspondingly the output to any size you like. (No way to shrink it to any wanted size, though.)

But without looking at the code that generates those tokens I think we can only make more or less educated guesses about the meaning of those tokens.

StackzOfZtuff
  • 17,783
  • 1
  • 50
  • 86
  • What I understood is that we can adjust input (for example email:pass in this case) to be of a certain length before encryption if it's small enough but if it's large then the encrypted cipher will be large as well. Have I got it right? – Abood Nour Dec 31 '15 at 01:10
  • Yup. Always easy to make input larger. [Impossible to generally shrink it without information loss.](https://m.reddit.com/r/explainlikeimfive/comments/38ezne/eli5_why_cant_we_compress_a_file_infinitely_until/) – StackzOfZtuff Dec 31 '15 at 07:42
  • Thank you! I am totally convinced. I am just curious to know is there a possible way to reverse the algorithm or at least have a clue about what encryption algorithm is used assuming that we have many generated tokens. – Abood Nour Dec 31 '15 at 09:46
  • No. Not in the general case. (Which is just what you want from good encryption: indistinguishable from random noise.) – StackzOfZtuff Dec 31 '15 at 15:22