# Tag Info

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

0

Both reasons are basically the same. The issue here is the following: Often you only want to compress for transportation (e.g. for sending an email) and decompress for storage (e.g. when storing the email in you local email client) to more efficiently offer features like text search. Because the compression algorithm is non-deterministic you would have to ...

1

As for the first reason: in the future you probably need the decompressed form of the message. There won't be much you can do with the compressed message. But PGP is application level; you may want to verify that message at any time. Now you may want to verify the signature over that decompressed data without compressing it first. E.g. it's a good use case ...

8

It depends on which cipher suites and extensions the client and the server implement, enable and negotiate. The default operation in TLS 1.2 and earlier, is MAC then Encrypt. This corresponds to alternative a in the question. In TLS 1.2 it is possible to use AEAD cipher suites. Such cipher suites (e.g. AES-CCM but not AES-GCM) might correspond to ...

4

Yes, TLS works by MAC then encrypt. This is the source of a large number of padding-oracle-type attacks over the past few years.

0

I've actually just stumbled across this page which is a great explanation of how TLS all works. It explains that you take the hash first, then encrypt the whole thing. http://www.moserware.com/2009/06/first-few-milliseconds-of-https.html

4

The property you are probably looking for is whether the MACs are PRF. With HMAC it depends on the pseudo-randomness of the hash function used. If the hash is a PRF then the HMAC is as well. However, that is not required for MAC security of HMAC, so it's not necessarily true even with a secure HMAC. See New Proofs for NMAC and HMAC: Security without ...

Top 50 recent answers are included