Hot answers tagged

7

Yes, this is exactly what a message authentication code is for. Its job is to prevent an attacker from tampering with your message, or from forging completely bogus messages. For a secure MAC, it should not matter what these messages contain. (And no, a secure MAC cannot compromise your key; if it did, it would by definition not be secure, since an ...


5

It is hard to have message authenticity without integrity. To authenticate the message you need to know what message is being authenticated. If you could change the message the authentication tag should become invalid. Message authenticity means that you can establish that the message originated from a trusted entity. For this reason message authenticity ...


5

With pure asymmetric encryption there is no way to ensure integrity and authenticity, since anyone who knows your public key can encrypt any message for you. For that you would need either a symmetric key to use for a MAC (in which case you could use it/derivatives for symmetric encryption too) or a signature from the sender. And in the latter case the ...


5

A length extension attack doesn't let you find a collision. It lets you predict the hash for an input with an unknown component in the prefix. If you have $h = H(x)$ for unknown (or partially unknown) $x$, you can generate $h_y = H(x \vert\vert y)$ for arbitrary $y$ (this is not strictly correct; I've ignored padding, but for the purposes of this discussion ...


4

RSA-OAEP does not provide "plaintext integrity in addition to confidentiality". ​ By the definition of PKE, anyone with the public key can encrypt whatever plaintexts they choose. ​ In particular, encrypting "a symmetric session key appended with a hash or eventually crc value for insuring integrity" doesn't help. ​ To get integrity, there has to be ...


4

Do not invent your own authenticated encryption mode. Use a standardized one, and use a well-supported library to implement it in your code. AES-GCM, AES-CCM, AES-OCB, and AES-CBC with HMAC-SHA256 over the ciphertext are all common options. Some great direction from Matt Green here: How to choose an Authenticated Encryption mode


3

FFX is not malleable. It's a strong tweakable pseudo-random permutation, where the "strong" here indicates that both encryption and decryption look like random permutations from the attacker's perspective. In particular, there's no relationship between the plaintexts of closely related ciphertexts (aside from the trivial observation that different ...


3

PCBC is provably secure for confidentiality, assuming you use a random IV like with CBC. The attacks you mention are all on the integrity rather than confidentiality of PCBC. No, you probably cannot construct secure authentication with PCBC and an unkeyed hash. For that you should instead use an actual MAC. While PCBC propagates errors, it only propagates ...


3

One solution is to use the choice of which equivalent message you send as a way to encode a MAC value. Take a "base message", where e.g. each word choice is the alphabetically first one. (Or some other known rule.) Calculate the MAC for that: MAC(key, message). The MAC should be $m$ bits or less. HMAC, possibly truncated would work fine. Encode that MAC ...


3

Signing and encrypting together is not secure in this method, at least in the way most would perceive security. For example, Bob would likely interpret this message as being sent from Alice to Bob. However, Alice may have sent it to Charles who decrypted and re-encrypted the signed message under Bob's public-key. In order to do this securely, you need to add ...


2

Which cryptographic algorithm would they want to use? That will really depend on the situation. To select the algorithms one should ask himself (at least) the following questions: Which standards do you trust? Which standard do you have to use? What computations can you afford? Symmetric, or public key based? It again depends on the situation. ...


2

Theoretically, there is no issue adding some kind of MAC on top of authenticated encryption's builtin. However, in practice there might be subtle flaws with composing the particular primitives you're using, or you may make an implementation flaw that renders them both vulnerable to a side-channel attack that didn't exist previously. Ultimately, it's best to ...


2

Instead of trying to invent your own protocol, you'd be much better off using something that is already out there. For example, you could use TLS to transport the data. Another option would be to use GnuPG and some other transport mechanism (post the file on a website to be downloaded by Bob, send it via email, etc). Now, to your question of does this ...


2

This answers a comment to Stephen Touset's fine answer. With SHA-256, or any collision-resistant hash, no known attack (including length extension) allows producing a file different from the original file and that has the same hash as the original, even if an adversary could choose the original. Even with the practically-broken MD5, or the broken SHA-1, no ...


1

Unfortunately, symmetric encryption do not provide integrity and digital signature functions. This is because symmetric encryption uses the same key for exncryption and decryption. This means that any who owns the decryption key can alter the data and no one will notice that the data is altered, because the same key was used for encryption. This means that ...


1

Use AES-OCB. It is patented, but now has a free license for any non-military software use. Unlike most other CAESAR candidates, OCB has been scrutinized for a while now, and meets all of your criteria other than 6 (assuming you have a good AES implementation). If the patent is simply too much for you, then use a heavily scrutinized patent-free tweakable ...


1

Suppose the server does not check the Client Finished value. This means that the MITM could change some handshake messages and the server would not know this (e.g., downgrade, as you mentioned). So, you could use this to fool a server that doesn't check the Client Finished value. If n bits are checked by the server, you have a 1/2^n chance of getting ...


1

First, if you mean to sign something, you should use a signature algorithm, rather than "RSA encryption" with private key, which on its own may be very weak. Now the main issue here is that the RSA part is only authenticating the nonce. Anyone who knows the AES key can just encrypt an arbitrary firmware image with a nonce they've already seen. This allows ...



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