AES in CTR mode, with a single key, and an IV derived from the plaintext We need a system to compare cipher-texts for equality, without (the checking system) having access to the plaintext.

We found a library that uses AES in CTR mode, with a single key, and an IV based on the SHA1 has of the plaintext.

This question is closely related to another question here on crypto.SE, but in our case the IV is derived by calculating a SHA1 has of the plaintext.

The plaintext in question are key value pairs, where the key is a short textual identifier and the value is a key. The total plaintext size is around 1k in bytes, and, additionally, but separately, SSH key files.

Would there by be any implications for the secrecy of the encrypted plaintext?
In the context, the IV is part of the ciphertext (as usual with AES in CTR mode). That part of the ciphertext leaks information about the plaintext including for one who does not know the AES key, which is bad in theory at least. This is because the (SHA-1) hash of the plaintext (or part of it) is the IV. In particular, an adversary can use a ciphertext to comfort a guess of the plaintext, by hashing the guess and checking if (the appropriate part of) that matches the IV.

One academic solution to the problem is a MAC of the plaintext, such as HMAC-SHA-256, with a secret key. This gives a short deterministic digest of the plaintext that does not leak any information about plaintext to adversaries not holding the key (beyond equality of two plaintexts, of course). That digest could be added as a prefix or suffix of the ciphertext obtained by AES-CTR or some other mode (authenticated encryption is a nice-to-have).

Using the same key for the encryption (authenticated or not) and the MAC is poor in theory, and could be disastrous with an AES-based MAC. However, with HMAC-SHA-256, the only foreseeable drawback would be that a key-recovery attack on HMAC (e.g. by some side-channel) would leak the encryption key; or vice versa.