Hot answers tagged

12

I don't think there is any official limitations when it comes from standardization bodies such as NIST. However, there do seem to be some papers such as New Generic Attacks Against Hash-based MACs. They show that HMAC may have less security than previously thought after the birthday bound. Generally, if you have a hash output size of, say 256 bits for SHA-...


9

This is a problem created by the library. Either the HMAC algorithm is skipped entirely, or - more likely - the HMAC authentication tag is generated and then forgotten. The reason is likely the spotty to non-existent handing of authenticated ciphers in the OpenSSL command line and (likely) higher-level functions. The string is recognized by the cipher ...


6

Is there an efficient way to do this? 32 bytes of "good randomness" provided by hashing some secret value gives much less entropy than required to directly compute a sample of 100 items from a list of 100000. If this is required for any cryptographic purpose, you must use a good CSPRNG to convert your starting entropy into as much randomness as ...


5

Well, supposing everything is properly domain separated, nonces are always generated randomly for encryption queries, and your KDF behaves like a perfectly random function, the first step is to bound the probability of a nonce repeat. A birthday bound tells us that this happens with probability at most $$ q^2/2^{256}\,, $$ where $q$ is the number of ...


5

For basic AES, it is easy to find two keys in this way. Take any $key1$ and $plaintext1$ and compute $c=AES_{key1}(plaintext1)$. Then, take any $key2$ and compute $plaintext2 = AES^{-1}_{key2}(c)$. It follows that $AES_{key1}(plaintext1) = AES_{key2}(plaintext2)$. Having said this, if AES is used in an authenticated encryption mode with a MAC, this may not ...


5

HMAC is a type of MAC. The output of a MAC is called a "tag". Not all MAC (algorithms) are HMAC. MACs are not required to be one-way or collision resistant for someone who knows the key. HMAC, however, inherits the one-way-ness and collision resistance of the underlying hash function. A CBC-based MAC is mentioned as a hint because it is almost trivial to ...


4

The usual lectures about the (in)securities of SHA-1 will be skipped. The standard defining SHA-1 is NIST FIPS 180 (recent revision(s)), it specifies how to pad a bit-string into a form suitable for processing in the compression function specified for SHA-1, which it also specifies. As of 2019, all current SHA-series hash functions are single-pass - that ...


3

