0

I want to encrypt information like a password. AES requires a passphrase that will be used to encrypt and decrypt. If the passphrase is exactly the same as the message being encrypted, does this affect the strength of the encryption?

Rob
  • 13,342
  • 26
  • 40
  • 60
John Soandso
  • 21
  • 3
  • I suppose this question is theoretically interesting, but, practically, how could such an encryption be useful? Nobody could decrypt without the passphrase, but, if they have the passphrase, they do not need to decrypt. I suppose it might serve as a digest/hash/checksum. – Eric Postpischil Jul 19 '19 at 19:54
  • Well, I don't want to store passwords in plain text. I was thinking of going with AES because it is the standard for encryptions. It does require a passphrase, and it doesn't make sense for a user to type in a password for a password. – John Soandso Jul 19 '19 at 20:02
  • 2
    [Password storage should use iterated hashes and salts.](https://stackoverflow.com/questions/549/the-definitive-guide-to-form-based-website-authentication/477578#477578) – Eric Postpischil Jul 19 '19 at 20:06

1 Answers1

0

If the passphrase is exactly the same as the message being encrypted, does this affect the strength of the encryption?

Absolutely. It creates a 1:1 mapping of plaintext to cipher text, which is horrible, even if it weren't "encrypt with self." But compared to the ideal of storing a password, it's literally infinitely worse.

First, you need to remember that the AES keys must be precisely 16 bytes long. Nothing more, nothing less. So for your plan to make sense, we can only apply it to "passphrases" (I use those words in the weakest possible meaning) that are precisely 16 bytes long. That's not a particularly useful construction. But let's consider even that limited case.

You're going to store something E(x,x)) such that D(E(x,x)) == x. That's a tiny space, compared to all possible x (where x is exactly 16 bytes long), but why do I say "infinitely worse?" Because we're comparing it to storing zero bytes, which is the alternative. Since "x" here must be provided by the caller, there is absolutely no reason to store E(x,x). "E" is doing no work here. I could re-write the function D as:

D: (d, p) -> p

(where "d" is the cipher text and "p" is the password)

I literally can ignore the cipher text. It can be zero bytes long. It can be anything. I really don't care. And that would be better than any other conceivable encryption scheme, which would necessarily leak some information about p.

Nothing here gets better when we consider the case of "not 16 bytes long." In that case I need some kind of KDF (key derivation function). But the only reason I even needed that was because you injected "AES" which is doing no work here. A little fiddling on paper should hopefully convince you that D(E(KDF(x), x)) == x is no better than we started with.

This is an encryption system that does nothing. It only says "if I know X, the function will return me X." If I knew X already, why even call the function?

Anything that this would be useful for, any SHA-2 hash would be much better at solving.

Rob Napier
  • 250,948
  • 34
  • 393
  • 528
  • The AES script I am using is pretty interesting. It uses a salt that randomizes the encrypted message: 1. b'\xb9\xc5L\xf8\xc6l\xb9A-k\xa8E\x93\xc6\xda..|\xd5\xcal\xfc\xf9\xf5' 2. b'\xa0,i\xa7\xdaY[\xe6\x94" – John Soandso Jul 19 '19 at 21:19
  • That doesn't change anything. Your function is now `D: (d, s, p) -> p`. The salt does nothing in particular. – Rob Napier Jul 19 '19 at 21:23
  • I really appreciate your response. It was a yes or no question and you took the time to provide an explanation. I still don't fully understand and I plan on keeping at it until it clicks. I definitely plan on giving you internet points for your efforts. If I were to add a single character to the end of the passphrase, would that improve the strength of the encryption? Say it is E(password, password+H). – John Soandso Jul 19 '19 at 23:23
  • You can't add a character to an encryption key. AES doesn't work on a passphrase; it works on a fixed-length encryption key (128, 192 or 256 bits). Converting a passphrase into a key is the job of a KDF. So the answer here is no, because it's not a possible thing to do. But in any case, this approach isn't solving any problem. You seem to be trying to turn AES into a hash function, and if that's the goal, just use a hash function. What value is encryption if knowing the password means I already know the contents? Why decrypt? – Rob Napier Jul 20 '19 at 14:34
  • So, AES encryption/decryption typically happens on the servers end? The end goal is a website that has a chatroom that saves info on a MySQL server. I want to save the passwords on the database, but it can't be saved in plaintext. So, the website would hash the password and send that to the database to be encrypted. When someone goes to log in, the server decrypts the password, sends the hashed password to the user and it would check to see the two hashed passwords match? – John Soandso Jul 22 '19 at 20:01
  • "So, AES encryption/decryption typically happens on the servers end?" I'm not sure how that's related to this discussion. AES can be applied at any stage. You shouldn't save passwords in a database if you can possibly help it. There's no need for AES or encryption to check passwords (it's not clear here how the password is related to the database). If the goal is just to login, then what you want is PKBDF2 to salt and stretch the password, and then you store the SHA256 of that in the database. To authenticate, you PBKDF2 + SHA256 again. – Rob Napier Jul 22 '19 at 20:24
  • So on the client side, you call PBKDF2 on the on password with say 10k iterations. Then you send the result of that to the server. The server applies SHA256 to the result and puts it in the database. To login, repeat and check that they match. No need for AES, and no need for the server to ever know the password. – Rob Napier Jul 22 '19 at 20:25