Hot answers tagged keys
20
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
...
14
The XOR is indeed meant as a protection against hypothetical short cycles. For a given password P, the sequence of Ui should make a "rho" structure: at some point in the sequence, a cycle is entered. For a n-bit hash function and random password, on average, there will be a single "big" cycle of size about 2n/2 and for almost all possible salt values, that ...
11
That's not quite correct. In SSL, two things happen:
First, a session key is negotiated using something like the Diffie-Hellman method. That generates a shared session key but never transmits the key between parties.
Second, that session key is used in a normal symmetric encryption for the duration of the connection.
SSL does use public/private in one ...
10
Well, to start off with, IVs have different security properties than keys. With keys (as you are well aware), you need to hide them from anyone in the middle; if someone did learn your keys, then he could read all your traffic.
IVs are not like this; instead, we don't mind if someone in the middle learns what the IV is; as long as he doesn't know the key, ...
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, ...
9
Splitting a key does not reduce the key strength at all. Simply generate two random 128-bit strings and give one to each party. Encrypt the data with the exclusive OR of the two random strings.
Each string alone gives no information whatsoever about the final key, assuming your random number generator is sound. No party has any advantage.
9
You can use a password based key, which is a similar approach to the PGP method, create a key somehow (random clicks, random numbers etc.), encrypt it with a password and store it somewhere. When the user wants to access the DB, he enters the password, which is the key for the DB decryption key file and then you get the clear password for the DB.
The main ...
9
Since the goal is to generate the salt for PBKDF2, there is no need for an efficient (as in fast) random generator: PBKDF2 is (purposely) compute-intensive. Further, in many uses of PBKDF2 (e.g. storing a password), the salt is generated once, stored, and reused many times, further lowering the concern over efficiency of the salt generation. As the saying ...
8
This is hidden well in RFC 4880, the OpenPGP message format specification.
Section 5.7 explains how message data is encrypted. (I'm using the values for a 16-byte block cipher like AES.)
A random block of data is created: $p_{1} \dots p_{16}$
The last two bytes of this block are repeated: $(p_{17}, p_{18}) := (p_{15}, p_{16})$.
These 18 bytes (in case ...
7
@D.W. is probably closest to the real reason (this was fifteen years ago, so things get a bit hazy), there was some concern about short cycles, and it was effectively free - you're already iterating the hashing deliberately to slow things down so speed isn't an issue - so why not do it? You've also got to remember the historic context, when replacements for ...
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 ...
6
To be honest, there's no good reason why the XOR is needed. My suspicion is that, most likely, the designers included it because they thought, "hey, why not? it can't hurt". But if the designers had left out the XOR, everything would have been just fine.
In particular, if PRF() is a secure pseudorandom function, and if we stick with typical parameters, ...
6
Short answer: just truncate, it's fine.
Long answer: you want a Key Derivation Function. A KDF turns an arbitrary-sized input (the shared secret obtained from SRP) into a configurable sequence of bytes, which you can split into as many sub-sequences as you need for symmetric cryptography. For instance, SSL/TLS defines a KDF (it calls it "PRF"; see section ...
6
If you're generating the salt for PBKDF2, well, you really don't care about efficiency (because the evaluation of PKBKD2 is itself quite expensive by design).
In addition, password salts do not have very high security requirements. We really don't care if someone is able to distinguish a valid salt value from a random value. All we really care about is ...
6
The last major effort I know of for cracking keys was the Distributed.net effort.
You can find the project page at http://www.distributed.net/RC5/en. In 2002, they cracked a 64-bit RC5 key using at total of 331,252 computers over 1,757 days. Their maximum throughput was "equivalent to 32,504 800MHz Apple PowerBook G4 laptops or 45,998 2GHz AMD Athlon XP ...
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 ...
5
For Diffie-Hellman, adequate security is achieved provided that:
we work modulo a prime $p$ big enough to resist discrete logarithm (1536 bits are sufficient);
the order of the subgroup generated by $g$ is a multiple of a big-enough prime integer $q$ ($q$ should have length $2n$ bits to achieve $2^n$ security);
the private exponents are randomly chosen in ...
5
Yes, you are correct; the keywrap algorithm assumes that you have one long term secure key, which you can use to protect other keys. The writers of RFC 3394 assume that you do have a secure key-encrypting-key (KEK).
This doesn't appear to be a valid assumption in your case. In your case, you need to do cryptographical operations even though someone can ...
5
The attack is described in the article Related-key Cryptanalysis of the Full AES-192 and AES-256. The attack applies in the following situation:
There is a key owner; the key is $K_A$ and the attackers tries to guess it.
The key owner can somehow be persuaded to compute three other keys $K_B$, $K_C$ and $K_D$, from $K_A$, using a specific derivation ...
5
What you are proposing in effect means that you use a not-really-random one-time-pad, which is used twice (i.e. a two-times-pad). This is not secure.
Using a single hash to generate a key from a password is a bad idea - especially if the password is short, it is easy to brute-force it (i.e. try lots of passwords).
Using the simple XOR cipher to encrypt a ...
5
If the keys have constant, known length, I'd concatenate them, and then apply SHA256. If they have variable length, applying some separation mechanism might be useful.
Truncating hash functions works well. If the original hash function is good, a truncated hash function has the same properties, albeit at a correspondingly lower security level. Truncating ...
5
Lets take your idea to the extreme to see its weakness. For simplicity I'll scale things down. Let's assume an 8 bit key chosen randomly. Call this key $k$. If I break into your database and get $d=H(k,s)$ along with $s$ (where $H$ is a hash function and $s$ is the salt), it would take on average $2^{8-1}=2^7=128$ computations (or calls to $H$) to find $k$.
...
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
...
4
Leaving aside the question of whether or not this is a useful feature, my theory is the designer of PBKDF2 were familiar with the design changes made from MD5 to SHA-1 and felt that it might be beneficial to introduce a parallel data channel like the SHA-1 key expansion array (also constructed with XOR). With negligible overhead, the XOR doubles the ...
4
The usual method of "splitting a key" $K$ into two keys $K_0$ and $K_1$ given to two parties, for the purpose described, is as follows:
generate $K_1$ randomly, of the same size as $K$;
set $K_0 = K \oplus K_1$.
"Joining" $K_0$ and $K_1$ into $K$ is simply $K = K_0 \oplus K_1$.
This construct is such that each of the two parties gain absolutely no ...
4
I agree with you. The XOR seems utterly pointless. A short cycle in the hash chain seems no more likely nor more unlikely than a short cycle in the hash/XOR chain. If one can degenerate into a sequence where additional iterations don't change the value, so can the other. If one can't, neither can the other.
4
It is very similar to how we authenticate ourselves to a website. During registration, the website must store enough information to, at some time in the future, convince itself that the person trying to authenticate now is the same person who registered at some time in the past. For online services, this typically involves storing some function of the ...
4
You can use TLS 1.0 as guidance: it is the direct successor of SSL 3.0, so many things are quite similar, and in some respects TLS 1.0 is a bit clearer. In section 6.3 you will find the key generation process, with the exact sentence:
To generate the key material, compute [...]
until enough output has been generated. Then the key_block is
...
Only top voted, non community-wiki answers of a minimum length are eligible
