Hot answers tagged

18

In short: You must authenticate the IV. Which particular attacks apply if you don't depends on the block cipher mode; I will give two common examples. In CTR mode, an attacker who fiddles with the IV can forge authenticated messages, but the content of the corresponding plaintext is beyond his control (since he doesn't know the key). Depending on the ...


8

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


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


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


4

I'll take this in parts: But this is clearly not the case when you're doing Encrypt Then Mac. When you do that you provide authentication to something that already has authentication (to decrypt we need to know the key). Encryption, by itself, does not provide authentication. why use a MAC when we can use a hash instead: E(m|h(m))? Here is a ...


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 Encrypt then MAC is done in general in order to be sure to decrypt into the correct plaintext, without risking of parsing a non-authentic plaintext message. If you don't MAC the IV, then Mallory (attacker that can tamper with messages as a man-in-the-middle) can modify the IV and your MAC will be still validated as good. So you will decrypt into an ...


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

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.


3

FFX is not malleable. It's a strong tweakable pseudo-random permutation, where the "strong" here indicates that both encryption and decryption look like random permutations from the attacker's perspective. In particular, there's no relationship between the plaintexts of closely related ciphertexts (aside from the trivial observation that different ...


3

Anon2000 - as currently constructed your mode is fatally flawed. Given two known messages encrypted with the same key (i.e. where the attacker knows the plaintexts) that are each at least two blocks in length (not counting the IV or final validation block), the attacker can trivially forge at least two other 'valid' messages (and many more than that if the ...


3

I would think these numbers would have been put on the google search engine, and yield (probably) many hits. This assumption is wrong. Certificate serial numbers are not indexed by common search engines, nor are they typically posted to any HTML site. Frankly, I'm not sure why you would assume they'd be indexed. The Wordpress certificate is used for ...


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

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

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

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

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


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

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


2

Yes, this is secure. Even simpler would be to just use XSalsa20-Poly1305 and the long term key directly. You could authenticate any additional data with the Poly1305 just as well as in the case of the ChaCha-based combination. However, if you use e.g. libsodium where the former interface does not support additional data and the latter has a short nonce, ...


2

When we have regions of the packet that we only authenticate but not encrypt, that happens because we have data that we want to bind to the encrypted region, but we don't need to include within the encrypted region. Examples of this are: For IPsec, we include the sequence number (as a part of the ESP header). We include that within the authentication ...


2

If you want to encrypt a long message with authenticated encryption, you should split it into many small segments (e.g. 4KiB each), with each fragment having its own tag. That way you only release plaintext to the application after verifying its tag. (As usual there are some pitfalls with designing such a construction). Such a construction works with any ...


2

The usefulness of online AE (locally): Assume you wrote a program that encrypt arbitrary files. Now further assume the user wants to view a movie, encrypted with this tool. The tool can now use the online-property to stream the movie in real-time as it uses online-encryption. The usefulness of online AE (programatically): Assume you want to process ...


2

This [Carter-Wegman] MAC is not, in general, secure in the quantum setting This is true; however we need to ask "what is this setting, and is it a realistic one?" This setting is one where the adversary can ask queries that are composed of a superposition of quantum states, and the oracle returns the superposition of the answers. In other words, the ...


2

This does not meaningfully authenticate the ciphertext. Your encryption is the same as OFB, meaning no block depends on the previous plaintext; for instance, $$C_2=P_2\oplus E(P_1\oplus (P_1\oplus E(IV\oplus 0)))=P_2\oplus E(E(IV)).$$ That means confidentiality should be fine; however, it provides no authentication except of the length of the message.


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

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

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



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