# Tag Info

6

Yes a brute force key-guessing attack would be faster, but: It would be ridiculously slow for either. E.g. see this for 256-bit keys. There are faster attacks on both and those attacks break larger RSA sizes than ECC sizes. Related: Why can ECC key sizes be smaller than RSA keys for similar security?

5

In two key 3DES two keys are equal so that key size is only 112 bits, compared to the 168 bits of full 3DES. The advantage is a smaller key size without a correspondingly large loss in security: both two and three key 3DES can be attacked in about $2^{112}$ time. With the encrypt-decrypt-encrypt construction it clearly must be the first and last key that ...

2

If we want to make three successive DES encryptions or decryption using 2 secret keys K1, K2 at least one time, and possibly a public constant C0 used as key, we are bound to chose among the following six possibilities (listed by alphabetical order, ignoring configurations equivalent by exchange of K1 and K2); all except number 5 are vulnerable to a basic ...

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. ...

1

To remain immunized from cryptanalysis One-Time-Pad must be encoded with a perfectly random key, which is not easy to do. Any pattern in the key will make its corresponding plausible plaintext into unlikely to be a randomized result. For example, if you encrypt your message P with a key K=0101010101010..., to get a ciphertext C, then, a cryptanalyst will ...

1

Or in other words, is keeping initialized cipher in memory basically equal to keeping key in memory? In the case of AES, yes, every time you encrypt (or decrypt) another block of data you need the key (or equivalent information, like the round keys), so the cipher instance must have it somewhere. Other ciphers (like Keccak's AE mode) may allow ...

1

Most applications store their private keys for TLS in a cleartext file protected with filesystem permissions. On UNIX-ish systems this location is typically in /etc/ssl/private/mykey.key readable only by root. Windows-based systems store private keys in a special secured portion of the system registry database, which only the SYSTEM account (equivalent to ...

1

If $f_k$ is AES the block cipher, then there are $2^{128}$ possible output values for a given plaintext and $2^{|k|}$ possible AES keys, where $|k|$ is either 128, 192 or 256, depending on which AES key size you use. Assuming AES chooses a random permutation, $g_{PT}(k) = f_k(PT)$ behaves like a pseudorandom function*, so you expect something like $2^{127}$ ...

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 ...

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