# Tag Info

6

From looking at the source or 7zip that seems to be the case. The format has a place for a salt, as SEJPM's link shows. It is mixed into the homebrewn iterated SHA-256 hash before the key. The 7zip decoder even seems to support salts. However, the encoder never uses a salt. Oddly there is even code for generating a random 4-byte salt, but it is commented ...

2

Collisions are not much of a concern, since you have to compute them to know they happen, and assuming your values are a typical hash size (256+ bits) they will never happen randomly anyway. But yes, having identical computation that use the same data is wasteful if you don't store the intermediate values. However, the main problem your function has is that ...

2

Yes and yes, as mentioned in the comments. It is worth noting that Bitcoin wallets use a scheme similar to this in BIP32, a method of creating n various EC keypairs from a single seed deterministically: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki

2

Yes, this is exactly what KDFs and PRFs are designed for. That is, no reasonably efficient attacker will be able to tell if you used an actual random key or something generated from the KDF/PRF. This is of course assuming that your initial seed/master secret was of sufficient entropy, and the way you derive the various values are not done in a silly way. ...

2

Coming up with a specific number is hard. Realistically, all three options take you well out of the realm of ever having more than the absolute worst passwords brute-forced by an attacker. The primary gain of scrypt and argon2 over bcrypt is a hit to parallelism due to the addition of memory requirements. GPUs with thousands cores will need (but don't have) ...

2

Your key derivation function is not particularly memory hard. The second loop walks the array in order, so an optimized implementation which an attacker would use can avoid the whole array, keeping only some elements in memory at a time. For example, you can halve the memory use by only storing the second half of M initially. Then for the first N/2 ...

1

Do NOT generate your own key derivation function. Use one of the known and trusted ones... industry standard ones, such as PBKDF2 https://en.wikipedia.org/wiki/PBKDF2 Use your starting (pseudo-random) value, and plug it into PBKDF2 for different numbers of iterations for each desired output (new seed) that you need.

1

Unless a fast AES is available on the combination of CPU and PHP instance being used (that is, something built with AES-NI), I strongly advise against using AES as the basis of entropy stretching. Number-1 rule in designing an entropy-stretching function is that it should put to the best possible use the computational resources available to the legitimate ...

1

I don't know the protocol, so I'm not sure. It is a standard way of converting group elements (e.g. the shared value $g^{ab}$ you get after Diffie-Hellman) to keys. You don't need to worry about the specifics of the group when choosing a hash function, just use a cryptographic hash like SHA256. It's hard to know what the difference between those two is ...

1

Yes, your best choice is indeed to use a key derivation function. However you should consider using the TLS-PSK set of cipher suites for your needs. If you use the variant with DHE / ECDHE key exchange (recommended) included you don't have to rely on your passphrase being strong for security, both the password and the discrete logarithm have to be disclosed ...

1

I assume the recommended approach is to use a KDF function like HKDF, but what is the security implication of taking an SHA-256 hash and using it directly for AES-256 or truncating it for AES-128 (Alice and Bob are using Java which doesn't have a native implementation of HKDF and I don't think it is a good idea to try and write your own). HKDF(-Expand) ...

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