Hot answers tagged

14

Although there are already many answers here, I wanted to strongly advocate AGAINST MAC-then-encrypt. I fully agree with Thomas' first half of the answer, but completely disagree with the second half. The ciphertext is the ENTIRE ciphertext (including IV etc.), and this is what must be MACed. This is granted. However, if you MAC-then-encrypt in the ...


9

The encrypt-then-MAC paradigm works as long as the encryption is CPA secure and the MAC is secure under the standard definition. However, such a MAC must be secure for multiple messages. Therefore, using GHASH or Wegman-Carter authentication is not sufficient. (Indeed, in GCM, the result of GHASH is masked and not directly output.) The proof of the general ...


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


7

Deterministic authenticated encryption indeed provides authenticity and it doesn't require a nonce or IV. In that sense it doesn't provide CPA security as identical messages would result in identical ciphertext. Authentication however doesn't really have to do with CPA security. It is about ensuring that the ciphertext was created by a specific party ...


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

What you're describing is pretty similar to the SIV block cipher mode. It also uses a deterministic function of the message to derive the nonce for CTR encryption. Under some pretty widely accepted assumptions about HMAC-SHA256 this is a perfectly fine way of achieving deterministic authenticated encryption. It doesn't meet IND-CPA (as you pointed out) but ...


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

I have argued so 15 years ago, and not been proven wrong since. Basically, A5/1, with a $n$-bit state, offers a resistance of roughly $2n/3$ bits of security. With $n = 64$, the resistance is very low, thus amenable to not only direct breaking, but also all kinds of trade-offs. All the attacks published so far are dances around that resistance level of ...


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.


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


4

No, this mode as listed does not provide integrity of the decrypted plaintext. An active attacker can flip arbitrary bits from the first 64 bits of the decrypted plaintext freely without causing a decryption failure. He can do this by modifying the $iv$; the decrypted $tag_0$ will authenticate (because the $iv$ is not used to compute that), and then the ...


3

It's rather hard to answer the full question, but I'll try and answer as best as possible. You try to derive a data encryption key using the IV, because you think the IV may be overused. NIST SP 800-38D section 8.3 states (for a probability of non-repeation of $2^{-32}$ ): The total number of invocations of the authenticated encryption function shall ...


3

This is standard Encrypt-then-Authenticate. The only difference is that when doing EtA, it actually isn't necessary to encrypt everything. This strategy makes sense when there is some part of the message that needs integrity and not privacy. In IPSec, the ICV (which is a counter to prevent replay) does not need privacy. Furthermore, by not encrypting it, it ...


3

Password-based encryption uses a hash function to derive a key from a password and that is the only use of a hash function. PBEWithMD5AndDES itself doesn't provide any authentication (includes integrity) and only uses MD5 for key derivation. If you want authentication, then you can still use PBEWithMD5AndDES, but you then would have to derive a MAC key from ...


3

Let's look at your requirements: have a large IV — specifically, one large enough that using a CSPRNG to generate a fresh IV each time is secure. Generally, IVs/nonces longer than 96 bits are thought to be okay for random generation. If it is at least 128 bits you can safely use it as long as you can a 128-bit block cipher like AES, because before you ...


3

This scheme is vulnerable to a "truncation attack", which allows an attacker to forge new ciphertexts (EN-FILEs). Here's how this works. Assume that the attacker controls a section of the plaintext and can predict (with reasonable probability) the plaintext prior to that section. In another words, a value $A \| B \| C$ is encrypted, where $A$ is ...


3

Internally, libsodium public key encryption uses the same primitives as the (nonAEAD) secret key authenticated encryption, namely XSalsa20 and Poly1305. NaCl, which libsodium is based on, does not have an AEAD interface at all. Instead, libsodium added it from a TLS draft. There is no similar reference for public key AEAD use of these primitives, since in ...


3

Yes. If you are looking for AEAD ciphers wrapped around a single primitive, there are several in the CEASAR competition for authenticated encryption. AEAD ciphers based on sponge constructions notably use only a single primitive, the F-function of the sponge permutation. These include NORX, Keyak, PRIMATEs-APE, and ICEPOLE, which are the 4 I find most ...


3

The NORX documentation does not specify how to use it for intermediate tags, but I agree with Richie Frame that it could easily support them. Using intermediate tags in sponge-based authenticated encryption was considered by Bertoni et al., SAC 2011, see Section 2.1. Since NORX's mode of operation is derived from the same construction, I see no obvious ...


3

ChaCha20-Poly1305-SIV is not well defined, and does not have the advantages of SIV-mode if you do define it. The SIV mode is essentially MAC-then-encrypt, with the MAC reused as nonce. The MAC in ChaCha20-Poly1305 requires a nonce, because it uses ChaCha20 to encrypt the Poly1305 authenticator (you cannot reveal the raw authenticator). So you cannot use it ...


3

I tried to combine both schemes them by signing the message and then encrypting the signature together with the message. But i struggle with proving that such a scheme is CCA-secure. I believe that the reason you're running into issues proving that is that CCA-secureness of this system doesn't actually follow from the CPA-security of the cipher and the ...


3

Yes, this is secure. (one of the few cases where I'm pretty confident about this). Here are the arguments: Combining a secure (e.g. SUF-CMA) MAC with a secure (e.g. CPA-secure) encryption method in encrypt-then-authenticate is generally proven secure. This was shown in "Authenticated Encryption: Relations among notions and analysis of the generic ...


3

You can do either. Though make sure you tighten up how you do the first scheme. In the first case you are going to have multiple tags, 1 for each chunk. In the latter, you will have a single tag. If you are downloading files that are approximately 1MB, I think #2 makes sense. If you are downloading files that are 1GB or 1TB, maybe #1 makes the most sense, ...


2

No. Yes, by choosing an authenticated encryption scheme with a known $\:I\hspace{.03 in}V\hspace{.04 in}||\hspace{.04 in}C\hspace{.04 in}||\hspace{.04 in}tag\:$ and $k_{\hspace{.02 in}0}$ and $k_1$ such that decrypting $\:I\hspace{.03 in}V\hspace{.04 in}||\hspace{.04 in}C\hspace{.04 in}||\hspace{.04 in}tag\:$ with $k_{\hspace{.02 in}0}$ and $k_1$ yields ...


2

Besides the security benefits of encrypt-then-MAC that many other answers have mentioned, there's a performance benefit. Checking the MAC first on the receiving end allows you to reject forged messages without doing the work to decrypt them. Bernstein mentions this in http://cr.yp.to/snuffle/design.pdf (in the section "Should the stream be independent of the ...


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

The scenario you're facing is well-known in cryptography. You can't afford expanding the message at all (maybe by some IV). So you can't get strong authentication but have to rely on what is called poor man's authentication, you rely on tampering causing random messages. Please note that all of the following modes are somewhat block-based, meaning you'd ...


2

MonkeyDuplex in NORX does not have padding per duplex because it does not need thanks to domain separation. As the plaintext is mixed into the ciphertext, it does so at the sponge rate, the same way as Keccak does during normal sponge operations. This makes it more efficient at the given security level. The standard MonkeyDuplex construction does not have ...


2

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


2

Secure encryption does not care about how the data is ordered. With the typical single use symmetric keys that hybrid encryption uses, I cannot think of a way it could matter one way or the other. With key reuse (if you used symmetric encryption on signed data), there are some cases where having the "randomness" from the signature in the first blocks might ...



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