Le 05/05/2011 20:34, Warp a écrit :
> Alain <aze### [at] qwertyorg> wrote:
>> Le 2011/05/05 12:37, Warp a écrit :
>>> Invisible<voi### [at] devnull>  wrote:
>>>> A company that requires you to send files to them electronically using
>>>> SFTP, requires that it uses public key authentication, and emails you
>>>> the private key that you're supposed to use, unencrypted.
>>>
>>>    I thought the private key can only be used to decrypt, not to encrypt.
>>> (Unless the public key can be created from the private key, which might be
>>> the case.)
>>>
> 
>> Normaly, you should first create your private decryption key.
>> Then, from that key, you generate the public encryption key. That key 
>> can be transmited unencrypted.
> 
>   That's not what I was asking.
> 

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.

Using the public key to encrypt allows to restrict the number of people
able to read the clear: only the private key can decrypt. It's a kind of
"For these people only".

Using the private key to encrypt is stranger, it would be "From this
people only".


Usually, the private key is used to crypt a checksum of the message
(signing), so that the users of the public key can verify that the
holder of the private key did in fact that operation.

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.

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.

Now, there is also weakness in algorithms, and rainbow book for the some
low length of keys.

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

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)


-- 
Software is like dirt - it costs time and money to change it and move it
around.

Just because you can't see it, it doesn't weigh anything,
and you can't drill a hole in it and stick a rivet into it doesn't mean
it's free.

Post a reply to this message