New answers tagged

0

I found a pretty clear response in the v2.0.0 release notes of cryptsetup : For now, default LUKS2 PBKDF algorithm is Argon2i (data independent variant) with memory cost set to 128MB, time to 800ms and parallel thread according to available CPU cores but no more than 4. So I was wrong. The default PBKDF is PBKDF2 for LUKS1 (LUKS1 header format ...


1

The default version of LUKS simply does not support Argon2 because, unlike PBKDF2, it requires more parameters than the current header format is designed to store. The newer version, LUKS2, may not be default on your system, but it does support Argon2. This is just a matter of software support. See also https://gitlab.com/cryptsetup/cryptsetup/blob/master/...


2

An important requirement for reusing the key is that there should be a random IV (CBC) or nonce used for each plaintext to protect. Otherwise the security the cipher is breached as the result is deterministic. It can even be fatal if CTR mode - or one of the many AEAD schemes that use CTR mode - is used for encryption. Many implementations of PBKDF both ...


0

Briefly: Single PBKDF2 hash per user is sufficient. PBKDF2 is designed to be slow and thus resistant to brute force atacks. That's why it has no much benefits if you use many different PBKDF2 hashes for the same user. On the other hand, if you use different PBKDF2 hashes for decryption of many encrypted data pieces, you will have to compute PBKDF2 many ...


13

Assume you have an IND-CCA secure cryptosystem $E$ that runs a password through a slow KDF and implicitly handles salts and random IVs, a human-chosen password $p$, and messages $m_1$ through $m_n$ to encrypt. Is $E_p(m_1+m_2+\cdots+m_n)$ or $E_p(m_1)+E_p(m_2)+\cdots+E_p(m_n)$ better for this? Each invocation of $E$ is slow due to it running a KDF on $p$, ...


Top 50 recent answers are included