Can we use symmetric-key algorithms without an initialization vector?
I am making an app where both the sender and receiver share a key and there is no way to create an initialization vector for each encryption. So I was thinking about setting the initialization vector to NULL while encrypting. Am I allowed to set the IV to NULL or can I use symmetric-key algorithms without an initialization vector?
If you really can't use an IV (why?), then just about the best thing you can do is use something like SIV mode (RFC 5297). SIV is a "maximally misuse-resistant" authenticated encryption mode which provides the following characteristics:
If every message is tagged with a unique nonce, SIV provides full IND-CCA2 security (up to the usual limits; i.e. it still leaks the length of the message).
Without a nonce, SIV remains IND-CCA2 secure as long as the same message is never encrypted twice (with the same associated data, if any).
If a message is encrypted twice without a nonce (or with an accidentally reused nonce), the only thing an attacker can learn is that those two messages are the same.
The down side of SIV mode is that it's a two-pass encryption mode: the encryption code must process the message twice. Thus, it is best suited for fairly short messages that can be held entirely in memory. Basically, on the first pass, SIV computes a secure message authentication code of the plaintext and any associated data (including the nonce, if provided); on the second pass, the message is encrypted using conventional CTR mode encryption, with the MAC from the first pass used as a "synthetic IV" (whence the name of the mode).
Also, to allow the message to be decrypted (and its authenticity verified), the 128-bit MAC/IV must be transmitted along with the message. Thus, SIV adds an unavoidable 16-byte overhead to each message, and is therefore not suited for format-preserving encryption. Of course, the same is true of every authenticated encryption mode, and indeed of every mode capable of providing semantic security, whether authenticated or not.
Probably not safely and in the way you mean. The NULL IV is completely unsafe.
There are deterministic encryption schemes used for things like searchable encryption, de duplication/convergent cryptography, and key wrapping. They leak a lot of data about the underlying file you are encrypting. In general, they are not safe for generic use. Don't use them.
There are systems that don't use an IV, but use something else. An IV must be unpredictable and unique. As such you must send a fresh one with every message. A nonce, short for number used once, has the sole requirement that it only be used once. It can be predictable. Both OCB and Counter Mode require only a nonce. You could, for example, keep a counter on both ends along with the key and increment it every time to derive your nonces.
However, great care must be taken to ensure you don't reuse a nonce (i.e. if your counters get out of sync or something). In practice, it's way easier to just prepend the cleartext random nonce/IV to the front of the cipher-text and send it. Why exactly in your case is this not possible? Are your cipher text's limited in length?
am making an app where both the sender and receiver share a key and there is no way to create an initialization vector for each encryption.
I don't know your constraints, but if the problem is difficulty with random number generation, then it may help to know that you don't have to randomly generate the IV, it's perfectly valid to create an IV by encrypting a unique number using the key and using the result as the IV.
If transporting the IV is a problem, the unique number could even be a counter that both sides maintain and use to derive the IV at encryption/decryption time.
No, you can't.
A symmetric encryption scheme without a random IV is not sure at all. The scheme is deterministic.
from wikipedia:
In cryptography, an initialization vector (IV) or starting variable (SV)1 is a fixed-size input to a cryptographic primitive that is typically required to be random or pseudorandom. Randomization is crucial for encryption schemes to achieve semantic security, a property whereby repeated usage of the scheme under the same key does not allow an attacker to infer relationships between segments of the encrypted message. For block ciphers, the use of an IV is described by so-called modes of operation. Randomization is also required for other primitives, such as universal hash functions and message authentication codes based thereon.
Some cryptographic primitives require the IV only to be non-repeating, and the required randomness is derived internally. In this case, the IV is commonly called a nonce (number used once), and the primitives are described as stateful as opposed to randomized. This is because the IV need not be explicitly forwarded to a recipient but may be derived from a common state updated at both sender and receiver side. (In practice, a short nonce is still transmitted along with the message to consider message loss.) An example of stateful encryption schemes is the counter mode of operation, which uses a sequence number as a nonce.
The size of the IV is dependent on the cryptographic primitive used; for block ciphers, it is generally the cipher's block size. Ideally, for encryption schemes, the unpredictable part of the IV has the same size as the key to compensate time-memory-data trade-off attacks.[2][3][4][5] When the IV is chosen at random, the probability of collisions due to the birthday problem must be taken into account. Traditional stream ciphers such as RC4 do not support an explicit IV as input, and a custom solution for incorporating an IV into the cipher's key or internal state is needed. Some designs realized in practice are known to be insecure; the WEP protocol is a notable example, and is prone to related-IV attacks.
