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 to...@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.