Tag Info

29

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

28

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

22

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

20

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

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

16

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8

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

8

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

It looks like, given your adversary model, things should be secure. HMAC as a randomness extractor has been shown to be good, especially when we can assume the hash function is collision resistant. That paper also has some results which tell how you could guard against the collision resistance being broken (basically use a hash function with larger output ...

8

Definitions In RSA, an encryption key is a pair of integers $(N,e)$ with $N$ the product of $m\ge2$ distinct odds secret primes $r_i$ (with $0<i\le m$), and $e$ is such that $\gcd(e,\lambda(N))=1$ where $\lambda(N)=\operatorname{lcm}(r_1-1,\dots,r_m-1)$ is the Charmichael function. It follows that $e$ is odd. Typically, other conditions are added, like ...

8

...wouldn't key still get repeated every few hours or so - i.e. you come to the end of the PRG(K)... This is where you are mistaken. Modern cryptographic PRGs simply do no repeat within any conceivable time frame. That is, starting from a seed, a well-constructed PRG (and this is true even when they are not so well constructed, like RC4) will simply ...

7

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

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

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