Find the answer to your Linux question:
Page 2 of 2 FirstFirst 1 2
Results 11 to 18 of 18
Originally Posted by mahela007 So.. the authentication and sharing of the symmetric key is done over an asymmetrically encrypted connection. But the actuall data of the session is encrypted symmetrically? ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #11
    mzv
    mzv is offline
    Just Joined!
    Join Date
    Aug 2009
    Location
    Evil Empire
    Posts
    33

    Quote Originally Posted by mahela007 View Post
    So.. the authentication and sharing of the symmetric key is done over an asymmetrically encrypted connection. But the actuall data of the session is encrypted symmetrically?
    no And it's not symmetric key, it's public key and you use asymmetric encryption.

  2. #12
    Trusted Penguin Irithori's Avatar
    Join Date
    May 2009
    Location
    Munich
    Posts
    3,422
    Sorry mzv, but actually yes.

    Mahela007 got it right.
    Asymmetric encryption is used:
    - to exchange the generated session key (which is symmetric). The public/private pair of the server are used here.
    - to authenticate the user. This is, where the userīs public/private key comes into the game.

    Symmetric encryption is used:
    - for the connection encryption.

    So basically:
    - asymmetric encryption for the initialization of the connection
    - and symmetric encryption for the "heavy lifting", aka data transfer (shell, filetransfers, etc)
    You must always face the curtain with a bow.

  3. #13
    mzv
    mzv is offline
    Just Joined!
    Join Date
    Aug 2009
    Location
    Evil Empire
    Posts
    33
    Quote Originally Posted by Irithori View Post
    Sorry mzv, but actually yes.

    Mahela007 got it right.
    Asymmetric encryption is used:
    - to exchange the generated session key (which is symmetric). The public/private pair of the server are used here.
    - to authenticate the user. This is, where the userīs public/private key comes into the game.

    Symmetric encryption is used:
    - for the connection encryption.

    So basically:
    - asymmetric encryption for the initialization of the connection
    - and symmetric encryption for the "heavy lifting", aka data transfer (shell, filetransfers, etc)
    haha,thank you. but, let's imagine you're right, please, explain me, how the symmetric encryption works here? I thought it should use one key for encryption and decryption. And I thought encryption here is needed for making secure connection only, right?

  4. $spacer_open
    $spacer_close
  5. #14
    Trusted Penguin Irithori's Avatar
    Join Date
    May 2009
    Location
    Munich
    Posts
    3,422
    Ok, explanation follows

    Symmetric encryption uses *one* key on both client and server.
    Letīs have a look at the picture here again:
    The Architecture of an SSH System (SSH, The Secure Shell: The Definitive Guide)
    That one key is the Session Key in the picture.

    What is symmetric encryption?
    - You need the same key to encrypt and decrypt

    What are the advantages of symmetric encryption?
    - relatively easy in design
    - therefore the CPU usage is low (compared to asymmetric encryption)
    So it is desireable to use that for ssh.

    But you need to ensure:
    - that the Session Key is good. That is: long and random enough
    - that the Session Key is exchanged in a *secure* way.

    You cannot send it plaintext.
    Anyone with a networksniffer would be able to decrypt your connection -> The encryption effort is just a waste of time and effort.

    This is there the asymmetric encryption helps.

    What is asymmetric encryption?
    - You have a key pair. Public and Private key
    - What is encrypted with one, can be decrypted with the other
    - This is why a public key can be transmitted plaintext.

    So, the client gets the Public Host Key (White key with H in the picture).

    Ah, I am sorry. Contrary to what I have written earlier, the Session Key is generated on the Client -not on the Server-, using random data.
    This Session Key is encrypted, using the Public Host Key, that the client now has.
    The encrypted Session Key is then sent to the server.
    The server decrypts the Session Key, using its Private Host Key. (Black key with H)

    Now both client and server have the same Session Key and thanks to asymmetrical encryption, it is ensured, that the transmission was safe.

    The mentioned requirements for using symmetrical encryption have been met.
    So a symmetrical connection can be established.

    Ok, that chapter is over. We do have a secure connection
    Now the authentication process can begin.

    It uses another set of key pair: The Black&White with U
    Letīs assume the Public User Key is already known to the server. ie: It is in the authorized_keys2 file
    Then the server will use that Public User Key to encrypt some random data
    and send it to the client.
    The client is supposed to answer with the decrypted data.
    It can only do that, if it has the right Private User Key.
    BTW: Thatīs why it is so important to keep the private keys safe.
    If the client answers correct, then the Userīs authentication has been proven.

    The user finally gets a shell

    Uff, lots of typing for a sunday morning.
    But at least I have 250 posts now.
    I am a linux user now
    (What was I the last 13 years then? )
    You must always face the curtain with a bow.

  6. #15
    mzv
    mzv is offline
    Just Joined!
    Join Date
    Aug 2009
    Location
    Evil Empire
    Posts
    33
    Quote Originally Posted by Irithori View Post
    Ok, explanation follows

    Symmetric encryption uses *one* key on both client and server.
    Letīs have a look at the picture here again:
    The Architecture of an SSH System (SSH, The Secure Shell: The Definitive Guide)
    That one key is the Session Key in the picture.

    What is symmetric encryption?
    - You need the same key to encrypt and decrypt

    What are the advantages of symmetric encryption?
    - relatively easy in design
    - therefore the CPU usage is low (compared to asymmetric encryption)
    So it is desireable to use that for ssh.

    But you need to ensure:
    - that the Session Key is good. That is: long and random enough
    - that the Session Key is exchanged in a *secure* way.

    You cannot send it plaintext.
    Anyone with a networksniffer would be able to decrypt your connection -> The encryption effort is just a waste of time and effort.

    This is there the asymmetric encryption helps.

    What is asymmetric encryption?
    - You have a key pair. Public and Private key
    - What is encrypted with one, can be decrypted with the other
    - This is why a public key can be transmitted plaintext.

    So, the client gets the Public Host Key (White key with H in the picture).

    Ah, I am sorry. Contrary to what I have written earlier, the Session Key is generated on the Client -not on the Server-, using random data.
    This Session Key is encrypted, using the Public Host Key, that the client now has.
    The encrypted Session Key is then sent to the server.
    The server decrypts the Session Key, using its Private Host Key. (Black key with H)

    Now both client and server have the same Session Key and thanks to asymmetrical encryption, it is ensured, that the transmission was safe.

    The mentioned requirements for using symmetrical encryption have been met.
    So a symmetrical connection can be established.

    Ok, that chapter is over. We do have a secure connection
    Now the authentication process can begin.

    It uses another set of key pair: The Black&White with U
    Letīs assume the Public User Key is already known to the server. ie: It is in the authorized_keys2 file
    Then the server will use that Public User Key to encrypt some random data
    and send it to the client.
    The client is supposed to answer with the decrypted data.
    It can only do that, if it has the right Private User Key.
    BTW: Thatīs why it is so important to keep the private keys safe.
    If the client answers correct, then the Userīs authentication has been proven.

    The user finally gets a shell

    Uff, lots of typing for a sunday morning.
    But at least I have 250 posts now.
    I am a linux user now
    (What was I the last 13 years then? )
    thank you for such a long respond, but I still didn't see where you use here the same code for encryption and decryption. OK then, I'll find out it myself.
    And congratulations on becoming a linux user

  7. #16
    Just Joined!
    Join Date
    Apr 2008
    Posts
    36
    Check this out mzv: Very usefull.
    Inside SSH-1 (SSH, The Secure Shell: The Definitive Guide)
    Errmm.. I just have one more little question. Could you please check if the following is correct?
    "When the client computer sends the session key for the first time over to the server, it [the session key] is encrypted with the public key of the host. Now, this transfer is secure because although the public key of the server is available to anyone, information encrypted using the public key is can only be decrypted with the private key of the server [which is secret]

  8. #17
    Trusted Penguin Irithori's Avatar
    Join Date
    May 2009
    Location
    Munich
    Posts
    3,422
    The article is about ssh-1, and ssh-2 is strongly encouraged.

    But the principle of the quoted sentence applies and is correct.

    *ONLY* with a corresponding private key can one decrypt data, that has been encrypted with its public key counterpart.

    And vice versa.
    You must always face the curtain with a bow.

  9. #18
    Just Joined!
    Join Date
    Apr 2008
    Posts
    36
    Thanks a lot for your help. I'm using Ubuntu 9.10 and just installed ssh from their repository. So, I beleive I'm using ssh-2. Thanks again. .

Page 2 of 2 FirstFirst 1 2

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •