# Tag Info

8

First the theoretical explanations: Integrity and authenticity are different goals to achieve, but both are achieved (for symmetric encryption) with a MAC. You should probably be using encrypt-than-MAC or an authenticated cipher unless you have very good reasons not to. No blanket statements can be made though. HMAC: HMAC is a often used construct. It ...

6

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

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

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

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

4

Indeed hashing is used to ensure integrity, but not this way. What you have in mind it seems is sending (msg, Hash(msg)). Indeed this is not secure because of the attack you describe. The first step starts with something you say by yourself: hashing algorithms are universal algorithms The name is not univesal but public, it means anyone knows it. ...

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

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

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

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

That's a lot of questions, I'll try and answer in order. A hash or message digest alone is not secure because anybody can calculate and thus substitute a hash value. If you (correctly) add a key to the mix then you get a HMAC, which can be used. Nowadays often a HMAC is used, or an authenticated mode of authentication such as GCM, CCM (for packet ...

2

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

2

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

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

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