# Tag Info

## Hot answers tagged keys

37

A key, in the context of symmetric cryptography, is something you keep secret. Anyone who knows your key (or can guess it) can decrypt any data you've encrypted with it (or forge any authentication codes you've calculated with it, etc.). (There's also "asymmetric" or public key cryptography, where the key effectively has two parts: the private key, which ...

32

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

23

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

22

Collisions of RSA keys should never happen for realistic key sizes and good random number generators. Assume a 1024 bit RSA key; the primes from which it has been derived are about 512 bit. If we assume every 500ths 512 bit number is a prime, and we assume the most significant bit of the 512 bit number is set, we still get about $2^{500}$ or $10^{150}$ ...

18

The XOR is indeed meant as a protection against hypothetical short cycles. For a given password $P$, the sequence of $U_i$ 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 $2^{n/2}$ and for almost all possible salt ...

17

Examining his claims about "Thundercloud": You can use it with "any existing software, operating system, or device" (a massive amount of effort---by whom?) Has its "own cryptographic language that is completely independent of any existing security technology" (this is a negative thing: abandoning the entire knowledge base of cryptography is incredibly ...

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

14

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

12

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

12

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

12

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

12

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.

12

An encryption algorithm does not need a keyspace. By definition, however, it has one. It sound to me like your confusion is mainly terminological. In cryptography, the "keyspace" of an encryption system is defined simply as the set of all possible (distinct) keys that the algorithm can accept. For example, let's say that we're back in the days of the ...

11

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

11

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

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

11

This depends on the public-key system (algorithm). For RSA, technically the private and public key (i.e. the exponents, the keys share the same modulus) are symmetric, you can swap them, and it still works. But you usually don't want to do this: The public exponent is usually a small number (like $3$ or $2^{16} + 1$) in order to speed up encryption/...

11

Do all ciphers suffer from the problem of multiple equivalent decryption keys? No. The number of non-equivalent keys is bounded by the number of permutations. Since the number of permutations is very high there is a very big chance that ciphers do not have equivalent keys. This is especially true for ciphers with a high block size (AES with 128 bits). Even ...

10

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

10

XORing a master key (presumably a long term key) with data is a very dangerous idea. If any data key is leaked, then the master key may be easily calculated, thus leaking all keys. ($m$ for the master key, $d_x$ for all data keys) $$c_x = d_x \oplus m$$ then somehow $d_4$ is leaked $$m = d_4 \oplus c_4$$ $$d_x = c_x \oplus m$$ You'd be better off applying a ...

10

There is no such thing as a 16 bit AES key. AES is a block cipher with a block size of 128 bits and a key size of 128, 192 or 256 bits. As a block cipher, AES can only encrypt 16 bytes (128) bits at a time. AES in itsef is not (CPA) secure as repetition of the plaintext would lead to repetitions of the ciphertext. To encrypt larger amounts of data, AES ...

9

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

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

9

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

8

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

8

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

8

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

8

The three terms (key, IV, nonce) you mentioned, and another, the salt, basically describe random numbers and each term is used in another context. The key is used as input for a cryptographic primitive and should be kept secret. A nonce is a random number only used once and for a short time with the intention to get replaced by or converted into something ...

8

AES by definition takes 16, 24 or 32 bytes as key, and nothing else. If you have a different size input use some kind of KDF to transform it to the correct length. If that input is a password this step is even more important. You should a key strengthening construction, such as PBKDF2 with sufficient iterations and a salt. If you use authenticated ...

8

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

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