# Tag Info

21

The public key blob doesn't consist of just the numbers that make up the public key: it begins with a header that says “this is an SSH public key”. The repeated prefix encodes this header. RFC 4254 specifies the encoding of public key in SSH key format. The "ssh-rsa" key format has the following specific encoding: string "ssh-rsa" mpint e ...

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

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

10

It's not a security problem but a necessary feature. It's not an exact science to distinguish a "good decryption" from a "bad decryption". What if the user had encrypted random data? you would not be able to figure out if the key is correct or not from that sole information, since in both cases the decrypted output would look completely random! Similarly, ...

7

Sure, use AES with a fixed key. Since the key is fixed, it could be considered keyless in the traditional sense. Someone with only access to the ciphertext could not crack it as long as you use a good mode (say GCM, CCM, or EAX) using proper nonces, IVs, or whatever else is required. This is security by obscurity as the plaintext is only as secure as the ...

7

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

6

First off, many block modes of operation require a message to be padded so that its length is evenly divisible by the block size of the cipher. CBC mode (Cipher Block Chaining), for instance, typically pads a message either with an entire block of zeroes if it happens to be exactly divisible by the block size, or with a given number of bytes that will extend ...

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\}\}$.

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

If your alphabet (set of all possible characters) has size $s$ and your password has length $l$, a randomly generated password has a strength of $\log_2s^l = l\cdot\log_2s = l\cdot\frac{\log_{10}s}{\log_{10}2}$ bits. This means if you want to create a 128-bit password using a 80-character alphabet, you need at least ...

5

By using padding, one can tell if the decryption is correct. Padding is used when the message length is not a multiple of the block size. You append predictable data at the end of the message (one "1" followed by several "0" for example) and then you encrypt it. If you find the correct "1000..." sequence at the end of decrypted message, it means it's ok. ...

5

No, your formula isn't correct. I don't know how you came to it, so I don't know what's wrong with your intuition. You can check whether your formula makes sense with dimensional observation — it's the same kind of reasoning that helps a lot in physics. Write all numbers with their units: entropy rate = 1.5 bit/character random key size = 128 bits ...

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

4

If all the components share the same certificate, then they share the same private key. This raises the two following points: When a secret is shared by more than two people, can it still be considered really secret ? Secrecy dilutes fairly fast. If all components share the same secret value, then breakage of any single component reveals the private keys ...

4

The write up on Wikipedia is pretty good. I won't go into all the detail that they do there, but your private key is a randomly selected integer $d_A$ selected from $[1,n-1]$ where $n$ is the order of the group. The public key is $Q_A=d_AG$ where $G$ is the base point on the curve defined in the publicly agreed upon parameters.

4

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

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

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

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

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

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

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

3

I mean for O notations, we usually state only the degree of the highest order polynomial (that expresses algorithmic complexity), ignoring the factors and lower order powers. Consider an imaginary runtime of $5x^{2.5} + 2x - 3$. As $x$ gets large this is almost entirely dominated by $x^{2.5}$. However, $x^2$ is significantly smaller than $x^{2.5}$, ...

3

Only wanted to point out an example regarding the alghorithm Triple-Des, which, in my opinion, quite summarizes your problem: Tdes uses three 56-bit keys, which, theoretically, gives to it a strength of one 168bit key (see wikipedia http://en.wikipedia.org/wiki/Triple_DES): the alghorithm basically uses the old DES alghorithm three times: first encrypt your ...

3

The point of a KDF is to take a low-entropy input and significantly increase the amount of computational power (and thus time or cost) it requires to brute-force, hopefully to a level on-par with a truly random value. If you're already using a 256-bit value generated from a CSPRNG, there is no need to use a KDF. In fact, using a KDF can only reduce the ...

3

Take the following points into consideration: A 32 character password composed of 95 ASCII characters only has $\log95^{32}\approx 210$ bits. As long as there are no quantum computers (which would reduce the key strength to 105 bits), that's not a practical problem. Not taking the previous point into account, if your password really gets generated ...

3

At a purely technical level, having the two group elements and secret exponents enables a proof, in the random oracle model, that the scheme is CCA secure assuming that decision Diffie-Hellman is hard. For regular (hashed) ElGamal, we only know how to prove CCA security in the random oracle model under a stronger assumption (in our paper we called it strong ...

3

If you have a high entropy input, then scrypt isn't a good choice. It's purpose is to compensate for the low entropy of a password. Don't ask the user for memory/cpu factors, you don't need them if the input is high entropy. You don't need a salt either. Simply use an input of at least 16 bytes from a secure random number generator. I recommend using one ...

3

There are two forms of entropy here at work. First there is "uncertainty" entropy from the user password which is typically very low (on the order of 20 to 40 bits for most passwords out there). And then, there's "computational" entropy, which is artificially obtained by forcing an attacker to do work to calculate keys. Essentially, if you run your KDF for ...

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