[Cryptography] mode of operation for file encryption

[sebastien riou]

On Wed, Sep 2, 2015 at 7:13 AM, Jon Callas <jon at callas.org> wrote:
>>
>> Any alternative, reference to published stuff or criticism would be highly appreciated.
>> I could go for XEX, but I would like to have a good motivation to justify the additional GCM operation.
>
> In my opinion, you should just go with XTS mode, which because you're doing to be doing disk blocks is going to fall out as XEX. It isn't perfect, but nothing is. It's fast, reasonably parallelizaeble, and usually good enough. I don't know what you mean by the GCM operation, myself. You can find plenty of people grumbling about it, but it's in my opinion the best thing overall.
>
> If you're not fond of XTS, then I'd say go with EME. EME is cryptographically the best thing you could do, but it requires two encryptions. Modern AES-NI hardware makes this not horrible. You can still probably keep up with even a fast SSD with any reasonable AES-NI CPU. We were going to use EME at PGP Corp for our WDE, but that fell off the shelf for lots of reasons (including the advent of SSDs and thus speed).
>
> EME is patented; at PGP we paid a license fee, but a few years later the state of California just opened up the patent.
>
> The notes on Wikipedia:
>
> https://en.wikipedia.org/wiki/Disk_encryption_theory
>
> are pretty good. They're not up to date on the EME patent status.
>


Sorry I substituted GCM in place of GF128 multiplication.
2 encryption sounds not bad at all compared to XEX indeed, thanks for
pointing that out + the "scoop" on the EME patent.

> There's another option that I will mention. That is to use a real, honest-to-god tweak able, wide-block cipher. My favorite is Threefish. If you use Threefish-512, you get 64 bytes per encryption, and (duh) 128 bytes with Threefish-1024. Threefish runs in software at over twice the speed of AES in software, but all in all, AES-NI hardware makes it really attractive to well, just use AES-XTS.
>
>         Jon

In my use case I am actually better off with a "narrow" block size: I
am working at the file access level, not at the "block device" level
(when I used block in my description, I was referring to AES blocks).
As a result, a program may ask to write as little as 1 byte in one
block in many different blocks (I guess this is what would happen if
someone update an entire column in excel). If I work with a wider
block, the overhead of encryption will blow up in such use case.
Anyway fully agree, the wide spread availability of hardware
acceleration for AES is biasing comparison with alternative ciphers,
that's just the way to go.

Sebastien