# Is it OK to encode data using key equal to data

For some project, I need to store some short string in encrypted form. It would be ideal for the current purposes to encrypt it using itself.

# This would be the usual way:
result = AES_ENCRYPT(string, key)

# but I would like to do it this way:
result = AES_ENCRYPT(string, string)


The same string itself would be used as the key!

The 'string' is always some short text, like 20 characters of letters and numbers. This solution seems better to me than using any hash function, since hash could lead to collisions - different strings could potentially produce the same result, which is low probability, I know, but still not zero so I want to avoid that.

My question is, is my approach safe? Encoding the data using the data itself, does it lead to any security issue? Would it mean that it could be easier to decrypt the result, if the 'attacker' knows the fact it is produced by encrypting my way? Thank you.

• Your idea could also lead to collisions. $\;$
– user991
Jun 7 '15 at 11:09
• @TomasM Yes. The properties of AES do not preclude that possibility (though it would probably be quite hard to exhibit a colliding pair). Just because the AES encryption is reversible with any given key does not mean that A encrypted with A cannot equal C encrypted with C (since the keys are not the same). Jun 7 '15 at 12:15
• @yyyyyyy How so? If AES_ENCRYPT uses AES-128, then there are $2^{128}$ inputs (the valid inputs are exactly the valid blocks, since the key needs padding too) and $2^{128}$ outputs. Unless I'm missing something, it seems like the numbers work out (there will in fact be collisions, but it doesn't seem like that's a consequence of the pigeonhole principle). Jun 7 '15 at 12:55
• Wouldn't this turn AES into a true PRF resulting in the birthday paradox being applicable? This would mean 64 bit collision resistance instead of 128+ with SHA-2/3.
– SEJPM
Jun 7 '15 at 15:45
• @SOJPM : $\:$ No, since the OP's function does not take a key and anyone can evaluate it. $\hspace{1.04 in}$
– user991
Jun 8 '15 at 1:24

The chance of a collision is so low for SHA-2 that it is easily possible to prune some of the rightmost bytes output and still have a large security margin in case you need a smaller output. The number of hashes required a collision using SHA-256 is about $2^{128}$. I.e. that's about the same amount of tries as brute forcing AES-128. In the end you need to end up with at least double the amount of the required strength in bits.
• No, his scheme tries to turn AES into a one-way function, not a Pseudo Random Function. $\;$