Kartik
Kartik

Reputation: 39

How to generate a small encrypted output (around 16 Bytes) from 250 characters and a 16 byte key?

Is there any algorithm or method to encrypt 250 characters using a 10-16 byte key and the encrypted string's size remains less than 16 characters? I tried using AES 128/256 + DEFLATE, but the final encrypted string is quite large with respect to expected string length.

Thanks!

Upvotes: 0

Views: 2133

Answers (3)

Aki Suihkonen
Aki Suihkonen

Reputation: 20037

The algorithm you describe is keyed hash. Truncated Hmac/sha256 fits the specification, that is you only use the 16 first bytes of the produced hash. But of course, this is irreversible.

Upvotes: 1

Ian Boyd
Ian Boyd

Reputation: 256781

Technically you could do it, but it depends on your definition of "character".

For example, you might think Noël is four characters. But with Unicode it is actually five code points:

  • N + o + e + ¨ + l (where you use U+0308 Combining Diaeresis)

Combining diacritics are interesting; you can keep piling on diacritics. So while you still have four "characters", you have all kinds of extra code-points -

  • Noe˿̴̵̶̷̸̡̢̧̨̛̖̗̘̙̜̝̞̟̠̣̤̥̦̩̪̫̬̭̮̯̰̱̲̳̹̺̻̼͇͈͉͍͎̀́̂̃̄̅̆̇̈̉̊̋̌̍̎̏̐̑̒̓̔̽̾̿̀́͂̓̈́͆͊͋͌̕̚ͅ͏͓͔͕͖͙͚͐͑͒͗͛ͣͤͥͦͧͨͩͪͫͬͭͮͯ͘͜͟͢͝͞͠͡l

The above text is four "characters", but is 114 code points.

Adding diacritics gets you more information per character.

Next is the fact that Unicode has a large alphabet. If you expand your alphabet to the other planes, you can encode a lot of information. It's like base-64, but with base-195088.

For more information about cramming a lot of information into few "characters", see this stackexchange code challenge:

which is based off the Stackoverflow Twitter encoding challenge:

This all highly depends if you have 16 characters, or 16 bytes.

Upvotes: 1

Mark Adler
Mark Adler

Reputation: 112404

First off, you'd need try compressing before encrypting. If "AES 128/256 + DEFLATE" means encrypting before compressing, then you will never get any compression as encrypted data is effectively random to the compressor.

Second, even if you did, you wouldn't in general expect much compression on just 250 characters. Compressors need more data than that to look for patterns.

Third, you would not get a factor of 16 compression on anything but highly redundant data, even if you had a lot of data.

Upvotes: 2

Related Questions