6
$\begingroup$

In Cryptography Engineering Bruce recommends using "rand IV CBC mode" but the copy of the book I have is from 2003 and I am unsure if this is still a recommended practice with all the recent attacks discovered on various CBC implementations.

Is there a better choice then CBC mode?

I am writing a program that will be using a block cipher to encrypt a file locally. This is for a personal academic project.

Assume the following

  • The block Cipher I am using is Threefish512 so GCM is not viable as it is only defined for 128-bit block ciphers
  • The block cipher I am using is not supported by any modern crypto libraries (I am aware of) so I will be implementing this mode of operation myself
  • The file is relatively small and the encryption/decryption of it is only done periodically so security is preferred over speed and parallelization ability
  • The computer doing the encryption has not been physically compromised
  • I have access to truly random numbers for IV generation
  • This encryption will not be part of direct network communications so an attacker will not have access to input whatever they want into the cipher.
  • A mode that offers authentication is preferred
  • The details required to implement this mode of operation are in the public domain and not encumbered by any software patents
$\endgroup$
  • $\begingroup$ Don't roll your own crypto. I'd consider just using GnuPG. $\endgroup$ – Luis Casillas Feb 2 '17 at 1:53
  • 2
    $\begingroup$ why would you use Threefish instead of Twofish or AES? $\endgroup$ – Richie Frame Feb 2 '17 at 2:01
  • 1
    $\begingroup$ Don't know if you have read this, but you might be interested. $\endgroup$ – mikeazo Feb 2 '17 at 3:25
  • 3
    $\begingroup$ Also, you should read this if you haven't already. $\endgroup$ – mikeazo Feb 2 '17 at 3:32
  • 8
    $\begingroup$ Your assumption that Threefish will remain strong for longer since it has longer keys is, in my opinion, misguided. If there are no algorithmic breakthroughs, then 256-bit security will be strong enough well after we are our great-grandchildren dead. Thus, the most important thing is the algorithm. AES has been studied in much greater depth and put under much more scrutiny than other algorithms, and so our confidence in its security is much higher. $\endgroup$ – Yehuda Lindell Feb 2 '17 at 5:54
6
$\begingroup$

You should use an authenticated encryption mode.

My personal current favorite is SIV mode, originally introduced by Rogaway & Shrimpton (2006) and standardized (for use with AES) in RFC 5297.

The major advantage of modes based on the SIV construction (such as SIV mode itself, as well as e.g. GCM-SIV) is that, unlike most other encryption modes, their security will not fail catastrophically even if the nonce/IV is accidentally reused. This eliminates one of the few remaining "weak points" of modern authenticated encryption modes. CBC mode also has this property to a limited extent, which I believe is the main reason why Schneier's book recommends it, but SIV is much better in that regard, and, as an authenticated encryption mode, also resistant to a much wider range of attacks.


The main disadvantage of SIV mode is that it's a two-pass mode: encryption requires first computing a MAC over the plaintext, and then using that MAC output as a "synthetic IV" to encrypt the data. If you want to encrypt large files, you may wish to use a "chunked SIV" mode. There is, as far as I know, (unfortunately) no standard for that, but the basic idea is to:

  1. Split your file into chunks of, say, 1 MB.
  2. Encrypt each chunk using SIV mode, and concatenate the resulting ciphertexts.
  3. For each chunk, include any relevant parameters such as the total size of the file, the chunk size used, the number of the current chunk and, importantly, the "synthetic IV" of the previous chunk as associated data. (At a minimum, if you don't know the size of the file in advance, each chunk should have as associated data its number, the previous chunk's synthetic IV and a flag indicating whether or not this is the last chunk.)

This "SIV chaining" should ensure that, if every chunk of the encrypted file can be successfully decrypted, this not only guarantees the integrity of the individual chunks, but also of the entire file (i.e. that no chunks have been added, removed or switched around).

$\endgroup$
  • $\begingroup$ I am calling this the solution because you offered the most detailed answer and included the reasons and drawbacks of your choice. I am considering both SIV and OCB mode. SIV mode is easier to implement but like you said it is two pass and I am not sure I wanna deal with the overhead of passing all the data twice when there is a one pass solution (OCB mode). $\endgroup$ – K3rb3ros Feb 5 '17 at 3:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.