# Tag Info

15

Layering encryption doesn't effectively concatenate the keys (despite what intuition may suggest). The attacker can still attack the two passwords separately, such as by using a meet-in-the-middle attack. This means the effective key space (that is, the number of possibilities for the combined password that the attacker must try) is much lower for the ...

12

Curve25519 was designed to take advantage of the Montgomery ladder, which combined with Montgomery curves forgoes the $Y$ coordinates, is side-channel resistant, and enables public keys to be any 255-bit string. The ladder looks something like this (pseudocode): Q[0] = P; Q[1] = 2*P; for(int i = log2(exponent) - 2; i >= 0; --i) { Q[ bit(exponent, i)] ...

11

Using encryption in a non-standard way very often results in decreased security, and not in the information-theoretical sense. Consider: you will have two different passwords. You have twice the difficulty in managing them. Twice the chances of losing them. Twice the chances someone will screw up trying to follow your complicated directions. I also assume ...

7

How long are parameters used for? Usually $g$ and $p$ are kept static for a very long time indeed. In fact, the values to use are actually written in to standards. See here for an example. Those were values standardised ten years ago. So the answer is basically decades. The impossibility of brute force Let's suppose that I as an attacker decide I'm going ...

7

The problem is a very old one going back at least as far as the late 1940's early 1950's and has been shown to exist with Quantum Key Exchange as well. You need to think of it in terms of entropy down to heat pollution where a coherent signal energy steps down due to inefficiency via various transducers to what is basically thermal noise where the noise ...

6

Those findings were based on a broken PRNG. A broken PRNG affects all keys generated on such a device, no matter the size or the algorithm. Common primes were how the problem was detected, but the problem itself is unrelated to primes or RSA. If RSA keys of a specific size where affected, that's only incidental because that's what the broken devices ...

6

Did you take a look at DjB's paper? One of his design criterias in order to improve performance is "Use a fixed position for the leading 1 in the secret key". The set of secret keys is defined to be $\{\underline{n} : n \in 2^{254} + 8\{0, 1, 2, 3,\ldots, 2^{251}-1\}\}$.

6

Efficiently - no. However, the best attack on DES - linear cryptanalysis - works with known plaintexts, and theoretically may work slightly faster than the brute force even for small amounts of data. Computing linear relations between plaintext $P$ and ciphertext $C$, an attacker is able to enumerate all keys according to their likelihood. The PhD thesis by ...

5

The same key is indeed used in EAX to key both the CTR mode and the underlying OMAC (which is actually used in 3 distinct phases: randomising the CTR nonce, authenticating the Additional Authenticated Data, and authenticating the Ciphertext). This is explicitly acknowledged in the security proof. Where EAX differs from a naive reuse of the key is that it ...

5

I assume you follow Kerckhoff's principle so the attacker knows the padding scheme and derivation function so the answer is yes, it only takes a few seconds to decrypt and anyone can do it. If he doesn't know these things, he can find them by trial and error (assuming he can get his hands on a valid ciphertext). The IV can be sent in the clear so making ...

5

I'm not really sure what your geo-location and time stamp key is really giving you above one well selected 128-bit key. Let's say you're resolving the GPS co-ordinates to an accuracy of one metre. There are approximately $5 \times 10^{14}$ unique square metres of the Earth. We can probably safely exclude $2 \over 3$'rds of those metres on the basis that ...

5

One way to address this question is to notice that if there was such a vulnerability in reusing $g$ and $P$ multiple times, then that vulnerability can be used to attack a specific exchange, even if they use $g$ and $P$ only that one time. That is, changing $g$ and $P$ cannot help matters. Here is how this observation works; suppose we have a black box ...

5

With proper hashing the entopy of $Z$ is roughly the sum of both individual entropies, capped to the strength of the hash-function. For SHA-256 the limit is 256 bits, for SHA-512 it's 512 bits. Since entropy above 256 bits is meaningless, this isn't a practical limitation. For XOR computing the entropy of $Z$ is tricky and depends on how your keys are ...

5

Start by reading the paper. They have an entire section on defences: it is Section 11, Mitigation, pp.46-48. As far as software countermeasures for RSA specifically, they mention blinding as a good defence. Blinding is a standard defence against many kinds of side-channel attacks, and it is apparently effective against acoustic cryptanalysis as well. ...

5

Quite apart from the correction that Reid made (it takes $2^{127}$ attempts to achieve a probability of 50% of finding the right key; with $2^{64}$ attempts, the probability of success is $2^{-64}$), with AES, there is no known way to take advantage of known (or even chosen) plaintext to speed up any brute force search; even with $2^{64}$ chosen ...

4

With RSA, there is no known way to deduce the private key based on chosen ciphertext; that is, even if the attacker has oracle access to the private operation, the key is still safe. However, this doesn't mean that it's safe to give an attacker this access; he can't deduce the key, but he can use this access to decrypt anything he wants (and this is the ...

4

Is there a better way to do this? Yes there is, using tools specifically designed for this problem - namely key derivation functions (KDF). Good ones include PBKDF2 and bcrypt. A more modern, better alternative is scrypt, but it's relatively new and could use some more analysis before deemed safe. All above mentioned algorithms take a password and a ...

4

For all standard modes, AES isn't secure at all if you reveal the key; even if you keep the IV hidden. Exactly how this works out varies between modes; for CBC mode, the attacker will be able to decrypt the entire text except for the first block (well, last block because of your reversing the file), even if you didn't give him an IV. The same goes for CFB ...

4

It has to do with the alignment between the size of cipher the key and the size of a round key. Since a 256-bit key is twice the size of a round key, the nonlinearity of the key schedule would be aligned to every other block, and that is bad. Here is an example of the round keys generated by the key schedule for a key (hex bytes) of value ...

4

Your idea is not bad, but not a magic bullet. Any serious vulnerability at the root CSPRNG as you describe is fatal for the system facing any serious attacker. A serious vulnerability being that the attacker can at will force values or predict (partially) values generated in a particular timeframe. A serious attacker is an attacker knowing your protocols ...

4

The interesting property for the one time pad is that every plausible plaintext (given the length constraint, i.e. of same length as the ciphertext, maybe including some padding) has a corresponding key which produces a certain ciphertext. As mentioned in the comment by CodesInChaos, this key can be retrieved by simply XORing both plaintext and ciphertext ...

4

You elaborated that your goal is to make it possible to decrypt a message successfully "only when the device is in a specific location". Great goal, but yeah, well, the particular scheme you describe in your question ain't gonna work. Someone who is not physically at the specific location, but who knows where the specific location is, can still infer the ...

4

If your key material is properly random and at least as long as that which is to be encrypted, and indeed each key is used only once, then one-time pad is indeed applicable. As was noted: Distribution of keys will be a hard problem. OTP makes practical sense only in scenarios where keys can be distributed at some time T, then used for encrypting and ...

4

Short Answer: NO, it is not safe, do NOT do this. Longer Answer: You are true that you can use your RSA keypair for both operations. This approach is used in many applications and scenarios. There are Web Services or Single Sign-On implementations, which enforce you to use the same key pair for both operations. X.509 certificates do not allow you (by ...

4

If you use public key crypto in the correct way, then every user has it's own private key and corresponding public key (included in the certificate) and the keys of users are not related. Consequently, compromising the private key of one user does not affect any of the other users. So in the case of compromise of the private key of one user the remaining ...

4

To answer this question, we must have a look at how TLS/SSL works. I guess you know that the aim of TLS/SSL is to authenticate communicating parties before setting up an encrypted connection through which application data will flow. And as you may already know, an SSL handshake/session will use asymmetric crypto for authentication and session setup and ...

4

"If PGP and GPG both follow the OpenPGP standard, are they 100% compatible in all use cases?" No, they are not 100% compatible in all use cases, because — depending on the PGP version — there are known interoperability problems. The GNUPG FAQ answers this question quite well: Is GnuPG compatible with PGP? In general, yes. GnuPG and newer PGP ...

4

The idea you describe is vulnerable to a meet-in-the-middle attack that work in approximately $2^{128}$ time and $2^{128}$ memory. The attack assumes knowledge of plaintext/ciphertext pair(s). Given a pair, you encrypt the plaintext with every possible key 1 and store those values. You then decrypt the ciphertext with every possible key 2 and look for a ...

4

Yes, absolutely. Here is the standard construction to address this problem. Let $pk_1,\dots,pk_n$ be the public keys of the $n$ recipients. We pick a random symmetric key $k$, encrypt the message $m$ (using authenticated encryption) under key $k$ to get $c=AE_k(m)$, and then encrypt $k$ under each of the public keys. Finally, we form the whole ciphertext ...

4

The short answer is NO. Generally, it is not true that for RSA with no padding, the length of data must be equal to the key length. When and if that applies, that's a restriction of a particular cryptographic library, and either that's not the only restriction about the data, or the library does not allow reliable decryption of what's encrypted. RSA ...

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