# Tag Info

8

You're right. Unless the software is doing something very peculiar, which should be very apparent when reading the code and documentation, and I can't imagine what it could be, the salt generation and the application of PBKDF2 are unnecessary. If you have 32 bytes from a cryptographically secure random generator, you can use these 32 bytes as an AES-256 key....

6

You need a key stretching function, not a mere key derivation function. A key stretching function is technically a kind of key derivation function, but most key derivation functions are not key stretching functions. A key stretching function is intrinsically slow to reduce the possibility of brute force guessing, and includes a salt input to make ...

5

No, there is no way (secure or otherwise) to compress a random $192$ byte value into something smaller; it is impossible to encode $2^{8 \times 192}$ bit possible settings in only 32 bytes (or $191$ bytes, for that matter...) Some exceptions: If those 192 bytes were nonrandom, that is, the vast majority of those 192 bit settings were impossible, you may be ...

5

You are correct: generally it is required to synchronize or otherwise synchronize information if you want to use a password based key derivation function (PBKDF) for sending messages. That doesn't mean that using a password on the client side a derived key on the server side doesn't have advantages: the password isn't stored on the server side, so an ...

4

First of all, generally, the shared secret is split in half because it consists of an X and Y coordinate. It is after all the point resulting in multiplying a public key point with a private key / vector, resulting in another point on the curve. Now the X and Y coordinate are related, so generally, only the X coordinate is used as a shared secret. Currently, ...

4

If you have a PSK then you don't need a password. You can just derive new session keys from the PSK, e.g. using a salt within HKDF. It is also possible to derive a key and IV if you're already using a salt. You could also use a counter starting at zero as nonce / IV instead because the resulting key is considered "fresh". Generally, you simply need a unique ...

3

KDFs are better used for offline protocols. What is often used for your second case are Key-agreement protocols. As far I know, there's no secure way of using KDFs in such interactive context where both parties need to know the key a priori. Key-agreement protocols make it feasible to compute a shared-secret (the encryption/decryption key) on demand - both ...

3

I understand the question to mean: is there a function $F$ whose domain is signatures under a public-key signature scheme such that, given a signature $s_1$ made with a key $k_1$ and a signature $s_2$ made with a key $k_2$, $F(s_1) = f(s_2)$ if and only if $k_1 = k_2$? Or in simple terms: can you tell who made a signature by looking at it? You aren't going ...

3

As written, it makes an additional security assumption on the symmetric cipher; that the attacker can't flip bits in the key (and modify the ciphertext) to gain some advantage. That is likely true for most ciphers we would use in practice, but is nevertheless an additional assumption. This is not difficult to fix; we don't select a random symmetric key $K_d$...

3

Yes, the salt in the HKDF can provide for key separation between the encrypt-then-mac applications. If that's needed depends on the system, maybe using an IV/nonce is enough, it depends on how many messages you want to encrypt and the used encryption and MAC scheme basically. Some other remarks: we derive keys - not passwords - for ciphers and MAC ...

3

I dont understand the use of the info parameter, what does "to fold in identity information" mean? It essentially is context information; that is, protection so that the ciphertext can't be reused in a different context. Here is a simple example; suppose I encrypt a message to you, and fgrieu intercepts it. Now, what fgrieu could do is forward ...

2

Looking at it closely, the linked RFC formally references SP800-56Ar2 section 5.8.1, which buries in 5.8.1.2.1: Note: When the single-step KDF specified in Section 5.8.1.1 is used with H = hash as the auxiliary function and this concatenation format for OtherInfo, the resulting key-derivation method is the Concatenation Key Derivation Function specified in ...

2

Am I right in thinking they should've piped the whole shared secret through the KDF to "compress" the 256 bits to 128 bits to retain 128-bit security? Using only 128 bits would not be the best practice, but does not open to attack as far as I know, for standard KDFs (which use all the entropy in their input). There's still effectively 128-bit ...

2

