New answers tagged

1

In general, you never want to use CRC/weak checksum for any computations on secret material (like keys). CRC is a linear function and by showing CRC of a key, you reveal a lot of equations that hold among the key bits. This is equivalent to showing the same number of bits of the key as the length of the checksum. The proper way of doing it has been ...


0

It's strange, but I was just thinking about this some time ago. It seems to me that you could first calculate the old master key (using the old password - you'll need that). Then calculate the new master key using your new scheme and XOR it with the old key. The result you should store with the salt. Now you have a method of calculating the old key: you just ...


1

If you want to allow sharing of files between users without sharing their master key and/or pass phrase, you need to allow for something like this extra layer of "indirection" complexity. However, per-file keys must be crated from HKDF(master_key, file_nonce) or a similar one-way key derivation function. Using simple XOR in this case would expose the master ...


3

First of all, the usual way to do this is to generate a new random AES key and then wrap it with the public key. Generally you don't encrypt with the private key at all. Yes, SHA-256 is a one way hash so you can do this. The problem is that you would still need to encrypt with a public key to let the other party know the AES key (unless you use the key to ...


0

Is it safe to recreate the key pair using the password+salt every time I need to use it so I don't have to store the keys (encrypted or not) anywhere in the system? The problem with that is that your public key then effectively becomes a password hash, meaning anyone who sees it will be able to mount a dictionary attack on your password to generate the ...


3

Would these steps result in a suitable pair of keys for AES-encrypt-then-HMAC-authenticate? Yes. That would be fine. It almost is HKDF-Expand, in fact. However, as you note, by deriving the two 256-bit keys from a 160-bit key your effective security will "only" be 160 bits, since an attacker could brute force the intermediate key. That is not at all a ...


0

The security - assuming you can validate the correctness of $K$ - is 56 bits (not even counting any attacks on DES itself, assuming to test all keys). This is because you can brute force $K_{BT}$ without even looking at $K_{AT}$ in your particular scheme. 2 key triple DES on the other hand would at least offer over 80 bit security. So this scheme is ...


0

For that purpose, are there some security implications having that salt as a fixed byte string? The key re-use is fine here, because the standard model for MACs allows the attacker to request an arbitrary (polynomially bounded) amount of authenticated messages while still not being able to forge new MACs. As a bonus, you may want to consider using ...


2

Actually, the strength of the derived key is likely to be limited by the strength of the password; for example, if the user selects the password "password", well, that's likely be to within the first couple that an attacker checks. However, if we assume that the password is stronger than what most people select, then the next limiting factor is $n$. The ...



Top 50 recent answers are included