Tag Info

Hot answers tagged

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


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


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


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

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

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


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

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

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

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

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


1

As additional detail, while the two keys need to be distinct and secret, you can derive the CBC-MAC key and the CBC encryption key from the same master key. Generate a random master key, then use any key derivation algorithm with two different salts to derive the authentication and encryption keys. For example, $K(m, \text{'auth'})$ and $K(m, \text{'enc'})$ ...


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

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



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