# Tag Info

97

I'm assuming you actually know all of this better than I do... anyway, this paper neatly summarises all these approaches and what level of security they do or don't provide. I shall paraphrase it in English, rather than Mathematical notation, as I understand it, here: Encrypt-then-MAC: Provides integrity of Ciphertext. Assuming the MAC shared secret has ...

55

@Ninefingers answers the question quite well; I just want to add a few details. Encrypt-then-MAC is the mode which is recommended by most researchers. Mostly, it makes it easier to prove the security of the encryption part (because thanks to the MAC, a decryption engine cannot be fed with invalid ciphertexts; this yields automatic protection against chosen ...

33

Combining is what SSL/TLS does with MD5 and SHA-1, in its definition of its internal "PRF" (which is actually a Key Derivation Function). For a given hash function, TLS defines a KDF which relies on HMAC which relies on the hash function. Then the KDF is invoked twice, once with MD5 and once with SHA-1, and the results are XORed together. The idea was to ...

24

You were right with your ideas in the the original question. If what you want to protect against is pre-images then chaining hash functions produces a function at least as strong as the strongest of its two components: H∘(x) = H₀(H₁(x)) If what you want to protect against is collisions, then concatenation is at least as strong as the strongest of its two ...

19

For such a scheme to work, if I have some currency, I have to be able to give it to Abel and I have to be able to give it to Beth, but I have to be unable to give it to both Abel and Beth. This means that giving the currency to Abel has to somehow make me unable to give the currency to Beth even though I previously could do that. There are three mechanisms ...

18

Hugo Krawczyk has a paper titled The Order of Encryption and Authentication for Protecting Communications (or: How Secure Is SSL?). It identifies 3 types of combining authentication (MAC) with encryption: Encrypt then Authenticate (EtA) used in IPsec; Authenticate then Encrypt (AtE) used in SSL; Encrypt and Authenticate (E&A) used in SSH. It proves ...

14

There exists something which is one step further than your idea. Look up SRP: this is a Password-Authenticated Key Exchange protocol; the two parties (client and server) who run the protocol end up with a newly generated shared key (which can be used to derive encryption and integrity-check keys), with mutual authentication with regards to a shared ...

14

Assuming you are asking about public-key signatures + public-key encryption: Short answer: I recommend sign-then-encrypt, but prepend the recipient's name to the message first. Long answer: When Alice wants to send an authenticated message to Bob, she should sign and encrypt the message. In particular, she prepends Bob's name to the message, signs this ...

13

The answer you posted is actually correct (more or less, see below): have each participant commit to their random number $r_i$ by publishing, e.g., $\mathcal{H}(r_i)$ in the first round. And then in the second round, each participant opens the commitment by publishing $r_i$ and everyone checks that it matches the committed value by hashing it. The final ...

13

The overall idea is a sound migration strategy. The nice thing is that security for all users is upgraded in a one-shot operation, rather than at the hypothetic next login of each user. Of course, original salt and new_secure_salt shall be stored, or perhaps for some portion derivable exactly from material keyed-in by the user, e.g. user name lowercased. ...

13

$Encrypt(m|H(m))$ is not an operating mode providing authentication; forgeries are possible in some very real scenarios. Depending on the encryption used, that can be assuming only known plaintext. Here is a simple example with $Encrypt$ a stream cipher, including any block cipher in CTR or OFB mode. Mallory wants to sign some message $m$ of his choice. ...

12

If you look closely at the definition of authenticated encryption modes, you will see they all are, actually, the combination of symmetric encryption and a MAC. Using traditional encryption and an independent MAC has a few tricky points, none of them being unsolvable: The encryption mode will use a key, and the MAC will also use a key; using the same key ...

12

Actually, that wikipedia article you mention in your question already answers your question: It is moderately common for companies and sometimes even standards bodies as in the case of the CSS encryption on DVDs – to keep the inner workings of a system secret. Some argue this "security by obscurity" makes the product safer and less vulnerable to attack. ...

12

Cascading cipher gives a sense of security; and one that is technically justified with respect to the possibility that a weakness in one of the cipher would allow recovering the encrypted data. That's Bruce Schneier's argument, and it made sense in an era where DES, the then leading cipher, was a closed design, clearly deliberately weakened by a small key, ...

11

If k is a constant, such as 3, it becomes possible to select a pair (N,g) such that the discrete log of k to the base g is known, which would enable the two-for-one guessing attack again.

11

I'll comment only the statement referring to an AES-256 replacement with 4096-bit key: According to our engineers, this will take 23840 times longer to crack than aes256 Bob writing that is not able to correctly transcribe even the numbers that engineer Alice allegedly spelled: most likely, $23840$ is intended to be $2^{3840}$, which is the ratio ...

10

TLS 1.0 uses initialization vector (IV) to refer to two different processes. TLS 1.1 introduces a new type of IV that causes an entire block to be discarded and isn't directly comparable to the old series of IVs based on CBC residue. By simply changing an operation at the beginning of a record, the hope was apparently to make implementations easy to patch ...

9

I'm sure @Thomas will give a thorough answer. In the interm, I'll just point out that the collision resistance of your first construction, H1(m)||H2(M) is surprisingly not that much better than just H1(M). See section 4 of this paper: Multicollisions in iterated hash functions. Application to cascaded constructions.

9

It depends on the chaining mode. With recent modes like EAX and GCM, the IV just needs to be non-repeating, so a timestamp is OK (as long as you take care never to issue two messages with the same timestamp: this can be a problem if you emit two messages in, say, the same millisecond, or if the sender clock is somehow reset through manual action or NTP; ...

9

First of all, if your goal is to keep the garbled messages to "once every hundred years", well, you already don't meet that goal, even before the change. With an 8 bit CRC, a random change has a probability 1/256 of being accepted; hence if your wireless network has a transmission error at least once every three months (which, to me, sounds like an ...

9

What happens if the sender is at another point in the sequence? ... the key is pressed while out of range to the car. In a rolling code (code hopping) system, the keyfob transmitter maintains a synchronization counter C, incremented every time a button is pushed. The car receiver stores the most recent validated synchronization counter it has received ...

9

No matter how bad a protocol built on top of RSA is, there is no known risk that a private key leaks from valid plaintext/ciphertext pairs, even if the adversary chooses plaintext or ciphertext; that's one of RSA's virtues. Thus to the question is it possible with this information for Cindy to find $pri_A$ we can answer: as far as we know, no; and more, ...

8

This is actually to a great extent a question of terminology, and ultimately which security claims you are prepared to make, more than it is a practical question. For short: You may draw the line between the key space and the algorithm any way you want, but the way you draw that line will have implications regarding which security claims you are able to ...

8

Annex E.1 of RFC 5246 contains the following text which is a nice summary of the situation: Note: some server implementations are known to implement version negotiation incorrectly. For example, there are buggy TLS 1.0 servers that simply close the connection when the client offers a version newer than TLS 1.0. Also, it is known that some servers will ...

7

First recommendation: Don't invent your own protocol, but use an existing one. Use SSL/TLS, in the newest version possible if you don't have to provide downwards compatibility to existing clients. This will take care of most problems here, you simply put in a pair of plaintext data streams, and get a pair of encrypted streams. There are TLS implementations ...

7

Well, the methods we use to take a block cipher (such as DES), and turn it into an actually useful function (say, to encrypt a large message) is called a mode of operation. Such a mode of operation takes the message (generally of arbitrary length), and processes it (usually block by block), using the block cipher as a primitive. There are a number of such ...

7

It can be done, but the algorithm is a bit complex and the hashes have to be specially constructed. The basic idea is this: What you need is a way for each party to give the other a verifiable "clue" that reduces the search space for the possible file, say by a factor of 10. As soon as one party stops giving clues, the other stops giving clues as well. So a ...

7

The question is about an attempt to augment an encryption scheme with an integrity-protection measure, by additionally transferring the hash $H=\mathtt{Hash}(P)$ of the plaintext $P$ together with the ciphertext $C=\mathtt{ENC}(P)$ of the original encryption scheme; and having the recipient of an alleged $(C,H)$ obtain the alleged $P=\mathtt{DEC}(C)$, and ...

7

It depends upon what trust you have in the cloud. If you don't trust the cloud provider, a malicious model (treating the cloud as malicious) might make sense. The so-called "semi-honest" threat model almost never makes sense in practice. It amounts to assuming that someone is malicious ... but not malicious enough that they'll deliberately, actively try ...

7

Short answer: Because the browser developers have long thought interoperability to be more important than security and standard compliance. Slightly longer answer: Some SSL/TLS server implementations do not negotiate the protocol version correctly, but terminate the connection with a fatal alert if the client attempts to negotiate a protocol version that ...

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