# 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

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

4

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

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

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

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

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

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

TL;DR: You put less of a burden an any attacker trying to brute-force this. And please note: Implementing PBKDF2 shouldn't be much harder than implementing your approach. Now let's head over to the explanation why "your" scheme is really bad for password-hashing. The scheme you propose is that each try cost you exactly two hash-function evaluations. One ...

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

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

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

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

2

PBKDF2 is an acronym for Password Based Key Derivation Function, #2. As you already have a key you need a Key Based Key Derivation Function or KBKDF instead. Currently the most up to date one is probably HKDF, which was - very quickly - also recognized by NIST. There are other KDF's such as KDF1 and KDF2 which are easier to construct (not many libraries ...

2

Well PBKDF is for deriving keys from passwords, you don't need it if your master keys are already safe, just use something like HKDF. (faster) ECDH and DH are certainly the most secure options you have for negotiating session keys. Of course, as you do have a pre-shared master secret you have some interesting new options. Your usage of the HMAC sounds ...

2

Key stretching is only used to make small-entropy keys less vulnerable to brute force attacks. If it is (nearly) impossible to break the original key, than there's little sense in using a iteration count of more than 1. If the input to the function is as big (in sense of entropy in bit) as the output, then an attacker could just attack the algorithm which ...

2

That's because AES is not a password-based encryption algorithm. It's a block cipher. It may seem like a detail, but such details matter. In cryptography, and in security in general, details often matter. AES is a pair of functions, each of which takes a key and a 128-bit message and produces a 128-bit message. The two functions are called encryption and ...

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