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

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

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

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

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

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.

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

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

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

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

2

encrypt it with the message author's private key This statement makes me uncomfortable. Normally, in asymmetric cryptography, one encrypts with the public key and signs with the private key. Did you mean “sign it with the message author's private key”? Otherwise, I would not accept your protocol without a clear, detailed explanation of what encryption ...

2

A symmetrically encrypted hash is not a secure MAC. You should use either an authenticated encryption scheme or a secure MAC in encrypt-then-MAC. With asymmetric encryption, it may be secure – "encrypting" with the author's private key means you are actually signing the message which is fine. However, you need to use the actual asymmetric primitive, not ...

2

In short any proposed solution to this problem would be a violation of CWE-602: Client Side Enforcement of Server Side Security. Even if what you are suggesting where possible in some bizzaro universe it would be insecure. A client (or an attacker) doesn't just execute scripts, they are able to view and modify everything in memory, as well as intercept, ...

2

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

2

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.

2

From my point of view, multi-hashing will slow down things, but it won't add the security you are looking for in this case. Is cryptography able to solve this problem? Yes. What you need is a message authentication code (MAC), which is a short piece of information used to authenticate a message and to provide integrity and authenticity assurances on ...

2

You need integrity/authenticity and freshness (replay prevention), and in many contexts confidentiality (depending upon the situation). Mere encryption is not enough, because it doesn't provide integrity/authenticity and doesn't prevent replays. A better scheme would be authenticated encryption, with a nonce that is checked on the server and verified not ...

2

That's a lot of questions, I'll try and answer in order. A hash or message digest alone is not secure because anybody can calculate and thus substitute a hash value. If you (correctly) add a key to the mix then you get a HMAC, which can be used. Nowadays often a HMAC is used, or an authenticated mode of authentication such as GCM, CCM (for packet ...

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