Indeed FIPS 140-2 requires a module to validate itself, and this has no security benefit. In order for a code integrity check to have a security benefit, both the code that performs the verification and the data that it uses (hash value for a hash, MAC value and secret key for a MAC, public key for a signature) need to be integrity-protected (and with a MAC, ...


3

No for this scenario where the message is statically sized, using a HMAC is not required. You can use a sufficiently strong hash such as SHA-2 or SHA-3 instead if you must. That said, it would probably be more neat to use a HMAC or even KDF. The advantage is that these algorithms do take input keying material as a separate parameter. This might be ...


3

TLDR: Such pre-hashing is weaker, and slower on a standard computer. Most serious security problem: in order to break the MAC with pre-hasing, it is enough to find two different messages with the same SHA-256 hash, and that's an offline attack (it requires a single query to a MAC oracle/device knowing the key). Such breaking of SHA-256's collision ...


3

So in my case is it safe to use PBKDF2 as hashing tool - to hash any thing like (timestamp+sensitive_info+extra_info) with a SECRET_KEY just similar to hmac? The reason that a Password Based Key Derivation Function or password hash is used is because passwords are generally not considered secure enough. The iterations or work factor of such a PBKDF makes it ...


3

If your secret material (you call this my secret so I'll use that name) is chosen with sufficient min-entropy, then yes this scheme is acceptable. my secret, however, must be in itself sufficiently hard to guess; it becomes effectively a password cracking problem. As such, I would suggest my secret be a randomly generated keyfile, or at least a really secure ...


3

No, it is not providing confidentiality as it is not encrypting your message but fingerprinting it. It provides authentication and integrity because only the creator (or the one who knows the secret) can check the fingerprint for validity. Though the creator doesn't know which of the two qualities is compromised if the validation fails.


3

"brute force a PBKDF2-HMAC-SHA1" is not about collisions (at least, if a single hash is targeted, or if there's salt at the input of the password hash). It's a preimage attack. The hash output by SHA-1 is 160-bit. That's 20 bytes (not characters; these are different notions, and why we have character encodings). It can take $2^{160}$ values. The ...


3

If the MAC is theoretically secure, but its implementation has a side channel (like by Differential Power Analysis, maybe even timing) leaking information about the MACed message (but not the key), and the encryption is secure including it's implementation, then neither MtE nor MtEtM are safe (because the side channel leaks about the message), but EtM is ...


3

You are describing encrypt-then-MAC using AES-CTR for encryption and HMAC for the MAC. This indeed results in authenticated encryption. There may be better choices for the key derivation function, but I'm not very familiar with the options, so I'll let others comment. I don't understand why you salt the KDF when deriving the key. This just means that you ...


2

Your quote is wrong: The wikipedia page for Length Extension Attacks says "Note that since HMAC doesn't use [Merkle–Damgård constructions], HMAC hashes are not prone to length extension attacks." The part that you've paraphrased in square brackets is a misreading of the original, which reads (my boldface): When a Merkle–Damgård based hash is misused ...


2

Is this protocol design secure? See below. What would be the advantage to use HMAC (or any other MAC) instead of AES encryption? HMAC was originally proposed as a construct that turns a Merkle-Damgaard hash function based on compression functions built from block ciphers, into a message authentication code. Although there's no decryption in HMAC, you ...


2

Is it secure to use the same shared symmetric key, used for encryption with the arbitrary generation of a new nonce per message, for unlinkable contact signaling? Yes, as long as adversaries do not manage to get hold on the key. That condition implies None of the multiple holders of the key in the proposed system are adversaries. Each is competent at ...


2

Recall the definition: a cipher is AE-secure iff it is secure against chosen ciphertext attacks and has ciphertext ingegrity. Try going through the attack games with $(E_1,D_1)$ and $(E_2,D_2)$: if the adversary succeeds, can he succeed for $(E,D)$? It's fairly easy to see that $(E_1,D_1)$ and $(E_2,D_2)$ are CPA-secure. If the adversary can distinguish ...


2

I read one answer to a similar question that put forth that a hash function is distinct from a PRF, however I've also found materials purporting that cryptographic hash functions are PRFs, and I'm not sure now. Those latter materials are wrong. Random function A mathematical function (i.e. a "pure" function) whose output values depend only on its inputs, ...


2

No, it is not useful to change the key between invocations of HMAC. That would not change the expected probability of collision, which remains about $n(n-1)/2^{257}$ for $n$ values under a model of HMAC-SHA-256 as a PRF. For $n=2^{40}$ (over a million million, the UK bilion), that's less than $2^{-177}$, the probability of 177 consecutive tails with a fair ...


2

You can just use a hash tree with a pre-configured node size then only the last hash value would be vulnerable to a length extension attack. In that sense this is not that different from performing a HMAC over a single hash. However, that's kind of besides the point. A length extension attack is only applicable for keyed hashes. As the hashes are not keyed ...


2

Even collision resistance is not sufficient to make HMAC unforgeable, so neither is second-preimage resistance. Let $H : \{0,1\}^* \to \{0,1\}^n$ be a collision resistant hash function. We define the hash function $H' : \{0,1\}^* \to \{0,1\}^{n+1}$ as $$H'(m\Vert b) = H(m)\Vert b,$$ where $|b|=1$. Since for any $m_0\Vert b_0$ and $m_1\Vert b_1$, it holds ...


2

Be reassured: both $\text{HMAC}(k,m)$ [instantiated with a strong hash function, e.g. SHA-512; even SHA-256 would do] and $\text{AES}(k,m)$ [understood as direct encryption of 128-bit $m$ with the block cipher] are believed to be computationally secure Message Authentication Codes for the foreseeable future when the key is 256-bit, irrespective of how many ...


2

It's indeed a genuine concern. How to fight this? Well, once client had provided the SHA256 hash of the file (to quickly index the file on the server), your server then provide a random one-time key and ask the client to hash the file again with HMAC and the key. Since the key is one-time and random, adversaries have little chance at guessing the key and ...


2

I'd confidently go for "first N bytes". It's quite universally recognized that the output of practical cryptographic hashes are bitstrings or bytestrings; where a bytestring starts is subject to little ambiguity; and how to count starting from that is unambiguous. That's not to say that an error is impossible. In particular, the MD5 output is 128 ...


2

In general, we always assume that the mode of operation is known ahead of time. In practice, this should be bound to the key - if the key is only used for a single mode of operation then the above shouldn't happen. However, if the same key is used for multiple modes of operation, then the mode ID should be made part of the ciphertext and therefore included ...


1

GPG doesn't use post-quantum signatures, so any current implementation of GPG would be unable to provide such security; regardless of the hashing algorithm used. However, let's assume we have post-quantum signatures in our GPG implementation: If the hash is sufficiently large, and the hash itself is secure, an attacker not knowing the HMAC key would be ...


1

Could this scheme be used as a nonce-misuse resistant alternative for AES128-GCM? Well, no, it's not nonce-misuse resistant. Consider the case where you use the same nonce twice (which is pretty much the definition of 'nonce-misuse'); there, you'll end up encrypting two different messages with the same GCM key and IV, which would leak the xor of the two ...


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