# Tag Info

8

It looks like, given your adversary model, things should be secure. HMAC as a randomness extractor has been shown to be good, especially when we can assume the hash function is collision resistant. That paper also has some results which tell how you could guard against the collision resistance being broken (basically use a hash function with larger output ...

6

One problem with RC4 is that, while it does take a variable length input (up to 256 bytes), it's known not to be great at mixing those bytes together. Specifically, we see correlations between the RC4 key and the RC4 output stream. My first recommendation to you would be to use something other than RC4. About the only advantage RC4 has over most other ...

6

It's called a key derivation function because that's what you'd typically use its output for — as a key for some other cryptographic algorithm. (Of course, you can also use the output of Bcrypt for other purposes, e.g. storing it in a database as a password hash, but that's really a secondary use case.) In general, key derivation functions (KDFs) ...

5

I agree with the comments that SHA-256 should be fine here. However, if you already use HMAC-SHA-256 for PBKDF2, you could use HKDF Expand, which despite its name is defined even for output lengths shorter than input. In your case the output would be simply: $$\operatorname{HMAC-SHA-256}(\text{key}, \text{info} || \text{0x01}),$$ where 'info' is an ...

4

Given a EC public key, can a different, but plausible and functional private key be derived to match the public key? No, a public key will correspond to only one private key (with one minor exception, which I will explain below). With Elliptic Curve systems, the private key is an integer $d$ between 1 and $q$ (the order the generator point $G$), and ...

4

A key derivation function lets you derive keys from others. In this case I would use HKDF, which means using HMAC in a predefined way. Your key material is the keys $X$ and $Y$, so you can concatenate those to get the PRK for HKDF-Expand. An output key would then be $\operatorname{HMAC}(X||Y, \text{info} || \text{0x01})$, if the size of the HMAC is long ...

4

Yes, this should be secure, as it is largely compatible with KDF1 and KDF2 which basically use a 4 byte big endian encoding of the counter instead of a direct ASCII conversion to a byte. Note that this construct works fine for master keys (short length, high entropy) but may be vulnerable to length extension attacks if larger input is allowed. However, if ...

4

Poncho does a good job of explaining why you could use a KDF before RC4. But you are talking about a password and a PBKDF. A PBKDF does more than just provide a good way to extract entropy from the given input (the password): It uses a salt, which can be used to protect against rainbow tables (which could be created for known plaintext). This salt could ...

4

Yes. Salts are only there to make a particular key derivation globally unique. They have no requirement of secrecy.

3

As CodesInChaos pointed out, the major flaw with this is that filenames aren't unique. If you did this on a large scale, anyone who's been given a key for a filename could decrypt any file with that filename. Even if the contents of the file are different, and they weren't intended to be given access to that file. Here's another solution that has one unique ...

3

Yes, it's safe, as you can't calculate the secret key from the HMAC result. HMAC would be useless without this feature No, Bob will not be able to use his key to calculate the other keys, as long as you use a reasonable hash function (SHA-2 should fit) It's the same as 1., Bob doesn't get more information by more derived keys But when Bob get the key for ...

3

When you use a PRF to derive a key, there is the potential for collisions. If you derived a 128-bit key from each possible 128-bit number, you'd expect some of them to collide. Specifically, you'd expect only about 63% of all the inputs ($1-e^{-1}$) to appear as outputs. That means you lose less than a bit of entropy even if the original key had the full ...

3

Yes, it is possible to deterministically generate public/private RSA key pairs from passphrases. For even passable security, the passphrase must be processed by a key-stretching function, such as Scrypt (or the better known but less recommendable PBKDF2), and salt (at least, user id) must enter the key-stretching function; the output can then be used as the ...

3

Simple solution (with symmetric encryption): Assign each device an ID (probably already present) Store a master key on the server Use a KDF on the master key and the device ID to generate the key for the device. Then you only need the device ID on the device, and the server can re-create that key as required with the master key and the device ID. Of course ...

3

Yes, the output should have an entropy of 512 bit (or slightly less). Using it as a key is a good idea. If you want to generate more than 512 bits of key material out of the 512 bit you need to use a Key Derivation Function (KDF). You do not need to stretch the key, because it is no password and has a high amount of entropy - enough to make any brute force ...

