What's the deal with Deno? We talk with a major contributor to find out. Listen now.

# Tag Info

212

These types of cryptographic primitive can be distinguished by the security goals they fulfill (in the simple protocol of "appending to a message"): Integrity: Can the recipient be confident that the message has not been accidentally modified? Authentication: Can the recipient be confident that the message originates from the sender? Non-repudiation: If the ...

65

A Message Authentication Code (MAC) is a string of bits that is sent alongside a message. The MAC depends on the message itself and a secret key. No one should be able to compute a MAC without knowing the key. This allows two people who share a secret key to send messages to each without fear that someone else will tamper with the messages. (At least, if ...

45

I'll answer in order: Output size = input size That's correct, GCM uses CTR internally. It encrypts a counter value for each block, but it only uses as many bits as required from the last block. CTR turns the block cipher into a stream cipher. Note that this doesn't include any additional authenticated data (AAD) that needs to be send, the optional ...

42

Although there are already many answers here, I wanted to strongly advocate AGAINST MAC-then-encrypt. I fully agree with Thomas' first half of the answer, but completely disagree with the second half. The ciphertext is the ENTIRE ciphertext (including IV etc.), and this is what must be MACed. This is granted. However, if you MAC-then-encrypt in the ...

38

Everything was changed between SHA-2 and SHA-3. In the specific case of the "length extension attack": the issue is that SHA-2 process data by splitting it into elementary blocks (64 or 128 bytes, depending on the SHA-2 variant), and produces for each block an output which has exactly the same size as the function output. Moreover, the output for a complete ...

35

$\operatorname{Encrypt}(m\|H(m))$ is not an operating mode providing authentication; forgeries are possible in some very real scenarios. Depending on the encryption used, that can be assuming only known plaintext. Here is a simple example with $\operatorname{Encrypt}$ a stream cipher, including any block cipher in CTR or OFB mode. Mallory wants to forge an ...

28

You're missing the most important strength of HMAC: it comes with a proof of security (under some plausible assumptions). The outer key plays an important role in the proofs. The best place to learn more is to read the HMAC papers: Message authentication using hash functions: The HMAC construction, Mihir Bellare, Ran Canetti, Hugo Kawczyk, CryptoBytes ...

25

From the proposal of GCM (rewritten if statement): if $\operatorname{len}(IV) = 96$ then $Y_0 = IV || 0^{31}1$ else $Y_0 = \operatorname{GHASH}(H, \{\}, IV)$. So there are additional calculations for IV's other than 96 bits. This is why the original proposal has this recommendation: 96-bit IV values can be processed more efficiently, so that [ed: ...

23

HMAC was there first (the RFC 2104 is from 1997, while CMAC is from 2006), which is reason enough to explain its primacy. If you use HMAC, you will more easily find test vectors and implementations against which to test, and with which to interoperate, which again explains continued primacy. Being the de facto standard is a very strong position. On many ...

23

Given that you use the SHA-3 hash (which is resistant against length extension attacks), would you still need to go through that procedure in order to produce a secure MAC? No, you don't need to do that, but you can. Needless to say we'd still use a key, which we prepend or append to the message, but is that sufficient for a MAC? Yes, you can prepend ...

22

Poly1305 is a universal hash function. The output of that function cannot be used safely without being encrypted. In order to encrypt it, any cipher can be used. AES was used as an example in the paper, but the very same paper mentioned: Users can switch from Poly1305-AES to Poly1305-AnotherFunction, with an identical security guarantee. All the efforts ...

21

Moxie Marlinspike calls it in his article http://www.thoughtcrime.org/blog/the-cryptographic-doom-principle/ the doom principle: if you have to perform any cryptographic operation before verifying the MAC on a message you’ve received, it will somehow inevitably lead to doom. He also demonstrates two attacks which are possible because of trying to ...

21

Length extension attack The reason why $H(k \mathbin\| m)$ is insecure with most older hashes is that they use the Merkle–Damgård construction which suffers from length extensions. When length extensions are available it's possible to compute $H(k \mathbin\| m \mathbin\| m^\prime)$ knowing only $H(k \mathbin\| m)$ but not $k$. This violates the security ...

19

No. A MAC guarantees unforgeability but not pseudorandomness. It is true that all MACs that I can think of right now are essential pseudorandom functions, but this does not mean that the MAC definition implies this. Indeed, it clearly does not. So, conceptually, you need a pseudorandom function. You can assume that HMAC is a pseudorandom function. It is ...

18

TL;DR No, the approach is not secure. Use a standard like CMAC instead. Or even better, check your AES accelerator module to see if it supports any AEAD modes of encryption like GCM, CCM, EAX. Long Version In order for a message authentication code (MAC) to be secure, an adversary with oracle access to the MAC (basically this means the adversary can send ...

17

If this requires a single answer among 1/2/3/4 (rather than none), I would select 3, by the following reasoning: Digital Signature provides confidentiality while message authentication code can not We can summarily exclude this, since a Digital Signature simply does not provide confidentiality. Digital Signatures works faster than message ...

17

Would it not be easier simply to send $E(m||s,k)$ where s is a salt shared across the system? Yes, that would be simpler; however, that would not (in general) be secure. The assumption you are making is that if someone modifies the ciphertext in any way, then the last few bits of the resulting plaintext must also be modified. This is often not the case: ...

16

Alas, there is no simple satisfactory answer to this question. What I can offer is a very strong property that $m \mapsto H\bigl(k \mathbin\| H(k \mathbin\| m)\bigr)$ fails to achieve; a more pedestrian property which even HMAC may or may not achieve but is typically asked to achieve; a reason not to worry about it for any new systems; and some historical ...

15

While the one time pad seems obvious, I am not sure about Carter-Wegman-Style message auth. What they are talking about is a Carter-Wegman authentication method that uses a stream of random bits as a part of the process (just like a one time pad uses a stream of random bits to encrypt). Normally, when we implement CW, we use some almost universal (au) ...

14

The construction you are proposing is called the "envelope" or "sandwich" MAC, it predates HMAC, and it is in fact secure—provided the key and message are appropriately padded. That is, $$\text{SHA256}(k \parallel m \parallel 1 \parallel 0^{b - 1 - (|m| \bmod b)} \parallel k)$$ is secure, as long as $k$ is the underlying hash function's block length $b$ (...

13

Using $H(m\mathbin\Vert k)$ with hash function $H$, message $m$ and key $k$, is one possible way to build a MAC algorithm. It is not necessarily a good one; it depends on the used hash function. Even when it is a good one, that does not preclude the possibility of other, "better" algorithms (e.g. for performance). As an illustration of potential security ...

13

I think Encrypt-then-MAC does not deliver Plaintext integrity, but only ciphertext integrity. If the MAC over the ciphertext is OK but then we use the wrong key to decrypt (for whatever reason), then the recipient receives a plaintext that the sender did not send and did not vouch for. If this can happen, this is a violation of plaintext integrity. So, ...

13

I'll assume 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 $A=... 13 Given some string s I want to [integrity protect], are following methods are equivalent to produce message with signature, assuming it does not matter whether s is visible in message or not? Absolutely not; with AES_CBC, if the attacker modifies one particular block of the ciphertext, then the decryption of the modified ciphertext will have two blocks ... 13 What are those existing constructions? Usually people consider three to four scenarios for authenticated encryption for embedded environments: Constrained for ROM + RAM In this case you probably would want to use as few primitives as possible and using something like the EAX or CCM mode to use your block cipher for both authentication and encryption. (... 12 Yes, this would be secure. CTR (Counter) mode based on keyed function$F_K$is secure as long as its output $$W_i = F_K(i)$$ is unpredictable given previous outputs $$F_K(1),F_K(2),\ldots,F_K(i-1).$$ This requirement is essentially the definition of a pseudo-random function (PRF). Most HMAC instantiations with widely used hash functions are believed to ... 12 One simple cryptographically secure rolling hash function is the following: $$F_{k1,k2}(x) = E_{k1}(R_{k2}(x))$$ where$R_{k2}(\cdot)$is a non-cryptographic rolling hash function (e.g., Rabin-Karp), and$E_{k1}$represents encryption with a block cipher (e.g., AES). By$R_{k2}(\cdot)$, I mean that the parameters of the rolling hash should be derived from ... 12 The MAC value should be calculated over all of the input, not just the first block. The chaining of CBC makes sure that the bits in the last block of ciphertext depends on all the previous blocks. 12 Can the$AES_k(n)$portion be simply replaced with$k \oplus n$? No, but you're close, it would be replaced with$k + n$, where$+$is addition modulo$2^{128}$; then it becomes informational theoretic. Here's why: Poly1305 is based on a polynomial universal hash. This is a hash where we select a finite field$GF(p^i)$, select a private value$x \in GF(p^...

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