Tag Info

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

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

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

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

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.

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

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

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

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

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

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