# Tag Info

15

Contrary to what Stephen says, you absolutely can compute the tag in parallel. Here's how it works; the tag computation is essentially "assemble the AAD, data, the length field and $Encr(Nonce)$ into a series of values $x_n, x_{n-1}, x_{n-2}, ..., x_0$", and then "compute the polynomial $x_nh^n + x_{n-1}h^{n-1} + x_{n-2}h^{n-2} + ... + x_0h^0$ This ...

11

In general the AAD itself is not required or won't change the security of the GCM mode of operation itself. It may however directly influence the security of the protocol in which GCM is deployed. For instance, you may have specific configurable parameters outside the ciphertext itself. These parameters may very well include: version number of the ...

9

AES has a block-size of 128 bits in all its variants. The number in AES-128/192/256 is the key-size. Rijndael, the block-cipher that became AES, also supports 256 bit blocks, but that part was not standardized as AES. Since the block-size is 128 bits, GCM works exactly the same way for AES-256 as it does for AES-128.

8

AAD has nothing to do with making it "more secure". The aim of AAD is to attach information to the ciphertext that is not encrypted, but is bound to the ciphertext in the sense that it cannot be changed or separated. (Conceptually, the MAC is computed over the AAD and the ciphertext together.)

7

This is terrible. In GCM, if you use the same nonce, then the authenticator is completely broken (for all messages in the future). You should never assume that the attacker doesn't know the filename either. You MUST use different IVs.

7

I'll answer in order: Output size = input size That's correct, GCM uses CTR internally. It encrypts a counter value for each block, but it only uses as many bits as required from the last block. CTR turns the block cipher into a stream cipher. IV of any size For GCM a 12 byte IV is strongly suggested as other IV lengths will require additional calculations....

6

The source of the limitation lies in the fact that GCM has a fixed block counter using a 32-bit integer. Since the block size is $2^7$ bits, the total amount that can be encrypted with the CTR component is $2^{39}$ bits. The first limit reducing this by 128-bits is the fact that the block counter starts at 1 and not 0, at least with a 96-bit nonce. Nonce ...

5

The GCM flowchart on Wikipedia and my intuition support the notion that some of the GCM work can be done in parallel. At the very least you can do each $E_k(ctr)$ operation in parallel, but it doesn't look like you should be able to parallelize the authentication, as each $mult_H$ requires the output of a previous call as its input. Edit: poncho explains why ...

5

The IV of encryption schemes can be made public without damaging the security of the encryption, so there shouldn't be any issues with prepending it to the encrypted file. The difference between IVs and Nonces was already explained by @SEJPM in the comments. Note that in the case of GCM, you do need to make sure that you do not re-use the IV with the same ...

5

XTS is designed so that the plaintext and ciphertext sizes are the same. This is "needed" for disk encryption in order to preserve the sector size. However, when you are encrypting your disk at the file level, this is a completely irrelevant issue. Also, XTS is not "ideal" in the sense that it's not truly a wide block cipher (defined as a pseudorandom ...

5

Any of the ways you listed would work. If you're collecting alternatives, yet another one (which I have seen in practice) is to include the message counter as the AAD (additional authenticated data), which is another input to GCM. When we consider which one would be the best, we note that GCM has absolutely no requirement that the nonce be "random", or for ...

4

You can use methods for hiding the output of the polynomial hash that don't require nonces, such as encrypting with a block-cipher of matching block-size or hashing it with a keyed hash (PRF). Not using a nonce reduces the security bounds (security decreases as the attacker sees more messages using the same key), makes it incompatible with stream ciphers ...

4

