Is it possible to calculate an encryption key when both the plain text and ciphertext are known?

Question

I have implemented an authentication system which works like this:

1. Upon successful login, the server takes the username of client and encrypts it with AES-256.

2. This ciphertext is stored in the client's browser and when the client wants to do something which requires login, this ciphertext is sent to the server. The server decrypts the ciphertext and obtains the username of the client who is logged in.

An attacker cannot breach a client's account because he/she doesn't know the encryption key, so it doesn't matter if the attacker knows the username. However, I'm worried if client's browser is exposed, the attacker will access both the ciphertext and plain text (username). Does this allow the attacker to "calculate" the encryption key given that both the ciphertext and plaintext are known? Because that key is used for all clients, so if it's exposed the entire system is ruined.

Answer 1

In answer to your main question, AES256 is secure as far as we know into the foreseeable future. However your authentication scheme has several drawbacks.

First, if any request where the token is sent is compromised, or if a the user installs a malicious addon that can grab the encrypted user name from their browser, that account is forever unusable. You are essentially creating a token to use for authentication that cannot ever be changed and that is a 1:1 relationship with the user name. The only way to deny access if it is compromised is to shut down the account and force the user to create a new account with a different username.

A much better way would be to generate a random token when the user authenticates and store that in the database, or generate a random value and encrypt that as the token. Then if the account is compromised or if the user wishes to 'log out', you can remove that token and generate a new one.

If your encryption key is ever compromised or if it is ever cracked somehow, the attacker can do anything as any user in your system. With a random token based approach, they would have to know the random part used to generate the token for each user. The attacker would have to have access to your database and your encryption key.

Answer 2

No. The attacker cannot obtain the encryption key from the plaintext and the encrypted text, because AES is resistant to known-plaintext attacks. See details in the answer on Crypto SE.

I'd suggest you to review your design. Making user name secret can lead to many problems. For instance, if user needs to report a problem, how can user tell user name if it is secret? Of if an administrator needs to change user permissions, how can the responsible person tell administrator what user needs to be changed, if the user name is secret? And so on. I'd suggest not to encrypt the user name.

So actually we have an XY problem here. Actually, an authentication token should be used to know who the user actually is. In such case encryption of user name is not needed and thus the question about AES and known-plaintext attack is not needed.

Answer 3

Would be bad form to ask "Why?"

There are plenty of free, open source, battle-tested authentication systems in place.

Unless you are expert in crypto engineering (and the fact that we are here shows otherwise), please don't invent your own system.

It's great messing around with code just to teach yourself, but don't take it further.

Answer 4

AES is secure against Known-Plaintext-Attacks (KPA) where an attacker has access to both plaintext and ciphertext. AES withstands attacks for more than 20 years and AES-256 is the golden standard that even AES-256 can beat the Quantum attack of Grover's optimal Search Algorithm. Even AES-128 is secure in the foreseeable future - except the multi-target attack..

Your authentication scheme is insecure as you noticed. You should either use

• standard password hashing with Scrypt, PBKDF2, or Argon2 with 128-bit random salt per user and users choose dicewire passwords for good strength against password searches.
• Or, use PAKE if that fits you.