# Tag Info

12

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

7

Well, SHA-1 and SHA-256 are both limited to inputs of no more than $2^{64}-1$ bits; the HMAC architecture itself prepends a logical IPAD (which is 512 bits); hence both HMAC-SHA160 and HMAC-SHA256 are both limited to inputs of no more than $2^{64} - 513$ bits, which is about 2 exabytes. I rather suspect that this is not a serious limitation to your ...

7

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

6

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

6

Yes, there are currently no known attacks on HMAC-MD5. In particular, after the first collision attacks on MD5, Mihir Bellare (one of the inventors of HMAC) came up with a new security proof for HMAC that doesn't require collision resistance: "Abstract: HMAC was proved by Bellare, Canetti and Krawczyk (1996) to be a PRF assuming that (1) the underlying ...

6

Is the calculated MAC encrypted using AES? What is the purpose? How about signing and verifying? How does AEs Play a role here? Is the case here that the encrypted AES is HMACed for signing and the HMAC is verified No, the MAC is not encrypted per se, however, it is calculated in conjunction with a key (independent of the encryption key). Simply ...

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

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

5

This is highly insecure, for the same reason that ECB mode and simple substitution ciphers are. Every time you use the word the in your message, it will be encrypted the same way. The same goes for other, lower-frequency (but still fairly common) words -- like as or with or will (or any of hundreds of other examples). This is a humongous clue to ...

5

Not using cryptography on URI: If you store subscribers on a database, maybe you could also store additional (say) 128-bit random value on some column when there somebody about to unsubscribe. This way there is no meaning for the value beyond this transaction and it cannot e.g. leak anything about the key. If you cannot use additional data on the ...

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

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

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

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

Why stop at 8 digits? 10 digits will be even more secure. Or 12. The output of the HOTP algorithm is 160 bits so you could go all the way to about 48 digits. Bottom line: 6 digits is secure enough for most applications and that is all that counts. Any more is inconvenient for the user and slightly more expensive when used in a hardware token (8 digit ...

4

"Frequency analysis of the output might help determine simple words in the ciphertext such as 'the' etc if that word is repeated and sent multiple times. This isn't necessarily a problem as it's only a simple word and doesn't convey much meaning to the message". If the word "the" doesn't convey much meaning, then why have you used that particular ...

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

3

What I did in one of my password generators is that given a secret key $K$, public data $\text{Pub}$, I first generate a solid "master key" $K_m$ via key-stretching the secret key using PBKDF2 (any other key derivation function would work, I just happened to have that lying around): $$K_m = PBKDF2(K, \text{salt, iterations, } \cdots)$$ And then derive ...

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

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, feasibility to guess the plain text size might be a serious vulnerability in real life scenarios. For instance, in traffic analysis the approximate length of the messages in a communication, might reveal enough information about what is communicated, for it to be possible to deduce the gist of it. If such threats exist in your case, however, you will ...

3

This seems like it may be an unnecessary complication. Why not encrypt the whole file at once, and HMAC the entire result? Or alternatively, use an encryption mode that has this built in, like AES-GCM? But to answer your original question, no, it does not introduce any weaknesses. If it did, knowing the value to within 16 bytes wouldn't be much of a ...

3

The theoretical problem with using text encoded keys, is that it doesn't necessarily conform with how the keys are assumed to be formatted in security proofs such as this one. If you are using HMAC with an underlying hash function that is still believed to meet the requirements of a cryptographically secure hash function, such as the SHA-2 family of hashes, ...

3

Before we jump into this question, you first need to know a bit about the internals of hash functions with the Merkle-Dåmgard construction. Here's a pretty picture from Wikipedia: In this diagram, you see the compression function $f$ being fed the message blocks along with the output of the state of the previous compression block (or the IV). The final ...

3

The answer to this question follows directly from the answers to Should we MAC-then-encrypt or encrypt-then-MAC? and the comment thread here. In short: Your scheme is computationally secure (IND-CCA2 and INT-CTXT) assuming that HMAC is a computationally secure privacy-preserving MAC; but your scheme is wildly impractical, as fgrieu explains, so it is not ...

3

Your scheme would make a nice puzzle for amateur codebreakers. That's about the best that can be said for it. It does not meet the generally accepted standards for a modern encryption scheme; in particular, it is not semantically secure. In fact, the security of your scheme would be seriously compromised if an attacker obtained even a small amount of ...

3

Decoding AES256-CTS-HMAC-SHA1-96 AES256 = AES using 256-bit key CTS = ciphertext stealing HMAC-SHA1-96 = HMAC using SHA-1 hash function with mac truncated to 96 bits. The benefits of HMAC truncation are discussed in FIPS PUB 198-1, chapter 5. For HMAC-SHA1 96 bits is very common truncation, used for instance by IPsec/ESP. For figuring out what key ...

3

The generator in the question internally transforms the $512$-bit string designated tag into an output determined either: as $1/10^4$ of a non-negative integer less than $10^6$, whenever the "If the result is smaller.." clause applies; as $1/10^2$ of a non-negative integer less than $2^{12}$, otherwise. Determination process 2 occurs for ...

2

Inspired by Henrick Hellström's comment, I think you need to dig a bit deeper into what “difficult” means. Pre-image resistance means that given $h$, it's difficult to find $m$ such that $h = H(m)$. Intuitively speaking, your only chance is to have started with an $h$ that is in the relatively small set of already-computed hashes. Now suppose you have $h'$ ...

2

There aren't any known attacks on the PRFness of HMAC-SHA256 better than brute force. (So you can truncate that MAC to length L where $\:\:\frac1{2^L}+\epsilon\:\:$ is an acceptable risk of forgery.) To reduce the impact of a forgery without making the ciphertext any longer, one should use a format-preserving encryption (FPE) scheme that is secure against ...

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