Tag Info

14

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

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.

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.

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

6

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

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

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

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

3

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

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

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

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

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

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

According to Wikipedia, GCM is defined for block ciphers with a block size of 128 bits. So no, you can't use GCM with 3DES or DES, because of the 64-bit block size. You could use something similar to GCM, but it wouldn't be GCM.

2

TLS has different keys for the two different directions. That is, the server-to-client connection is encrypted with one set of keys, and the client-to-server connection is encrypted with another. Both sets of keys are derived at the same time, however they are distinct. Because the keys are distinct, using the same nonce isn't an issue. Technical point ...

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

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

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_i$ $R$ is a ...

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

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

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

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

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

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

1

This sounds like Kerberos. ( https://en.wikipedia.org/wiki/Kerberos_%28protocol%29 ) In any case, you didn't mention, but it would seem quite important, how long are the generated auth tokens valid for, or how would you expire one. There is no such thing (IMHO) as permanent/indefinite authorization--if you believe otherwise, you should not be doing ...

1

No, not as described in the question. Putting aside the block size confusion that Richie Frame mentions in a comment (AES block size is always 128), there is no advantage to encrypting a second half of an IV in GCM mode in particular, and rarely in other modes. In GCM mode the actual IV is used to derive a nonce for CTR mode encryption. By adding a block ...

1

The authentication tag in GCM is generated by XORing a block cipher output with the Galois field hash (and truncating it for shorter lengths). It is thus assumed to look PRF. So it is effectively just a random nonce that should not collide until a birthday bound of $2^{t/2}$. With a tag length of 96 or more bits, it should be secure. Shorter random IV ...

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