It is safe to reuse AES-CTR IV (or not use one at all) in some theoretical situations, including when all except one plaintext are uniformly random and independently chosen. However, that's unsafe in most practical situations, including when an adversary knows the general nature of the plaintext (or guess it among several standard use cases), and there are a number of ciphertexts. Don't reuse IV, at least with the same key.
For any block cipher in CTR mode, it is typically extremely dangerous to reuse the same key and IV (even if secret). That's because the encryption ends up to be XOR with a fixed keystream (a bitstring) dependent on key and IV. Even though the keystream is initialy secret and indistinguishable from random (for an adversary not knowing the key), the keystream can be recovered (and all ciphertext deciphered) under many plausible assumptions, including:
- Adversary knows one plaintext.
- Adversary knows the ith bit of the ith plaintext.
- Adversary knows some general characteristic about the plaintext; and there are a enough ciphertexts.
The first and arguably second bullets are excluded by the question, but the third applies to nearly all practical use cases except super-encryption of already enciphered data, when there are enough ciphertexts.
The crudest, but still sometime effective method to find the keystream is to determine the expected mean value of the ith bit of plaintext (which is a function of the kind of plaintext and of i, independently of the actual plaintext, which is unknown). If that deviates enough from 1/2 in either direction (as it does for many practical kinds of plaintext), and enough ciphertext is available, comparing this expected mean to the actual mean for the ith bit in the ciphertext will often reveal the ith bit of the keystream (it is expected that the means are on the same side of 1/2 for a keystream bit of 0, and on different sides for 1).
Inter-bit dependencies in the plaintext allows much faster recovery of the keystream. If plaintext is known to be English text in ASCII, a handful of ciphertexts will typically allow to recover nearly all of the keystream. Even if the plaintext was email addresses, there is enough redundancy in that to allow to find the keystream from a few hundreds ciphertexts.
If database entries are never modified and have a key index that wont vary, a common and safe solution to the problem of IV choice and availability for decryption is to use as initial counter value the index shifted left by a constant large enough that the counter values will not overlap from one database entry to the next. For AES-CTR, that shift count constant can be as small as the number of bits in the maximum plaintext size in octets, minus 4. For 64 gigaoctet of maximum plaintext size, shifting left by 32 over 128 bits is fine. We can thus append 4 zero octets on both sides of an 8-octet binary representation of the index (without having to care about endianness, unless that's mixed) to set the initial counter value (which, depending on implementations details, may or may not be the IV; actually, many implementations with an IV less than 16-octet internally append zeroes on the appropriate side).
While other modes of operation (like CBC) significantly mitigate the danger of IV reuse, that's still extremely dangerous in some scenarios.
