2
$\begingroup$

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?

$\endgroup$

migrated from security.stackexchange.com Jan 16 '18 at 16:12

This question came from our site for information security professionals.

  • 2
    $\begingroup$ 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. $\endgroup$ – John Dvorak Jan 9 '18 at 20:03
  • $\begingroup$ 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. $\endgroup$ – Nathan C Jan 9 '18 at 20:05
  • $\begingroup$ @NathanC To clarify, these would be encrypted passwords, not hashed passwords. $\endgroup$ – Stevoisiak Jan 9 '18 at 20:07
  • 2
    $\begingroup$ Possible duplicate of How to determine what type of encoding/encryption has been used? $\endgroup$ – Nathan C Jan 9 '18 at 20:09
  • $\begingroup$ @NathanC The proposed duplicate assumes the attacker only has the final ciphertext, as opposed to being able to experiment with a chosen-plaintext. $\endgroup$ – Stevoisiak Jan 9 '18 at 20:11
3
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ 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. $\endgroup$ – Adonalsium Jan 12 '18 at 14:45
  • $\begingroup$ @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... $\endgroup$ – Serge Ballesta Jan 12 '18 at 14:50
2
$\begingroup$

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).

Thus the answer to

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.

Note: password "encryption" might not be worth the name encryption, because for any half-decent method there is intentionally no decryption procedure beside trying all passwords. At least, password "encryption" is not performed with a cipher. Common terminology is not "encrypted password", but hashed password or password hash. And even that is somewhat misleading, since hashing a password with a standard secure cryptographic hash function is not a secure way to compute a password hash. We want a special hash intended for passwords (entropy-stretching or password-based key derivation), and that needs extra inputs beyond the password: random salt, perhaps secret pepper, and parameter(s) controlling the work involved (number of iterations, and for modern methods amount of memory, number of threads..).


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.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.