# Tag Info

4

As far as I know (which, admittedly, might be limited; I do not claim to possess encyclopedic knowledge of attacks on KDFs), there are no known practical attacks against KDF1 or KDF2 (which are also mentioned on this page, following ISO-18033-2) when instantiated with a secure hash function. Regarding the relative security of these KDFs vs. HMAC-based KDFs ...

4

It is my understanding that a KDF adds entropy, whereas a hash loses information. Password Based KDFs can be seen as hash functions (or families of hash functions, depending on your definition), just ones with a lot of complexity. It is sometimes said that they "add entropy" but that usually means either they combine entropy from a salt into the ...

3

If I got the code correctly, it works in the following way: Computes digest $D = SHA256(password + salt)$ Computes table T with $N=MEMSIZE /32$ elements: $T_{0}=D, T_{i}=SHA256(T_{i-1})$ Set $R=T_{N-1}$ Update $R$ by mixing it with $T_{0}$, $T_{1}$, ..., $T_{N-1}$, where "mixing" is a byte addition or subtraction depending on value of the byte ...

2

Background When defining protocol compliant with NIST SP 800-108, you just need to pick suitable options, which work well with your protocol. If there is a need to be compatible with a specific pre-existing protocol, you may want to take a look at NIST SP 800-135Rev1, which defines application specific key derivation functions. It is notable to recognize ...

2

Does input truncation using SHA-256 expose any potential weaknesses? No, hashing the passphrase with SHA-256 will be no stronger or weaker than feeding it in directly. If you go with Scrypt (which I would recommend you do), there are no restrictions on the size of the passphrase... and Scrypt consumes it internally with one round of PBKDF2-HMAC-SHA256 ...

1

I wouldn't recommend rolling your own KDF. PBKDF2 is easy to implement with access to SHA-256, and with a high enough iteration count will still slow down an attacker, even if not as much as scrypt. From a quick look, it seems that you are walking the memory linearly both when generating the SHA output and when collecting the data output data through ...

1

While your post is hard to decipher, I understand you need to split your master key $(MK)$ into three shares $DK_i$, of which any two would suffice to recover $MK$. This is called secret splitting (or sharing), or a (2,3) threshold scheme. One of the many possible ways to do this is with Shamir's Secret Sharing Scheme (SSSS). It is proven secure when ...

1

Internally scrypt has a huge state space, from which it derives 256-bit output blocks using PBKDF2-HMAC-SHA2, so it's basically already doing what you suggest as 1., just with much larger inputs. Adding another level of HMAC on top will not help. In general, you need to be careful when chaining hash functions like $H_1(H_2(x))$. Both collisions in $H_1$ and ...

1

First, consider dropping bcrypt, because of its output limitations. If you are concerned about GPUs and ASICs, there's always scrypt. If you decide to go with bcrypt, you won't have 256-bit security with AES-256 and will need to pad the key somehow or disallow that combination. I would simply call the KDF with a constant 256-bit output, which matches the ...

1

If you have plenty entropy in your "seed" then just use a KBKDF such as HKDF. If you have somewhat less, use a PBKDF such as PBKDF2. Both HKDF and PBKDF2 can take a salt as input parameter and are already using a HMAC internally. There is no need to perform a HMAC beforehand. If you do, you would have to specify what data is used as key for the HMAC ...

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