# If an attacker has a chosen-plaintext and encrypted data, can they determine the encryption type?

This question differs from How to determine what type of encoding/encryption has been used?, which asked about a ciphertext-only attack. This question is asking about a chosen-plaintext attack.

Let's say an attacker was trying to perform a chosen-plaintext attack on an encrypted password server. This attacker is an internal employee with their own registered account. They can:

• Specify an arbitrary plaintext password for their account.
• View encrypted ciphertext passwords saved to the server.

This attacker doesn't know what encryption method is being used, whether passwords are salted, or what key is being used. However, they notice that the encrypted passwords are always the same number of characters (64).

Using their chosen plaintext and encrypted passwords, could an attacker determine what type of encryption was used?

## migrated from security.stackexchange.comJan 16 '18 at 16:12

This question came from our site for information security professionals.

• Will you have a big problem when the attacker finds out what hash you use? If so, you already have a big problem no matter what other circumstances might be. – John Dvorak Jan 9 '18 at 20:03
• There's quite a few sites out there (and even some utilities like hashcat has it built-in) that can determine what hash it is or it thinks it is. Most hashes have some sort of signature. That said, it doesn't really matter if the attacker knows the algorithm. – Nathan C Jan 9 '18 at 20:05
• @NathanC To clarify, these would be encrypted passwords, not hashed passwords. – Stevoisiak Jan 9 '18 at 20:07
• Possible duplicate of How to determine what type of encoding/encryption has been used? – Nathan C Jan 9 '18 at 20:09
• @NathanC The proposed duplicate assumes the attacker only has the final ciphertext, as opposed to being able to experiment with a chosen-plaintext. – Stevoisiak Jan 9 '18 at 20:11

In fact, good password hashing libraries do not try to hide the used algorithm but document it instead, because it allows to transparently change to a better algorithm without knowing the user passwords: when a user tries to login, the library looks at the registered hash and uses the documented algorithm to compute the hash from the clear text password. If then do not match, login is rejected. If they match and the algorithm is the current one, access is granted and nothing more happens, but if they match and the algo is not the current one, a new hash with the current algo is registered. For example, Modular Crypt Format prepends the hash with $digit$ where digit is (from man crypt):

       1.   MD5
2.   Blowfish
3.   NT-Hash
4.   (unused)
5.   SHA-256
6.   SHA-512

Other crypt formats may be easily added.  An example salt would be:

$4$thesalt\$rest


If you are in that case, only one single hashed password is enough to know the used algorithm, and it is not a security problem, provided the algorithm is non invertible.

• This answer seems like it kind of goes around the question entirely. Its a good thorough answer, but to a different question. I feel that this interpretation of "encrypted data" is rather broad. I think this answer isn't quite in the spirit of OP's question. – Adonalsium Jan 12 '18 at 14:45
• @Adonalsium: What leaded me to that is OP speaking of encrypted passwords in its (bold) question. Whether it is what OP really wanted I cannot be sure... – Serge Ballesta Jan 12 '18 at 14:50

As explained in that other answer, for password "encryption", the algorithm is usually part of the "encrypted password". And even if it is not, unless the algorithm has a secret key (called pepper in that context) or an otherwise secret component, password verification is deterministic, thus a known password and matching "encrypted password" allows to confirm or infirm a guess of the algorithm with near certainty (chosen password is not even needed).

Using their chosen plaintext and encrypted passwords, could an attacker determine what type of encryption was used?

is: yes if the "type of encryption" is among a list of candidates and uses no secret component (no pepper/key); likely no otherwise, unless of course headers or size considerations allow to narrow down the list of candidates.

The question's title makes no reference to password, and it seems to be for a cipher (at least that's how it sounds on CSE).

If an attacker has a chosen-plaintext and encrypted data, can they determine the encryption type?

The answer to that is no, for common modern symmetric ciphers with unknown key, and unless the encryption type is apparent from non-encrypted data (which is common for interoperability reason; also, the habit of putting the date/time before the ciphertext could be a telltale sign). That's because common modern symmetric ciphers have their ciphertext essentially undistinguishable from random data of the same length, for one without the secret key. This in turn is because that's the best and most common way to be secure under Chosen Plaintext Attack while making the ciphertext as compact as possible (as compact as the plaintext within essentially constant overhead). The only thing an adversary could probably determine is the block width for algorithms where there is one (such as a block cipher in CBC mode), by observing the relation between plaintext length and ciphertext length.

If the algorithm's secret key leaks, then a guess of the algorithm can be checked. And some symmetric algorithms can be guessed; but that's a sign of insecurity or non-optimality, and standard algorithms are not of that kind.

Things are different for asymmetric encryption algorithms. For many common ones (including RSA), it is possible to recognize the algorithm from the ciphertext, especially with the public key known (and as the name implies, that is assumed known to all). Essentially, that's because asymmetric encryption algorithms do not try to have their ciphertext indistinguishable from random or/and as compact as possible, and thus leak identifying information (even when they are secure under CPA, a desirable and common goal). For some algorithms, known or chosen plaintext may help.

Note: Determining the algorithm is out of scope of modern cryptography, which assumes that the algorithm is public, by the second Kerckhoffs principle. Thus the question's topicality on CSE is debatable.