12

I'll assume All ciphered blocks means the same as ciphertext for CBC-Encryption with implicit zero IV, while CBC-MAC is the last block of that. All ciphered blocks is unsafe as a message authenticator for messages longer than one block, for it succumbs to a trivial attack (here with two blocks): Eve intercepts message $M=M_0||M_1$ and its authenticator $A=...


11

It is a recurring topic: what exactly is identity and how to prove it ? But related to your question: a MAC (correctly implemented) proves that the author of the message was in possession of the secret key (like you are, if you can verify it). Now, depending on the application you have in mind, that's a good enough proxy of identity, or it isn't. In other ...


10

First the theoretical explanations: Integrity and authenticity are different goals to achieve, but both are achieved (for symmetric encryption) with a MAC. You should probably be using encrypt-than-MAC or an authenticated cipher unless you have very good reasons not to. No blanket statements can be made though. HMAC: HMAC is a often used construct. It is ...


10

It is hard to have message authenticity without integrity. To authenticate the message you need to know what message is being authenticated. If you could change the message the authentication tag should become invalid. Message authenticity means that you can establish that the message originated from a trusted entity. For this reason message authenticity ...


9

Actually section 6.2.3.3 of RFC 5246 talks about the associated data: The additional authenticated data, which we denote as additional_data, is defined as follows: additional_data = seq_num + TLSCompressed.type + TLSCompressed.version + TLSCompressed.length; where "+" denotes concatenation. So the sequence number, the packet ...


8

Don't believe every claim ever made in any paper ever written, particularly when the paper provides little or no justification for the claim; not everything you read reflects the cryptographic consensus. This is particularly true for a paper written in 2002, which is a time our understanding of authenticated encryption and security engineering was still in ...


8

