ssh rsa vs ssl rsa

[pcm81]

Normally we have public key that is a product of 2 primes and private key that are primes-1. And the security is dependent on difficulty of factoring the public key. In case of ssh the public key sits on the ssh server while private key is on client. This begs the question: "if the public and private keys were exchanged securely, does the ssh tunnel security still dependent on the length of the key the same way as it does in usual public key cripto like ssl?" In case of ssh the "public key" isn't really public so how would attacker know the large pseudoprime that needs to be factored?

 

[John Connor]

No idea. I have a built in SSH server in my router and when I used Putty gen to make the private key I made it 4096 bits long. So perhaps it does play a factor.

 

[Mark R]

The point is that the user has to get the public key to the server. The key could be captured during the transfer process. As it is a public key, it is not strictly necessary to exchange it or store it securely.

Because the private key never leaves the user's computer, it is less likely to be captured. In addition, good practice would require the private key to be stored in an encrypted form.

 

[Gryz]

I'm not a specialist in cryptography, but I think I can make a few comments.

Normally we have public key that is a product of 2 primes and private key that are primes-1. And the security is dependent on difficulty of factoring the public key. In case of ssh the public key sits on the ssh server while private key is on client.

I don't think that last sentence is true.

First you need to realize that RSA (the algorithm behind public key encryption) can be used for 2 things:
1) authentication. you prove to the other side that you are who you claim you are.
2) encryption. once the server believes that you are who you say you are, the rest of the conversation will be encrypted, so that no eaves-dropper can listen in.

I assume ssh uses both in its protocol.

You should also realize that not only you authenticate yourself to the server, the server also has to authenticate itself to you ! Usually this works very simple. When you log in for the first time, the ssh-client asks you if you really believe you are talking to the computer you are supposed to. If you answer yes, the ssh-client on your machine will accept the public-key of the server. And that public-key is from then on used when the server authenticates itself to you, when you log in in the future.

Also, I don't think private keys are exchanged. Public key encryption works with challenge/response.
https://en.wikipedia.org/wiki/Challenge–response_authentication

Some systems work like this: they use a public key encryption system to authenticate each other. Then they use the public key encryption to exchange a temporary password (=random long bitstring). This is caled the session key. Then from that point on, all the user data that is exchange is encrypted using a private-key-system (like AES) with that temporary session-key.
This is done because public-key systems (like RSA) are usually very cpu-intense. While private-key systems (like AES or DES) are much lighter on the CPU.

This begs the question: "if the public and private keys were exchanged securely, does the ssh tunnel security still dependent on the length of the key the same way as it does in usual public key cripto like ssl?" In case of ssh the "public key" isn't really public so how would attacker know the large pseudoprime that needs to be factored?

In RSA, public keys are really public. I think every time another ssh-client connects to a ssh-server, the ssh-server will give the client the public key. There really is no secrecy of the public key. That's why it is called public.

Maybe your question is: does the length of the temporary session-key have an impact on the security of the encrypted data that is exchanged, after the initialization of the session with RSA ?
I think it does. An eaves-dropper that sees only the encrypted data will have to do brute-force decryption with different keys, to try and guess the key and decrypt the data. The length of the session-key is a factor there.

Of course the strength of the session-key and the AES-encryption depends on the initial setup with the public-key system. If that initialization can be broken, then the attack will have the session-key. And he can then decrypt all user traffic.

Hope this helps.

 

[pcm81]

When I run vnc overssh tunnel the update rate shows down usin 4096 bit key vs using 1024 bit rsa key, hence I wonder if ssh really uses aes or if it actually uses rsa for the actual data. The use of rsa for authentication or for public key encryption are just different implementations of rsa. The public key is the product of p*q while private key are p and q bc (p-1)*(q-1) have a strict relationship to e^(p*q*t) where t is plain text. Hence using p and q one can recover plain text from cipher text generated by public key p*q. As u can see public key encryption is a particular implementation of rsa, but there is no requirement to make public key public. This makes me wonder if ssh implementation of rsa is more secure than it is in ssl where public keyrereally is public.

 

[matricks]

First you need to realize that RSA (the algorithm behind public key encryption) can be used for 2 things:
1) authentication. you prove to the other side that you are who you claim you are.
2) encryption. once the server believes that you are who you say you are, the rest of the conversation will be encrypted, so that no eaves-dropper can listen in.

About the bold: authentication (which the bolded part is) is not required for encryption. Authentication and encryption are completely independent concepts, and while they are often used together, neither depends on the other. PGP is a system where authentication (signing), encryption, authentication before encryption and encryption before authentication all are possible use cases (although some, particularly the latter one, are unlikely to be the best option). Each results in a different outcome in terms of how the message/data is secured, and what can be deduced about the security of the message.