3

I don't think it is a good idea, for two main reasons. Firstly, you are basing your security on the obscurity of a parameter that was not designed initially for being secret, which is a risky practice. It is similar to hiding the salt. Secondly, following your example, you may in principle think that a random number of iterations between 10 and 100,000 is ...

3

There are two things here: Encryption uses mode of operation, and not "AES alone". Some of them are randomized by an initialization vector - that means the encryption of the same text under the same algorithm is still randomized and not deterministic. The encryption methods take care of that. You only need the correct key to decrypt. Passwords are not ...

2

If you are concerned about database size, only the master key needs to be stored when you use HKDF. Ditto when sending it to another computer. Otherwise, two independent random keys are clearly secure and simpler to implement, so you should do that.

2

Is it subject to some class of attacks or is it just a really bad crypto nightmare which is only subject to brute-force attacks? You are calculating PBKDF2 twice, which takes twice as long. An attacker doing a brute force or dictionary attack only needs to calculate one of them to verify his guesses. That means you are making attacks twice as easy as ...

2

If you are certain that SecureRandom is a trusted, verified CSPRNG you can use that without HKDF without problems.

2

Although the answer is already accepted, I'll add an answer with a different look on things. It's safe, but that's not what HKDF-expand should be used for. The idea of HKDF-expand is to call it twice, once for each key, using the info element to distinguish between the two (e.g. info could be an ASCII encoding of the key name). Note that HKDF should have a ...

2

The once part inside of the nonce in CTR mode means effectively "once for this particular key". If you use a fresh key for each message (e.g. by encrypting it using public-key crypto or similar), you can use the same nonce for all the messages (or a size-zero nonce). The important part is that the combination of nonce and ctr-value (i.e. what is input into ...

2

It seems that you are trying to implement your own KBKDF (Key Based Key Derivation Function) using HMAC. Maybe it is better to use a pre-defined one. It would be more sensible maybe to use an HSM that is FIPS certified for NIST SP 800-108. These use one of the KBKDFs defined in NIST SP 800-108. You can still use the idea of the random by putting it in the ...

2

The algorithm produces a password based on the value of the time that is input as an argument. That value does not have to be the current time. For the purposes for which TOTPs are generally used, there is no value in producing the password for a time other than the current time step - it won't be recognized by the validator.

2

Probably because a simple cascade would only be stronger against some attacks, while opening the door to more implementation bugs. While bcrypt and scrypt are (password based) key-derivation functions, much of what is in the answers to this question about combining hash functions applies here. Different constructions give preimage resistance and PRF-ness, ...

2

As Trevis says, it's at least as safe: there's a simple reduction from the salted to the non-salted MAC, assuming the latter is secure in the standard "existential unforgeability under chosen message attacks". Assuming the adversary has full control of the salt, it also won't buy you anything security wise. In a slightly different setting, where the salt ...

2

Safe, yes, but it doesn't really give you anything. The only use for a salt is to mitigate precomputation attacks against a password. Since it is public, it gives you no extra MAC security. By the property of the MAC, no adversary can forge one without knowing the key, and by the security of your KDF (which includes the salt) no one should be able to get ...

2

Depends on what you mean by Keccak. There is actually a slight issue here that not all 256-bit Keccak variants have 256-bit preimage resistance. SHA3-256 (in the current SHA-3 draft) does have 256-bit preimage, but if you are using Keccak with 256-bit capacity it only has 128-bit preimage resistance. At least some of the earlier documents had 256-bit output ...

2

HMAC: The hmac version is considered slightly more secure than sha-256, assuming it's also based on SHA-256, because the HMAC formulation folds in the key material with 2 rounds of hashing, making it harder to use a chosen plaintext attack on the digest. SHA-256: SHA-256 should be relatively secure against chosen plaintext attacks, but it's better to be ...

2

all those concerns have been studied a lot and still are. I'll try to give some keywords for them. a web app that stores all data on the server in a way that the server can't decrypt the data even if it wanted to. Solution for this is User-side encryption. That's why, forget about the server chosing the encryption key himself. It's quite well spread ...

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