Hot answers tagged

13

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


7

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.


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


4

If you are constrained by the embedded environment, you should consider CCM instead of GCM as AES mode. One of the major constrain when implementing GCM is that the authentication part (the GHASH) is totally unrelated to AES and should be implemented in its own way. And, to make it reasonably fast, you have to use key-depended look up tables which will ...


4

The authentication tag is defined as an output parameter in GCM (see section 7, step 7 of NIST SP 800-38D). In all the API's I've encountered it's appended to the ciphertext. Where it is actually placed is up to the protocol designer. The protocol designer may well consider the place behind the ciphertext as ad hoc default though. The name "tag" of course ...


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


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

As SOJPM says in their answer, the proofs for AES-GCM assumes that AES is a PRP. I can't believe that there is anywhere in the proof that using a PRF (possibly truncated) would break things -- but I haven't looked carefully for this. Depending on how the GCM proof is structured, (using/not using) the PRP/PRF switching lemma [1] may suffice, but I don't ...


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

GCM is a stream cipher -- it encrypts using CTR mode, which turns a block cipher primitive into a stream cipher. Additionally, GCM is an AEAD mode, which means the authentication is nicely built in (so you don't have to worry about how to handle it, because the mode itself specifies how to do it in a secure way). The IV does not need to be secret. However, ...


2

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.


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

The ZFS file system uses AES in CCM or GCM modes. This works because in ZFS the data and file system metadata is encrypted but the block pointers are in the clear, the AuthTag (MAC) is stored in the block pointer. ZFS also has a SHA256 based merkle tree based on the block pointers that is used for data integrity for resilvering and navigation purposes. ...


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

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

For any $k$-bit MAC, an attacker blindly guessing a tag has a one-in-$2^k$ chance of successfully forging a message. Thus, the expected number of attempts needed to forge a message by brute force is $2^{256}$ for a 32-byte tag, $2^{128}$ for a 16-byte tag, and $2^{64}$ for an 8-byte tag. In practice, attempting $2^{128}$ forgeries is far beyond the reach ...


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

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


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


1

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


1

Reusing an IV once opens you up to someone finding the XOR of those two plaintext, seriously compromising their confidentiality. Moreover, with GCM, a single IV reuse leaks significant information about the key used for authentication; if there are even a few pairs of reused IVs (not even one IV used many times; a few IVs each of which are used twice is ...



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