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

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

5

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

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

4

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.

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

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

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

In principle this is safe. 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. Your usage gives me a bad feeling concerning padding oracles. I see no direct attack in your example, but it looks a bit risky to me. This is related to the encrypt-then-MAC debate. Finally with ...

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

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

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

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

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

1

If you want to be sure the value is not altered in transit by an active attacker that is occupying the wire then what you need is an integrity mechanism that will guarantee that nobody has tampered with the message. Such mechanisms are instantiated with the employment of a message authenticated code (MAC) which are build on top of secure crypto primitives ...

1

You asked the same question over on the IT Security site. Please don't cross-post. It is frowned upon, under the rules these sites operate. Here is what you should be doing: Truncate the MAC tag to an acceptable length. You will need to choose a length that provides a suitable tradeoff between packet size vs. security against forgery. I suggest you use ...

1

You can use the well established TLS (Transport Layer Security) protocol to achieve the first three properties and modify it to include a digital signature for non-repudiation*. However, strictly speaking, non-repudiation requires the use of certificates from a CA so that the signature can be verified by any third party.

1

The verifier and logger start with a seed for a forward-secure pseudo-random number generator. To denote a valid ending of a log, append the string of the next $b$ bits of the PRNG's output to the end of the log. $\;\;$ To add a log entry, get the next $\:b\hspace{-0.03 in}+\hspace{-0.03 in}k\:$ bits of the PRNG's output, use the last $k$ of those bits to ...

1

Time stamps are also signatures; see for instance RFC 3161 which is the most commonly used time stamp format. In particular, such time stamps also rely on certificates (the TSA certificate), and thus also expire. So you need regular time stamping; whenever the latest time stamp is about to expire (but before expiration), you need to obtain a new time stamp ...

1

It would seem that the answer is no. If the TSA's private key is compromised (and thus revoked), the time stamp signature cannot be trusted as whoever compromised it could sign documents with old time stamps. Surely users would want to be warned before accepting a time stamp signature from a compromised certificate. It seems then if this is your threat ...

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