6

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
Ilmari Karonen
  • 46,120
  • 5
  • 105
  • 181
K3rb3ros
  • 143
  • 4
  • Don't roll your own crypto. I'd consider just using GnuPG. – Luis Casillas Feb 02 '17 at 01:53
  • 2
    why would you use Threefish instead of Twofish or AES? – Richie Frame Feb 02 '17 at 02:01
  • The largest version of AES (as well as Twofish) only supports key sizes of 256 bits and there are several existing side channel attacks against various AES implementations. While still practically secure I doubt AES will be 5-10 years from now. Twofish is also quite slow. Neither of these ciphers meet my intended use case of fast future proof (>512 bit key and state size) encryption. Threefish has implementations with 256, 512, and 1024 keys size and was optimized for performance on 64 bit processors. – K3rb3ros Feb 02 '17 at 02:32
  • 1
    Don't know if you have read this, but you might be interested. – mikeazo Feb 02 '17 at 03:25
  • 3
    Also, you should read this if you haven't already. – mikeazo Feb 02 '17 at 03:32
  • Apparently the license for OCB allows unlimited non-commercial non-military use. So I am going to use OCB. – K3rb3ros Feb 02 '17 at 04:02
  • 8
    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. – Yehuda Lindell Feb 02 '17 at 05:54
  • When I was looking into doing something similar like you, I've made this question which you may find very useful. (I was looking for a mode that uses tweakable block ciphers to have some nice additional features like nonce-misuse-resistance) – SEJPM Feb 02 '17 at 11:45
  • @K3rb3ros I've changed the title to include Threefish and file encryption. You can avoid the chance of comments about "not rolling your own crypto" that way as well - to a certain degree anyway. You can always simply ignore such comments as well. Answers that only contain "don't roll your own crypto" you can simply downvote. Avoid negative statements in your question though. – Maarten Bodewes Feb 02 '17 at 12:13

1 Answers1

6

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).

Community
  • 1
Ilmari Karonen
  • 46,120
  • 5
  • 105
  • 181
  • 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). – K3rb3ros Feb 05 '17 at 03:57