Is it safe to encrypt a string using same string as key?_问答_开发者

Are there any security downsides in encrypting a given key with itself using AES in CBC mode, and using an IV (of course)?

The principles are respected: the key is secret, and the IV is public (as this does not affect security of encryption).

However, a potential attacker will know (as he can access the source code), that the string is encrypted using itself as the key.

My judgment does not see any problems, but I'm trying to make sure.

Thank you.

EDIT - details of the task, I hope I'll be able to pass them across clearly, it's not yet very clear for myself:

My system uses encryption to store certain values in MySQL tables. Encryption is performed on the PHP code (not the MySQL built-in AES). Obviously, I need a secret key, which needs to be setup by the system admin, just ONCE, at system setup. This is critical, because changing the key after any encrypted data has been saved as such, will make that data un-decryptable.
Admin can setup secret key by simply editing a PHP script file via FTP (or whatever). But that's not what I want.
What I want is having a install script, during which the admin choses the secret key, which gets encrypted with itself and stored into a table. Granted, a valid point that has been made below, is that you'd need the key to decrypt the key... I didn't get as far in my reasoning, I was at the stage of investigating if encrypting a key with itself开发者_开发技巧 as key is still a secure thing.

If you have any ideas regarding the above, it'll be much appreciated.

Thanks.

The question is, what is the point? If you want to decrypt the string, you must know the string already; if you don't know it, you shouldn't be able to decrypt it. It's possible but pointless IMHO.

Encrypting the key with itself is basically an ad-hoc hash function. So you could use a real one instead.

As you mentioned in your comment in Jesper's answer, "strength resides in the encryption key" and in the encryption algorithm. If both are strong, it should be safe. As far as I know, the technical weak link of a strong encryption and key is in the implementation, if any.

Interested to know what application are you going to use this method for, if you can say it.

Edit This is not exactly answering the question in the post's title, but I suppose it's relevant to your updated post:

Assuming a strong and correctly implemented AES with CBC and IV, and that the attacker can access the table where you store the encrypted master key.

There should be little security difference whether you're storing an encrypted master key using itself, or storing the cryptographic hash of the master key. Assuming both the cryptographic hash and AES in CBC mode are equally secure, the strength lies in the strength of the master key.

If the master key is weak, even if an attacker cannot get the master key from the cryptographic hash of the master key, he'll be able to get the master key and hence the "certain values" via the "certain values" table. If using a master key to encrypt itself, he can get the master key via the "certain values" table or the master key table.

Whether you opt to use the same cipher to encrypt and store the master key or cryptographically hash and store the master key, make sure the master key is strong. Seems like you're writing some open source system. My suggestion is that your system checks any potential master key against a regular expression (or a function), and reject that key if it is deemed to be not strong enough.

I hope I have understood your post correctly as well.

Disclaimer: I'm not a security expert nor in the security industry.

First: Not really security expert

So to get this currently, you want to store a secret value, and only be able to get the secret value, but telling it the secret value? :)

But I can see where you want to go with this, for a password system (perhaps), you can then just validate them together.

Some downsides can be, that if the hacker gets access to all the users passwords, and the hacker has a account with a password he can remember, then he can very easily spot your encryption logic. He can after that, just make a dictionary attack, and get a lot of passwords. For that I would a least consider using a unique hash for each record. Then he can still dictionary attack, but it will take way longer. Then also add a custom hash stored deep in your application, so he need to guess that as well, or have access to the application code.

So I've would at least recommend a key that is a composite of password+record_hash+shared_hash

UPDATE: I can see that the hacker will have access to code, then try to store the shared_hash a place he cannot access.