Hot answers tagged hmac
13
This is something I tend to disagree somewhat with Colin Percival on.
You should use Encrypt-then-HMAC if and only if you can get it right. The biggest pitfall is using a short-circuiting string comparison versus a constant-time string comparison. Given the former, people can use timing attacks to forge valid HMACs for arbitrary ciphertexts. With an ...
13
As Chris Smith notes in the comments, HMAC is a specific MAC algorithm (or, rather, a method for constructing a MAC algorithm out of a cryptographic hash function). Thus, HMAC can be used for any application that requires a MAC algorithm.
One possible reason for requiring HMAC specifically, as opposed to just a generic MAC algorithm, is that the HMAC ...
9
Those "magic numbers" are related to the security proof behind the HMAC construction.
In their Crypto'96 paper, Bellare, Canetti and Krawczyk first prove that $\mathrm{NMAC}_{(k_1, k_2)}(x) = F_{k_2}(F_{k_1}(x))$ forms a secure MAC ("message authentication code") provided $F_k(.)$ is an iterated and keyed compression function enjoying some good security ...
9
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 ...
8
No, you are not leaking any information except how to MAC those specific values with the specific key you are using. Using a short message is exactly as secure as using a long message.
For the following, remember the definition HMAC (K,m) = H((K ⊕ opad) || H((K ⊕ ipad) || m)). There are two hashes here, an outer hash and an inner hash nested inside the ...
8
Brute forcing the key would hardly be an issue: 128-bit keys (assuming they have been properly generated) are in a space which is way too large to be successfully explored by brute force; and 256-bit keys (the kind you put in AES-256) are even more larger. Whether AES is "faster" than HMAC or not does not make such brute force more feasible: even if each key ...
6
The original security proof of HMAC, as well as a new one not requiring collision-resistance of hash, are for the construction hash(o_key_pad ∥ hash(i_key_pad ∥ message)) with o_key_pad different from i_key_pad (and both filling a block). That's the rationale for at least one of the constant. The other plays no role, it just must be different from the first. ...
6
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 ...
5
TL;DR, an HMAC is a keyed hash of data.
A good cryptographic hash function provides one important property: collision resistance. It should be impractical to find two messages that result in the same digest.
An HMAC also provides collision resistance. But it also provides unforgeability. In order to generate an HMAC, one requires a key. If you only share ...
5
It is indeed safe to send it along with the ciphertext; the attacker can't learn anything from it (other than possibly how many packets has been generated so far, if you use a counter to generate the IVs), and if the attacker modifies the IV, the resulting message will fail to decrypt (with high probability).
Existing protocols that can use GCM (TLS, IPSec) ...
5
You could have "protocol ID's" which describe the set of primitives and parameters each library version is capable of using. You may deprecate older ID's once they become obsolete by just removing them from some future version, this way you can reject files which are deemed too old (or too recent) and thus unsupported, as long as you don't change how you ...
5
CodeInChaos has it right about the infeasbility of this against a random key; however, lets run the numbers to see how extremely correct he is:
Let us assume we are attacking HMAC-MD5 within TLS; this has a 128 bit key.
The fastest GPU server (actually, it has 25 GPUs internally) can test about 400 billion keys per second.
Let us assume that we, having a ...
5
Clearly, if you had been using AES-256-CBC for confidentiality and AES-256-CBC-MAC for authentication, it would not be secure to use the same key for both confidentiality and authentication. Hence, using the same key for confidentiality and authentication cannot generally be secure; you need additional premises to arrive at that conclusion. In your case it ...
5
Points 3 and 4 are a secure way of storing the input to bcrypt (with appropriate choice of parameters for bcrypt).
Points 1 and 2 aren't necessary but don't harm:
they would add a small amount of extra computation for an attacker is possession of the password database that wants to do a dictionary attack;
the attacker wouldn't be able to straight-out use ...
4
Summary: I don't know of any good reason why it has to be this way. In practice, I don't think it is necessary to inject the password into every iteration. As far as I know, I think the construction would still be secure (in practice) if you used the salt and password only in the input to the first iteration, and then just repeatedly hashed the result many ...
4
As a Skein co-author, one of the properties of the UBI chaining mode is to give you HMAC-like properties in one pass. Skein itself consists of the Threefish tweakable block cipher, the UBI chaining mode, and some proofs that extend tweakable block cipher theory into a tweakable hash function theory that reduces the security of the hash function to the ...
4
You got some notation wrong. There is no algorithm like "AES-GCM-SHA-256".
AES is a block cipher, i.e. a pseudorandom permutation of 128-bit blocks. It itself only allows encryption for messages of size 128 bits (= 16 bytes), with a limited security guarantee.
When you mean "encrypt the data using AES", you actually mean "use AES with some mode of ...
4
Your worst case scenario is that all $18$ characters in the Base64 string are letters — this allows for $2^{18}$ possible collisions due to case-insensitivity. A normal SHA-1 hash is $160$ bits, and therefore has $2^{160}$ possible combinations. Divide by the number of collisions, and you have an effective strength of $142$ bits.
That said, I wouldn't ...
4
I'll assume that "sha256hmac" designates HMAC using SHA-256 as the underlying hash function.
HMAC is used for its intended usage: the first parameter privatekey is a key, I assume random and secret, of fair length (128-bit); the second parameter word is a (possibly public) message; output is a (possibly public) cryptogram. Observing any number of (word, ...
4
Yes, this is fine, at the record level. (What you've built would be classified as a "Encrypt-then-Authenticate" scheme in the literature, and there are standard provable security results for such schemes.) Well done on constructing a solid, well-engineered cryptographic scheme.
An AEAD mode would spare you from having to invent such a scheme, but what ...
3
Put simply, if you're using a simple hash of a file to guarantee file-integrity, then an attacker could modify the file, re-calculate the hash of the modified file, and replace the old hash with the modified one. With a HMAC, a key is used when calculating the hash value, so unless the attacker has the key, they're unable to calculate a valid hash value of ...
3
At a glance, I see no obvious weaknesses. Obviously, the security proof of HMAC won't apply to this construction, but that doesn't necessarily make it insecure — it just means that we can't prove its security (given appropriate assumptions on the underlying hash function), or at least that we'll need different methods to do so. Certainly, none of the ...
3
There are two answers: the "engineering" answer, and the "principled" answer.
The engineering answer is that, in practice, if you generate two keys using two different info strings, I suspect you'd probably get away with it without problems. If we model the hash as a random oracle (admittedly a very strong "assumption"), then I suspect it might be possible ...
3
A key derivation function is intuitively "purifying" the entropy in the group element Z into uniformly random (looking) bits that can used as a key for other purposes. It is not designed to produce "multiple keys" from the same Z, and one should definitely not call the KDF on the same Z twice (even with different salts) and expect to get two independent ...
3
GCM mode is best, as it can not be attacked using padding oracle attacks, which are much more common than commonly thought. It is also the only one providing integrity protection, something that is certainly much overlooked.
Make really sure your NONCE is random though, or use one that is uniquely defined (even in time) within the database.
...
3
Well, if you are using CBC mode in the recommended way (always using an unpredictable IV), then it turns out to be easy.
With CBC mode, the value that is presented to the encryptor is always a plaintext block exclusive-or'ed with an IV or a previous ciphertext block. If plaintext blocks are uncorrelated with both the IV and the previous ciphertext block ...
3
I would say that CBC+HMAC mode is the best of the three (although not the fastest), because of the various security requirements on the IV/nonce.
For GCM and CTR, the counter must be unique, for every pair encryption key/plaintext. I assume the key will be always the same. Uniqueness is very difficult to securely achieve in practice. If you rely on some ...
3
As Stephen Touset explains, this is perfectly fine and completely safe. There is no need to update the email addresses everyone is using. The security level you achieve is basically that of a 142-bit MAC, so an attacker who tries to guess a MAC value (with one try) has about a $1/2^{142}$ chance of success. That's a sufficiently small number that the ...
3
Yes, authenticate the IV. If an attacker changes the IV while keeping the rest of the ciphertext intact, they'll change the message. Just because they can't change the message to an arbitrary value doesn't mean they can't cause harm (if nothing else, they can send random junk until they hit a valid command or a bug in your parser, or feed you invalid data).
...
3
Designing an HSM or other secure device is relatively easy; making it reliable even in the absence of adversary requires careful engineering; making it safe against adversaries with some level of physical access is hard; demonstrating that it is safe (for some definition of that) is even harder.
One thing to worry about is integrity of stored data ...
Only top voted, non community-wiki answers of a minimum length are eligible
