RSA digital signature vs authenticated cipher

Question

I want to provide both confidentiality and integrity for data at rest (many large files stored on disk).

I plan to encrypt the data using AES, which will cover the confidentiality requirement.

The issue is how to provide integrity:

1. Instead of AES, use AES-GCM-SHA256 (authenticated cipher). My understanding is that this produces an HMAC (keyed hash) of the encrypted data (and IV), and appends it to the end of the file.

2. After encrypting each file, produce an RSA digital signature, and either save it as a separate file or append it to the encrypted file.

What are the merits and disadvantages of each option?

Answer 1

You got some notation wrong. There is no algorithm like "AES-GCM-SHA-256".

AES is a block cipher, i.e. a pseudorandom permutation of 128-bit blocks. It itself only allows encryption for messages of size 128 bits (= 16 bytes), with a limited security guarantee.

When you mean "encrypt the data using AES", you actually mean "use AES with some mode of operation to encrypt the data".

Galois/Counter Mode is one such mode of operation, which combines counter mode for privacy and a block-cipher based MAC (GMAC) using some finite field operations and some block cipher calls for authentication.

SHA-256 is a hash function, but neither it nor its associated HMAC function HMAC-SHA-246 are used here in any way.

When using GCM (or almost any mode) for disk encryption with changing files, you should pay attention: You shall not use the same key and initialization vector (= initial counter) twice for different data. This also means, don't simply change some parts of the file an then encrypt again only the changed parts with same initialization vector, as you are then using the same IV twice (over time).

Instead, either generate a new random IV and encrypt the whole file with it, or split the file in blocks (of a comfortable size, e.g. 4 KB or such), each of which is then encrypted using GCM mode with a separate, independent random IV. (This works better if you are encrypting your whole disk – then you would use the disk sector as your encryption unit.)

There is no point of using a signature – that only makes sense if you want to allow someone else to prove that you did produce (or at least sign) the data, without this one being able to produce it himself.

Answer 2

Your options should really be either using GCM mode, or using a non-authenticated mode (such as CBC) and calculating the HMAC (with something like HMAC-SHA256) post-encryption. Using an asymmetrical encryption scheme such as RSA in this context is not very efficient or appropriate.

GCM is a good option as it combines encryption and integrity in one mechanism. You're right, GCM produces a keyed digest of the ciphertext and appends it, and also validates it upon decryption. The advantages are that you only have to worry about one key, and there's less room for error. Just a note regarding your terminology, I'm not aware that you can specify the hash algorithm (ie, AES-GCM-SHA256) for GCM mode, but I may be wrong.

The second option, encrypt-then-hmac, is fine too, but there's more room for error. I guess the advantage is that you can specify your own hash algorithm (such as SHA512, Keccak, or whatever), which may be advantageous if you're ultra-paranoid about security.

Answer 3

The answer "GCM is a good option as it combines encryption and integrity in one mechanism. " is a bit misleading. GCM uses one after another: 1-st encryption in counter mode and then GHASH to authenticate the data. In the recent intel processors CLMUL-NI is used to speed up the GHASH operations.

Benefits of GCM over CBC+HMAC:

1. is much faster, as the encryption of multiple blocks can be done simultaniously. ( in CBC, the next block is waiting as IV the previous encrypted block )
2. can add Additional Authentication Data - / not encrypted data / to the final authentication TAG

Drawbacks of GCM over CBC+HMAC:

• GCM use only one key for both operations, The GHASH key / multiplyer / is derived from the encryption key: encrypting a 128bits block of "zeros".