# Tag Info

9

I'll assumme 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 ...

8

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

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

6

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

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

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

6

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

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

5

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

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

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

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

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

4

From the sound of your questions, it almost appears that you have some confusion between the CBC-MAC key and the CBC-MAC tag. The CBC-MAC algorithm takes the message (in this case, most likely the ciphertext) and a secret key; it outputs a tag (which can be public). The security property of CBC-MAC is that someone who does not know the key cannot generate ...

4

If we're talking about a malicious and intelligent attacker, you are mostly wrong, but not for the reasons you might expect. If we assume an intelligent attacker, then a CRC does not help; they can obviously modify a file, and either figure out how to update the CRC32, or how to make sure that the modifications do not change the CRC. On the other hand, if ...

4

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

4

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

3

There aren't any known attacks on the PRFness of HMAC-SHA256 better than brute force. (So you can truncate that MAC to length L where $\:\:\frac1{2^L}+\epsilon\:\:$ is an acceptable risk of forgery.) To reduce the impact of a forgery without making the ciphertext any longer, one should use a format-preserving encryption (FPE) scheme that is secure against ...

3

1. To clarify: The critical time period here is one year (after wich the certs are changed). With the cracked RSA key the attacker can decrypt the traffic and do nan-in-the-middle attacks, posing as a valid hardware device. Let us take the numbers determined by experts. In their paper on cracking the 768-bit RSA key the researchers state that they needed ...

3

Small addition: You do not lose integrity when using encrypt-then-MAC. Since encryption is an injection, distinct plaintexts produce distinct ciphertexts, so plaintext forgery implies ciphertext forgery, which is hard if encrypt-then-MAC is secure.

3

If the receiver can wait for all the packets before decrypting: This case is simple, since your final goal is to ensure that the plaintext you decrypt was the exact same plaintext you encrypted. (Trivially, this includes rejecting re-ordered plaintext.) Use an Authenticated Encryption (AE) scheme (eg, CCM, GCM, etc) across all the packets, treating the ...

3

The plain text at the beginning of your crt file is there for informational purposes only. All it does is present in human readable form the contents of the Base64 encoded certificate that follows. The informational text is ignored by most PKI software.

3

You can be sure that the attacker did not manipulate the file. It's preferable to use a hash function that's collision resistant, even if it doesn't seem to be strictly necessary in your application. But confidentiality against an active attack is problematic. Since the authentication happens inside encryption (MAC-then-encrypt). A careless implementation ...

3

I have ask as part of my answer, "What problem are you trying to solve?" Do you want a secure unkeyed hash function? If you do, then there are plenty of them around. Even some of the ones that are broken for some uses might be okay for yours (SHA-1 springs to mind -- note the discussion above on HMAC and how broken a hash function has to be). But really, ...

3

If the plaintext format is indeed as you describe, then you're out of luck: the insertion of the newlines and the consequent shifting of the plaintext records is enough to disrupt any structure in the ciphertext. If the plaintext were longer, say, 8 records, then it could work, but with just 7 records there's no way to switch the first and last record ...

3

In general signature creation contains the hashing part within the algorithm. A signature algorithm may also contain a padding mechanism such as PKCS#1 v1.5 or PSS for RSA. Finally it contains a one-way trap door function (modular exponentiation within RSA). Encryption has other requirements, and uses a different padding mechanism. Basically you are ...

3

I wrote this response while thinking I was on Information Security. Oops. Anyway, I think it may be helpful, so sorry if this is not exactly "cryptography" POV. Point of this response is: in this case encryption or hashing is not a good solution. It has a lot of problems, because there is very little entropy and it has to be working over HTTP. Full ...

3

Signing and encrypting together is not secure in this method, at least in the way most would perceive security. For example, Bob would likely interpret this message as being sent from Alice to Bob. However, Alice may have sent it to Charles who decrypted and re-encrypted the signed message under Bob's public-key. In order to do this securely, you need to add ...

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