To encrypt arbitrary-length messages and lengthy communications, symmetric cryptography is often used instead of (or with) asymmetric cryptography. This is because it is fast. Unfortunately many protocols forget that encryption is not enough, as attackers can still tamper with the ciphertexts in order to modify the underlying plaintext. To add integrity, we often use an additional Message Authentication Code (MAC) or better, an all-in-one encryption + integrity primitive called authenticated encryption.
No. Integrity of the ciphertexts must be ensured. For this use an authenticated encryption cipher like AES-GCM.
No. See Wikipedia).
If used without an integrity protection mechanism, no. This is what AES-GCM is: AES with the CTR mode of operation protected by the Galois Message Authentication code (GMAC).
see BearSSL
TKTK
AES comes with three types of keys: 128-bit, 192-bit and 256-bit; while most implementations will only support 128-bit and 256-bit keys. It is accepted that 256-bit keys provide unecessary security, unless you are trying to market your application as having military-grade encryption.
No. AES-GCM is not nonce mis-use resistance. If nonces are repeated, the authentication key can be extracted which will destroy the integrity of future ciphertexts. This has been demonstrated live in the past, for example with Nonce-Disrespecting Adversaries: Practical Forgery Attacks on GCM in TLS. For nonce-misuse resistance check AES-GCM-SIV
96-bit
If the nonce used by AES-GCM is of standard size 96-bit, 2^96 messages can be encrypted. In practice, this means that you can pretty much encrypt an infinity of messages.
AES-GCM uses a counter to encrypt blocks of 128 bits, the blocksize of AES. If the nonce used by AES-GCM is of standard size 96-bit, a counter is 32-bit wide. This means that at most 2^32 * 128 bits ~ 68.7GB can be encrypted without repeating the nonce.
No. An IV cannot be repeated nor be predictible, this is what gave rise to attacks like the BEAST.
As no IV should repeat in AES-CBC, it is important to limit the number of messages being encrypted with it. As an IV is 128 bits, sweet32 says that after 2^(128/3) messages it starts becoming dangerous to encrypt more messages. In order to circumvent that change the key at that point.
128-bit of security is what most applications aim for nowadays. AES-256 provides around 256-bit of security and is often called "military-grade encryption" for marketing purposes. It is often used in conjunction with key exchange algorithms providing 128-bit of security and is thus not increasing the security of the protocol compared to AES-128.
No. It's easy to create two keys that will decrypt the ciphertext to two different messages with AES-GCM. See https://eprint.iacr.org/2019/016
No. The Day DES Died is a nice paper summarizing the situation.
Yes and no. Triple DES (or TDES, or EDE) is a 64-bit block cipher providing 112-bit of security at most, it should provide enough security in most settings, but because of the 64-bit block size it is not perfect as shown by the Sweet32 research paper from Karthikeyan Bhargavan and Gaëtan Leurent (see a video explanation here).
If you are in a situation where:
Nonetheless, attacks only get better with time, and you are encouraged to deprecate this algorithm.
No. RC4 has been found to have multiple biases in its keystream. This means that whatever the key used, some bits of the keystream will statistically more often appear as 0s or as 1s. Attacks taking advantage of this have been made practical by numerous research papers:
The most recent attack, RC4 NOMORE retrieves a 16-byte cookie in 50-75 hours. This works well with cookies and HTTPS because they are repeatedly encrypted and there are approachable ways to trigger a client to send requests, but any protocol making use of RC4 and repeatedly encrypting the same secret should be vulnerable to these attacks. For example, an HTTP connection tunneled through SSH would be vulnerable to the exact same attack.
RFC 7465 contains a list of TLS cipher suite that are to be depreciated