3 more surprising (to me) things about ssh (was: Re: SSH resources, specifically on certificates (certificate authentication))

[rhkramer@gmail.com]

Thanks for the response, and to dsr as well.  I won't really ask a question 
here, but I will make some comments -- not sure how / where to fit them in -- 
will try to intersperse below.  Or maybe I'll just top post them here:

Surprise 2:

Another surprising thing to me (with the evolution of the surprise) -- my 
initial objective (until I came across certificates) was to learn about public 
key(pair) authentication with the intent to allow passwordless ssh between 
computers on my LAN.  It was in the course of digging into that that I learned 
about things like the Diffie-Hellman key exchange and the use of a symmetric 
encryption algorithm for the exchange of bulk / payload data.

Then I got to thinking that if ssh uses a symmetric algorithm for exchange of 
bulk data in (well, after) public key authentication, it probably does the 
same (that is, use symmetric encryption (with a shared secret encryption key)) 
after any other method of authentication, and that it probably also uses Diffie-
Hellman key exchange (maybe with different inputs) in those other methods of 
authentication.

(I'm assuming this is also the case for gssapi (one variation being Kerberos) 
authentication, in which I have absolutely no interest, at least at present.)

Your post makes me much more confident that is the case.

Surprise 3:

Maybe it should not have been a surprise, but ssh turns out to be much more 
complex and flexible than I expected -- I've been trying to think of the best 
word to describe it and have been thinking of it as sort of a meta-protocol 
instead of just a protocol.  I say that for a number of reasons (some that 
don't really justify the use of the prefix meta, but....)

   * Variations of ssh, either within one implementation (e.g., openssh) or 
between implementations of ssh (by other vendors) can use a wide variety of 
actual encryption protocols (e.g., AES-128, AES-192, AES-256, RSA, ecDSA, 
ed25???. and a variety of others.  And, next week, when somebody implements a 
new variation of ssh, they might use other protocols / algorithms.  (Of 
course, some backward compatibility and handshaking is required so different 
implementations can talk to each other (to the extent possible) (one example 
is the openssh versions 1.0, 2.00, and 1.99, which I won't explain atm).

   * I mentioned it already in the previous bullet, but the other point I was 
going to make is that other vendors / implementors can implement variations of 
ssh which can use different encryption protocols (but again, need means of 
backward compatitbility / handshaking or such for inter-operability between 
implementations).

Surprise 4: 

Even Diffie-Hellman is (or can be) more complex than I recall it being described 
in the Wikipedia article (but I may have forgotten some of what I read there).

For example, in the variation used in public key(pair) authentication, in 
addition to the expected user and server public keypairs, there are things 
like a salt, and multiple iterations of some algorithm / process, and even a(n 
optional?) second set of public keypairs (ephemeral public keypairs, used once 
and thrown away, iiuc).  This (the additional ephemeral keypairs) might be 
only in the variation of Diffie-Hellman known as triple Diffie-Hellman (3-DH).)

(In at least one source I found, 3-DH is the thing that mentioned as providing 
forward security, but I think the bigger point is, as dsr pointed out, the 
generation of new session keys for each new "session" (which, afaict, can be 
done with things like a new salt (which I think is a random number) or a 
different number of iterations of some process (and that number of iterations 
might also be a random number), i.e., 3-DH is not necessarily required for 
forward security).

And to elaborate a little (without me knowing the details) even in ssh 
(simple) password authentication, some variation of Diffie-Hellman (or Diffie-
Hellman using different inputs -- maybe using the "host" public keypairs for 
both the client and server machines instead of using the server public keypair 
and a user public keypair (as in public key authenttication) with the user 
password thrown into the mix somewhere.

I don't care too much about the actual details, it is enough for me (for now) 
to know (or at least think I know) that even the process for (simple) password 
authentication is fairly complex, secure(, and, (incidently) almost certainly 
uses some variation of Diffie-Hellman).

(Oh, I could also mention that sometimes variations of Diffie-Hellman are 
referred to as being of different groups, some being more secure than others.  
I won't get into that at all -- I mean, I don't think I need to know any 
details.  Oh, and sometimes, iiuc, that is referred to as Diffie-Hellman Group 
Exchange instead of Diffie-Hellman Key Exchange, which seems like at least a 
little bit of a misnomer to me.)

Comments / clarifications / corrections welcome.

Maybe my next post will pose the big question I have (about the number of 
public keypairs needed in public key authentication vs. certificate authority 
authentication...)

Nothing new below this line, in fact, I've deleted most of it.

On Friday, July 15, 2022 01:33:15 AM tomas@tuxteam.de wrote:
> This is standard for public key cryptography, be it "interactive style"

-- 
rhk

If you reply: snip, snip, and snip again; leave attributions; avoid top 
posting; and keep it "on list".  (Oxford comma included at no charge.)  If you 
change topics, change the Subject: line. 

A picture is worth a thousand words -- divide by 10 for each minute of video 
(or audio) or create a transcript and edit it to 10% of the original.