Tag Info

Hot answers tagged

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

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

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

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

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

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

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


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

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

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

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


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

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


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

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

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


1

As I understand, MAIC is mostly used where MAC has a different meaning (e.g. MAC address). If a message authentication code didn't provide integrity, you could make a forgery based on another valid message, so it wouldn't provide authenticity either.


1

I second Gilles' suggestion of using an authenticated encryption mode. In particular, if your crypto library provides it, this sounds like a perfect job for SIV mode (RFC 5297). SIV is designed to be "maximally misuse-resistant" authenticated encryption (AEAD) mode for securely encrypting and tamper-proofing (relatively) short messages (such as private ...


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

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

This procedure, also called signing a message, does not encrypt the message itself, thus does not ensure it cannot be read by others. Instead, a hash sum of the message is encrypted using the private key. For verifying, the recipient again calculates the hash sum of the message, and decrypts the hash sum calculated by the sender using the sender's public ...


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