On 06/05/2011 08:38, Le_Forgeron wrote:

> Private key and public key are the mirror of each other.
> If you crypt with the public key, only the private key can get it back
> in clear.
> If you crypt with the private key, only the public key ... and so on.

This is true of algorithms like RSA. However, there are algorithms where 
the encryption and decryption keys are actually in different formats, 
and it is only possible to encrypt with the designated encryption key.

> The RWTF is that the private key should not be generated by the company
> but by the identified people (you). And they should get your public key,
> verify your identity-matching-that-key using a separate *secure*
> channel, and then sign your public key with a trust level and their own
> dedicated key-pair for that purpose.

In this instance, we're only trying to establish a secure channel. If 
they got an imposter's key, we won't be able to log in, and the problem 
will quickly be rectified. (And the area the attacker temporarily gets 
access to is empty until we put data into it, so there's no disclosure 
to worry about.)

> The usual private-public key's algorithms allow only to compute the
> public key from the private key, at best.
> If the private key was computable from the public key alone, it wouldn't
> be private any more.

You understand that in principle, it is *always* possible to compute the 
private key from the public one, right? It is impossible to prevent 
this. All you can do is make it ludicrously expensive to do it.

> For instance DES is weak enough, yet 3DES in some modes (such as Crypt
> with key 1, uncrypt with key 2, crypt again with key 3) is assumed
> strong enough as long as key2 is not key1 or key3 (moreover, DES use an
> internal vector, and some mode propagate/share that vector with the 3
> stages, whereas other modes have their own vector for each stage).

AES exists for a reason. Triple DES is subject to meet-in-the-middle 
attacks, and its keyspace is only 168 bits anyway. The keyspace of AES 
is potentially much bigger, and in general it is considered far more 
secure than any modification of DES.

> And last but not least, usually the asymetric keys (public-private) are
> only used to crypt a "random" symetric key (like XOR) generated for the
> session (or less), because asymetric cyphering is expensive in CPU
> whereas symetric is usually far less.
> Which also means that if part of the data exchange can be guessed (such
> as a standardised header), the eaves-dropper could try to find the
> symetric key in use by comparing the crypted data with the clear one.
> (hence the random appeareance of "no-data" packets in the ssh streams:
> just to make their lifes more difficult)

Any symmetric block cipher worth toffee *must* be able to resist an 
attacker with access to both the plaintext and the matching ciphertext 
being able to deduce the key, or anything about the key. This is a very 
basic property of symmetric block ciphers. Any cipher lacking this 
property is trivially insecure. This has nothing to do with public key 
cryptography.

Post a reply to this message