Some systems work like this: they use a public key encryption system to authenticate each other. Then they use the public key encryption to exchange a temporary password (=random long bitstring). This is caled the session key. Then from that point on, all the user data that is exchange is encrypted using a private-key-system (like AES) with that temporary session-key.
This is done because public-key systems (like RSA) are usually very cpu-intense. While private-key systems (like AES or DES) are much lighter on the CPU.

This is correct, but poorly worded. AES is not a "private key system", it's a symmetric encryption algorithm. Symmetric algorithms (and modes/systems/any other encryption context) implies that both sides in an exchange uses and knows the same key/secret. A symmetric key must be agreed upon through other means of trusted communication, because otherwise the key would be sent in plaintext, readable by anyone. Asymmetric algorithms/modes/systems imply that each side uses a different key, and in this case each side has one public and one private key (which is why I find it important to point out this error in your explanation). Asymmetric encryption can be initiated over untrusted connections, because secret information is never communicated to the other party.

Also, keep in mind there are multiple keypairs involved in an SSH session. The server/host keypair, and the user/client keypair (reading your explanation, it seems you mix them up). The host keypair is used by the server to authenticate itself to the user connecting to it - the first time you connect to a server, the client will show you the hash/fingerprint of the host public key, and ask you whether to trust it. The host public key must be communicated over some other means of trusted communication (unless the user doesn't care). The user keypair is used to authenticate the user, and the server needs to know the public key of this keypair (usually saved in $HOME/.ssh/authorized_keys or similar).

When I run vnc overssh tunnel the update rate shows down usin 4096 bit key vs using 1024 bit rsa key, hence I wonder if ssh really uses aes or if it actually uses rsa for the actual data.

SSH does not use RSA for encryption at all. It is only used for authenticating the server and the user. Some variant of Diffie-Hellman is used initially to agree on a symmetric key (e.g. an AES key), and this key is used for data encryption.

See Understanding the SSH Encryption and Connection Process for a more detailed explanation.

Hiding the public user key does not make SSH more secure. The user keypair is not used for encryption, meaning that the security of the keypair does not affect the risk of eavesdropping. Hiding the public key only contributes to obscurity, in that an attacker does not know how long a key he needs to factor (an attacker who has the ciphertext of an SSH initialization may be able to deduce RSA key length from ciphertext alone - a 4096-bit key will produce a larger signature than a 2048-bit key).

 

[John Connor]

Looking at the encryption used in a SFTP session, I see that the encryption is AES and the connection is SSH. And the key fingerprint is RSA.

 

[Gryz]

About the bold: authentication (which the bolded part is) is not required for encryption. Authentication and encryption are completely independent concepts, and while they are often used together, neither depends on the other.

Of course. And I think I said something like that in my post.
As I wrote, I am not an expert on cryptography. I think I understand the concepts. But I'm not 100% on details, terminology, and which applicaition does what.
The OP seemed to not realize a lot of the details, and nobody else answered his question. So I thought I'd write down some tidbits that could clear his mind a bit.

This is correct, but poorly worded. AES is not a "private key system", it's a symmetric encryption algorithm.

OK. I think that when I looked at RSA the first time (which was over 2 decades ago), symmetrical-key systems were called private-key systems. I just did some googling and indeed that term seems to have been replaced by symmetrical-key encryption. Good to know.

Asymmetric algorithms/modes/systems imply that each side uses a different key, and in this case each side has one public and one private key (which is why I find it important to point out this error in your explanation).

I'm sorry to have caused confusion. This is what I wanted to say anyway.

SSH does not use RSA for encryption at all. It is only used for authenticating the server and the user. Some variant of Diffie-Hellman is used initially to agree on a symmetric key (e.g. an AES key), and this key is used for data encryption.

That is what I tried to say in my post.
I don't know which algorithms are used precisely. I just tried to point the OP to the right concepts. (It seemed he thought public-key encryption was: "you multiply 2 primes, you give away the product to the world as public key, and you're done".

Thanks for the comments.

BTW, if pcm81 really wants to know the details of SSH, the best source of information is always to look at the RFCs themselves. (RFC = Request For Comment, the documents that define the standards for the protocols used in the Internet. They are free and easily accesible).
https://tools.ietf.org/html/rfc4251
RFC 4251 explains the architecture of the whole protocol.
And then there are a handful more protocols that explain things like the transport layer protocol, the user authentication protocol, the connection protocol, etc.
https://tools.ietf.org/html/rfc4251#section-10.1