Score:1

Which block cipher modes are best used in real life situations?

sa flag

For an exam I'm studying for, I'm wondering what block cipher modes are best to use in certain situations.

We learned about these block cipher modes: ECB, CBC, CFB (+ s-bit), OFB (+ s-bit) and CTR.
From what I understand: some can be parallized, some can't. Some can be turned into a stream cipher (s-bit), some can't. Some have worse error propagation. They each have their (dis)advantages.

My question is, which block cipher methods are preferred in certain situations, for example for video chats, to store passwords, to send data with a micro-controller, ...

kelalaka avatar
in flag
Welcome to Cryptography.Se This is rather a wide question that cannot be answered completely.
sa flag
Well, there's a great chance my professor will still ask me this on the exam, and I will need to provide an answer... For example, to store passwords, it's a really bad idea to use ECB because equal blocks get encrypted in the same way. I'm looking for other clues like that.
kelalaka avatar
in flag
For passwords, we don't encrypt we use password hashing algorithms, this is the correct answer. See [How to securely hash passwords?](https://security.stackexchange.com/q/211/86735). If you insist on encryption then how do you keep the encryption key safely?
SAI Peregrinus avatar
si flag
IMO, one of GCM-SIV, GCM, OCB, CTR, or XTS for encryption (not password hashing). OCB is fastest but not as widely supported (it was patented until recently) and not nonce-misuse resistant, GCM-SIV is good for most uses and is nonce-misuse resistant but is 2-pass, GCM is common but not nonce-misuse-resistant, XTS doesn't authenticate and is thus weaker but doesn't expand ciphertext so it's used for full-disk encryption, and CTR is a building-block for authenticated modes and occasionally used where authentication is provided at another level of a protocol. The rest are much less useful.
Swashbuckler avatar
mc flag
@kelalaka Sometimes we do encrypt passwords, it depends on what the password is being used for. If it's being used for us to authenticate then we don't, if we're storing the password to authenticate to something else then we do encrypt.
kr flag
@kelalaka: "*For passwords, we don't encrypt we use password hashing algorithms*" - This is true only in one case, when passwords are needed to authenticate user. But when user stores passwords in password manager, then of course these passwords or normally the whole password database is encrypted, e.g. with AES-256. If one wants to develop a password manager, it is very important what mode to chose.
kelalaka avatar
in flag
Yes, I've only considered the authentication. Did not mention other usages where one needs the password rather than the hash value.
cn flag
ECB is a bad choice for anything. Unless you can guarantee, the same message is never sent twice with the same key. This is a restriction on the messages - and it's better to avoid that.
Score:1
ng flag

In real-life situations, except for compatibility with existing systems, it seldom should be directly used any of the encryption modes listed in the question, because they at best provide secure encryption (caveat: ECB does not), which does not cover the needs of most real-life situations.

In real applications, if one needs encryption, one also typically needs to prevent undetected alteration of the message (e.g. removing part of it, altering a segment). Thus it's needed a mode that provides encryption and authentication¹, such as GCM combined with the block cipher AES. It's fast enough for "video chats" with a modern CPU and simple enough to "send data with a micro-controller".

Such authenticated encryption mode will often internally use one of the question's mode for the encryption that it provides, e.g. GCM uses CTR. ECB/CBC/CFB/OFB tends to be phased out for CTR, because CTR is simple, fast, easily parallelizable, and allows direct read/modify/write access to large files without re-encrypting what follows. It's only drawbacks are

  • Malleability², but that's entirely solved by authenticated encryption.
  • Sensitivity to reuse of Initialization Vector/nonce. This can be mitigated by good procedures to generate IV, or nonce-misuse-resistant authenticated encryption modes like GCM-SIV.

To "store passwords", we often don't want to use encryption, which implies the possibility of decryption, when we often can live with a system that never requires to decrypt passwords and thus is less vulnerable to data leaks (there are some exceptions like password managers). For passwords, the first choice is secure hardware designed for passwords storage. The second choice is to store on disk the result of a deliberately slow and salted hash function of the password, like Argon2. The last choice is authenticated encryption of the password. Notice authentication matters: with encryption alone, it's to fear that someone with read/write access to the encrypted passwords can reset a user's password to a known one, without the key, if they know the password of another user.


¹ In the sense that deciphered plaintext exactly matches plaintext that was encrypted with the encryption key, which make it authentic.

² In the sense of allowing changing the meaning of deciphered plaintext for known plaintext, e.g. change pay $1000 to pay $9800. CBC or CFB mode make such attack more difficult, but do not provide full authenticated encryption.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.