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


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

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


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


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

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

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

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


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

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

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

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

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

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

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


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

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

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

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



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