Hot answers tagged hmac
13
Actually, HMAC might still be secure for a hash function that is broken (with respect to the requirements of a cryptographic hash function, such as primary preimage resistance, secondary preimage resistance and collision resistance), but it must not be too badly broken. If you read the original paper, you see that the authors assume things such as the hash ...
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 ...
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 ...
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 ...
9
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 ...
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 ...
7
I really don't have an answer (other than saying that storing a hash of the password is good as any other way of solving your immediate problem; there are other ways, but they all allow an attacker to run a dictionary attack on the database).
On the other hand, I do have these comments on what you're doing:
If getting decrypted gibberish will really crash ...
7
The short answer is: 2128 operations, no known birthday-like attack.
The long answer: when HMAC was first published, it came with a security proof, tailored for iterated constructions like Merkle-Damgård. In a MD hash function (MD4, MD5 and the whole SHA family are MD hash functions), the data to hash is processed by blocks with a compression function: the ...
7
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 ...
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. ...
5
What you're suggesting is likely good enough, and very likely far more secure than just about any other lock on your house.
If the only hash function you can find is MD5, go with it, but make sure to HMAC with the passphrase as the key. Again, it's not going to be the weak point of your security. I'm sure I could pick the lock on your front door faster than ...
5
The usual ways to check that a user-supplied encryption key is correct are to either:
store a (salted) hash of the key, and check that it matches, or
encrypt a (partially) known block of data with the key and check that the decrypted output has the expected form.
The former method is exactly same as what your OS, for example, does to verify that you ...
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
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
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
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
You may want to take a look at the original HMAC paper by Bellare, Canetti and Krawczyk (1996), or at the new security proof by Bellare (2006).
As far as I can tell at a glance, there's nothing in either of these proofs that would actually rely on the inner and outer hash functions being the same function, as long as both of them satisfy the appropriate ...
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
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
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
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 ...
Only top voted, non community-wiki answers of a minimum length are eligible