The only limitation that you really have to consider is that of nonce collisions. With 128-bit random nonces, you would expect collisions after about $2^{64}$ nonces due to the birthday bound. Even if you stored all 30 fields of all 50 million rows thousands of times (you need a new nonce if a field is rewritten), you would still have a chance smaller than $... 4 Under the ideal cipher model, security is not diminished by any choice of value$H = E_K(d)$for a known value$d$, as long as none of the counter values that get encrypted to generate the encryption stream is equal to$d$. This is what "ideal cipher" means: you have no information on$E_K(x)$for any$x$that you have not already tried to encrypt with the ... 4 Use XTS for whole-disk encryption. It is designed for that purpose. Definition of XTS mode in wiki is under the Disk Encryption Theory which says enough i think :) In GCM, for a fixed key each, IV value must be distinct. This makes it disadvantageous for encryption of large files. From an early GCM question: GCM is bounded to encrypting about 68 GB ... 3 Those ciphersuites do use GCM for both encryption and authentication. The hash function mentioned at the end is not used for integrity, but in the pseudorandom function. The TLS PRF is used to derive valid keys for the ciphersuite from the shared secret generated in the key exchange. 3 In asymmetric crypto including RSA, we ALWAYS encrypt with the public key, and decrypt with the private key (NEVER the other way around). In the question, what's wanted is to sign with the private key, not encrypt. And that's enough to solve the whole problem, since RSA signature schemes exposed in BouncyCastle or the Java crypto API allow to sign data of ... 3 You don't actually need 384 bits of key material. The IV for GCM does not need to be secret, and may be chosen deterministically, e.g. as an incremental counter. Thus, you only need 256 bits for the AES key, which you already have. That said, if you did actually need more key material, you could use any standard KDF to expand your 256 bits. Since you ... 3 Yes, it appears that it can be solved in practical time in$GF(2^n)$, if the attacker gets$n+\epsilon$random$a_i$values, even if he gets a single bit of the$a_i \times k$values. The chief observation is that the mapping from$a_i$to bit$j$of$a_i \times k$(which I'll refer to as$bit_j(a_i \times k)$) is bitwise linear (for constant$j$,$k$). So,... 2 Thanks @poncho for providing a correct answer. I investigated it deeply, viewing it as a linear algebra problem. Here's what I obtained: in$GF(2^n)$, the series of equations$r_i=a_i\times k$can be written as$R = K \cdot A$where:$A$is a known$n \times n$matrix, where each column is a bit representation of$n$, linearly independent,$a_iR$is a$...

2

GCM is sometimes called a 1.5 pass AEAD cipher, where the CTR encryption counts for 1 and the GMAC counts for 0.5. So you would indeed expect it to be faster than encryption + CMAC and HMAC with regards to the amount of CPU instructions. That is: as long as the encryption is using AES for both solutions. GCM requires a 128 bit block cipher while CMAC and ...

2

The field polynomial used for GHASH limits most definitions to 128-bit block size. That does not mean you could not define it for other sizes – the proposal defined it for 64-bit as well (pdf, see Appendix A) even if NIST did not standardize that. However, defining it for arbitrary block sizes would be more difficult. You would need to define a ...

2

Theoretically, there is no issue adding some kind of MAC on top of authenticated encryption's builtin. However, in practice there might be subtle flaws with composing the particular primitives you're using, or you may make an implementation flaw that renders them both vulnerable to a side-channel attack that didn't exist previously. Ultimately, it's best to ...

2

Is it safe to use non-random nonce in GCM? Say I use 0x1 for m1, 0x2 for m2, so on. It is perfectly safe to use a non-random nonce in GCM, as long as you never reuse a nonce for two different messages. So, if you use the message count for the nonce, that's fine; if you accidentally forget that you used nonce 0x5 for a message, and use that again, well, ...

2

I do not agree with the other answers and comments given here. The use of the 96-bit nonce gives the best bounds, but it is certainly not the only way to use GCM. Also, the degradation is gradual. It is not the case that anything else is insecure. Having said this, it is completely insecure to encrypt beyond $2^{32}$ blocks using a 96-bit counter since the ...

2

I would say thats not safe. GCM works as CTR, so an attacker that knows (part of) the plaintext version of the file name can compute the beginning of the file as plaintext. If you XOR the two encryption, you'll have the XOR of plaintext, and if you know the filename, you'll get the (beginning of the) file. To securely encrypt the filename you'll need a ...

2

The result you are getting is the cipher text (the encrypted data) plus 16 bytes of authentication data. The authentication data (mentioned directly below the ciphertext in the resource you cited) ensures that the ciphertext cannot be changed without the change being detected, and is the (most important) thing that distinguishes GCM from regular CTR-Mode. ...

1

It is per message. I.e. per (key, nonce) -pair. The reason it exists is that GCM uses CTR mode for encryption with (normally) a 32-bit counter. That means you can only encrypt $2^{32}$ blocks, i.e. $2^{39}$ bits with AES. The 256 bits that are subtracted are due to authentication. So you can encrypt multiple maximum-length messages securely.

1

You need to call gcry_cipher_authenticate if you have additional authenticated data (data also authenticated that is not encrypted and - in this case after decryption of the ciphertext, excluding authentication tag - you should call gcry_cipher_checktag with the authentication tag. It's wise and possibly required to call gcry_cipher_authenticate before ...

1

Yes, you are in the ballpark with your assumptions. I will store the encryptedKey with the encrypted data, but can I use the same key for all rows or do I need to generate a new one for each one? No you can use the same key. How does the AAD factor into this? Do I need to store it? Does it need to be unique per row? If you don't need ...

Only top voted, non community-wiki answers of a minimum length are eligible