Hot answers tagged hmac
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 ...
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 ...
4
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
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
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, ...
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
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 ...
1
I recommend you read a bit more about cryptographic design before getting into design of a HSM. Designing a HSM is basically designing a cryptographic protocol.
For instance, using AES-128-CBC is a bad idea, as it does not provide message authentication; instead, you should use authenticated encryption.
Similarly, rather than deriving a derived key in ...
Only top voted, non community-wiki answers of a minimum length are eligible