Would it be safe to use an architecture-level instruction like RDRAND or RDSEED (x86) or RNDR (ARM) to generate this key material, and then derive a key that way? Would you need to derive the same key twice (for example, you're using the key to encrypt data from Alice to Bob, so both Alice and Bob need to derive the key; or if you're using the encrypt ...

2

While it's technically not (probably) an issue, you should definitely avoid sharing keys between different purposes. RSA uses separate keys for signing and encryption, for example, since an encrypted-and-signed message would cancel out. RSA only signs a hash of the original message, negating this issue, but it still avoids sharing keys because it's simply ...

2

Covers Argon2id the known attacks? Although there is no research into this, I would say that Argon2id is probably not vulnerable to the attack shown by Alwen and Blocki. Maybe an attack on the first part (the Argon2i part) could be practically applicable, but the advantage for the attack quality would be ruined by the second part (the Argon2d part), because ...

2

As PBKDF2 is a key derivation function, its primary purpose is to turn a secret, low-entropy value into a higher entropy secret key. In your use-case, if the key is expected to be secret (I assume it is), then using only publicly known data associated with the user will result in a key that anyone with access to the PBKDF2 parameters can generate. That said, ...

2

Rather no. There is no standard construction going by the name Key Derivation Function aimed at generating public/private key pairs. Traditionally, especially for RSA, how to generate a key pair is left at the discretion of the implementation, rather than made per a specific deterministic process. The usual name is Key Generation. And it's usually stated as ...

2

AES is not irreversible, at least not when the key is known. I'd rather look at a PRF (Pseudo Random Function) rather than a PRP (Pseudo Random Permutation) such as AES. A good PRF is HMAC. HMAC also has the nice properties of having no limit to the input message and a rather large, although statically sized output. Even more specifically you might want to ...

2

It is generally assumed that cryptocurrency mining is an "offline" process, that is you take one input from outside, and then after a long while you report back with a result. In particular, it is assumed that an adversary does not see when exactly one search starts and when it ends nor do they see how many tries it took you exactly. This makes ...

2

Generally we look at strength by looking at the order $O$ that it adds to the password search when an attacker is trying to guess passwords. That's just the same as the number of iterations basically, assuming a salt and correct password hash. Often it is simpler to just use bits, which is basically the $\log_2$ of the order. So if a password strength is an ...

2

Or would it be better to use something like HKDF? Generally? Yes. Using HKDF is preferred, if only to communicate clearer what you're actually doing here. Is it acceptable to use PBKDF2 with just 1 iteration to do the simple key expansion that I need? Yes. To explain this, we first need to understand how PBKDF2 works. First, note that it compute $\ell$ ...

2

The problem is that this requires relatively low level access to the cryptographic algorithms. In general the private key can simply be set to a set of bits, although it should actually fit in the field. Setting the highest bit to zero is a dirty trick if the runtime(s) do not accept as many random bits as the key size. This will however let you use any kind ...

1

The remark of Conrado showed me that I could look at the XOR as a simple key wrapping operation, which is basically just another encryption. In that case it is clear that the scheme is secure for confidentiality; it just adds another layer of encryption. Of course, encryption by itself doesn't offer integrity / authenticity. ECIES cannot offer authenticity ...

1

Key material is the “mathematical” key, as opposed to metadata about the key such as the key type, its name in a database, its usage policy, etc. In the context of key management, and in particular of programming interfaces that manipulate cryptographic keys, the term key can mean multiple things. It can refer to the actual bytes or numbers that are used in ...

1

You probably don't want to encrypt data with a key derived from a password directly with a KDF. This makes changing the password require rencrypting everything. You can instead encrypt data with a strong random key. And encrypt the key with a password derived key. This encrypted key is what you keep. You can also encrypt this key with other keys. Including a ...

1

Is it really just a block cipher in ECB mode, so that each packet can be decoded without any prior packet⁰? No. ECB is bad and creating a secure real-time channel (that can even handle packet loss) is a solved problem. It has been for years. There's no good excuse for using ECB here. Is it a block cipher in some non-ECB mode, but it gets reset at the ...

1

The immediately obvious way to do this is to use RSA in a large-public-exponent format. That is, the server selects an RSA modulus, and a large public exponent (say, $e = 2^{2^{30}}+1$) [1]; if the RSA primes are safe primes, this practically eliminates the possibility that $e$ is not relative prime to either $p-1$ or $q-1$. The server would internally ...

1

Sending symmetric key is equivalent to sending password (used for PBKDF) - they are both secret information that require secret channel. Sending session symmetric key encrypted with asymmetric cryptosystem doesn't require secret channel - you use public key of recipient (for instance taking it from certificate signed by root certificate that you trust, say ...

1

Trying to use a PBKDF for transferring data over a network is not appropriate. The place to use a PBKDF is when you're protecting data at rest, e.g. some sort of archive file like a zip file or a backup. In works well in those contexts.

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