Yes, this is exactly what a message authentication code is for. Its job is to prevent an attacker from tampering with your message, or from forging completely bogus messages. For a secure MAC, it should not matter what these messages contain. (And no, a secure MAC cannot compromise your key; if it did, it would by definition not be secure, since an ...


7

You are writing out data and reading it back on the same server. You want to ensure that the data that you read back is the same as the data that was written out. For this use case, symmetric cryptography seems appropriate. Have a single symmetric key that doesn't leave the server. You need to rotate the key only if the server is compromised; this will ...


7

The short answer: No. It is not secure. Details. To answer the question properly, we first have to decide what we mean by "secure". In this case, I assume security means confidentiality plus integrity. So let's talk about each separately. Integrity: yes, this provides integrity, under your assumptions. @poncho explained why. Confidentiality: no, this ...


7

Using a MAC on the plaintext may potentially leak information about the plaintext (MAC algorithms do not necessarily ensure confidentiality of the data they are applied to, although some MAC algorithms like HMAC seem pretty safe). If you want to avoid this (theoretical) problem, then you should encrypt the MAC on the plaintext (i.e. MAC-then-encrypt, not MAC-...


7

Sending information covertly when using legitimate systems is a well-studied field. As another question mentions, key words are covert channel and subliminal channel. Designing systems with no covert channels is difficult, but not impossible. The main difficulty is to ensure that if any randomness is sampled incorrectly, the legitimate recipient must detect ...


7

If I want to ask a potentially compromised server to remember a file that I don't have room to store myself, I can pick and remember a 256-bit secret uniformly at random, and compute a short—say, 128-bit—authenticator (or MAC, message authentication code) for the file under the secret key. I keep the key on my person; I affix the authenticator to the file. ...


6

It is easy to see that this secure, in the sense that the attacker cannot cause Alice to accept any download except for the file that Bob originally sent. This remains true even if the attacker knows the encryption (CBC) key (alternatively, Alice and Bob doesn't bother to encrypt the message at all), and if the attacker also knows the correct $SHA1(M)$ ...


6

The answer to that depends on the details of your system, and specifically whether someone other than you can modify the hash. If you store the hash in your database, and retrieve the expected hash value from your own database to compare it with the actual hash (when checking to make sure that those certain values have not been altered), there's no point in ...


6

Indeed hashing is used to ensure integrity, but not this way. What you have in mind it seems is sending (msg, Hash(msg)). Indeed this is not secure because of the attack you describe. The first step starts with something you say by yourself: hashing algorithms are universal algorithms The name is not univesal but public, it means anyone knows it. ...


6

Do not invent your own authenticated encryption mode. Use a standardized one, and use a well-supported library to implement it in your code. AES-GCM, AES-CCM, AES-OCB, and AES-CBC with HMAC-SHA256 over the ciphertext are all common options. Some great direction from Matt Green here: How to choose an Authenticated Encryption mode


6

RSA with PKCS#1 v1.5 padding for signature genernation would work, as the algorithm is fully deterministic. The random padding is only used for RSA with PKCS#1 v1.5 padding for encryption which is different from the padding for signature generation. Note that both OAEP and PSS are not deterministic either; they both rely on a random number generator. I ...


6

There are several concepts of integrity. Authenticity can be thought of as integrity of the association between data and its creator/modifier/sender. There is also integrity of the internal structure of data and multiple integrity definitions inside database management. Note also, that cryptography cannot help to prevent integrity violations, it can merely ...


6

The goal of a MDC is to provide integrity guarantees. That is, given the value $h(x)$, it should be possible to check whether $x$ has been tampered with. The attack scenario you are describing requires authenticity guarantees, i.e., you want to be able to detect whether the tuple is actually from Alice. To achieve this, there are many possible solutions. One ...


6

Does it matter? Yes: there's a qualitative difference in the types of attacks that would break your system. The elephant in the room, of course, is MD5, but let's examine the qualitative difference between the attacks first. It is almost useless to publish the bad hashes, because as an adversary I could just distribute different versions to everyone. A ...


5

The "Common Name" is part of a X.500 name; here, the one called "SubjectDN", which designates the owner of the public key which is contained in the certificate. That name is part of the certificate, in the part which is covered by the signature; as such, it is exactly as trustworthy as any other element in the certificate.


5

INT-CTXT and INT-PTXT are usually on considered for private-key encryption. For public-key encryption, no correct encryption scheme can satisfy those requirements. (Proof: The adversary can run the encryption algorithm on an arbitrary message and submit it as its output. Since it made no queries to its encryption oracle, this ciphertext violates both INT-...


5

With pure asymmetric encryption there is no way to ensure integrity and authenticity, since anyone who knows your public key can encrypt any message for you. For that you would need either a symmetric key to use for a MAC (in which case you could use it/derivatives for symmetric encryption too) or a signature from the sender. And in the latter case the ...


5

A length extension attack doesn't let you find a collision. It lets you predict the hash for an input with an unknown component in the prefix. If you have $h = H(x)$ for unknown (or partially unknown) $x$, you can generate $h_y = H(x \vert\vert y)$ for arbitrary $y$ (this is not strictly correct; I've ignored padding, but for the purposes of this discussion ...


5

Yes, there is the one-time MAC. This is a scheme which ensures that an adversary (even one with infinite computational resources) has a negligible chance of altering the message or forging a fake message without detection. Edit to add: Mikero's comment and the other answer demonstrate that we need to be clear about what we mean by "perfect" integrity. "...


5

My answer is taken from the following paper http://cseweb.ucsd.edu/~mihir/papers/oem.pdf (it is a well-written paper, so if you are interested in this topic I highly recommend you to read it). Suppose $\mathcal{SE = (K, E, D)}$ is INT-PTXT secure. From $\mathcal{SE}$ we create another scheme $\mathcal{SE}_2 = (\mathcal{K}, \mathcal{E}_2, \mathcal{D}_2)$ ...


5

Like entrop-x says, a valid MAC proves that the sender (or, more specifically, whoever computed the MAC) knows the secret MAC key. That can be sufficient to prove the sender's identity, e.g. if the only people who are supposed to know the key are you and whoever claims to have sent the message, and you know you didn't send it yourself. That said, there are ...


5

Hash-then-encrypt is not a scheme that is used a lot. It may not be necessarily secure in all situations. Instead message authentication codes (MAC) are used. These produce what is called an authentication tag (symbol: $t$); a fixed size, keyed hash over the processed data. Obviously, as a keyed hash it requires a key as input, preferably one specific for ...


4

Does it negatively affect security to calculate a hash value of the ciphertext before MAC calculation? Like exchanging step 2. with this: HMAC-SHA256(SHA256(ciphertext)). Technically, yes, but not significantly. In order to attack the scheme you propose, the attacker would have to be able to do at least one of two things: (1) Find an attack on the (standard)...


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