My web site host has just now terminated servers for sftp and SSH due to a denial of service attack. I presume that the problem is that the server must perform a multi precision modular exponential computation to discover that the new client is bogus. This costs many CPU cycles.
I now realize (subsequent to writing the stuff after the first rule below) that I need to collect the reasons why people want session keys. On page 494 of Handbook of Applied Cryptography they say:
See: Photuris, Guidelines for Cryptographic Key Management, Guidelines for Mandating Automated Key Management,
At one extreme the shared keys are never changed. This has been seen as a bad idea since before computers were involved. At the other extreme symmetric keys are changed every few minutes even within a session. Issues of forward secrecy are not orthogonal here. It would seem we must throw issues of forward secrecy, perhaps plausible deniability, DoS attacks into the choice of key management tradeoff.
Long term secrets seem required. One vague argument is that
Other ideas: This provides some rationale for session keys. Another reason I have heard is that the session key is in constant use and is thus vulnerable to explicit theft thru violation of whatever physical and logical steps are in place to protect it. This can be anything from timing attacks dependent on cache timing, to breaking down a door while an electro mechanical system is in use.
The task is to choose a shared session secret to serve in message authentication and/or symmetric encryption. This scheme is much cheaper than public key solutions which invite denial of service attacks based on forcing the server to do expensive computations before rejecting a new session. We assume here that the server knows each client. I propose length parameters on the small end.
For each registered client, the server holds a c bit secret C which is also known to the client. c is about 64. Upon contacting the server, the client sends its alleged identity and the server responds with a 32 bit number N not used before with that client. N need not be concealed. The client computes a crypto hash of N and C and returns a k bit portion K of the hash. k is about 32. The server computes the same hash and compares it with the returned value. The nascent session is ended with a diagnostic to the client if the hashes do not match. If the transmitted hash portion matches the other hash portion serves as the shared session secret.
If one of the client’s C’s is compromised, it is as if the client had been turned and the Denial-of-Service dilemma is solved by deleting the server’s record of that client’s C upon any excess resource demand by that client.
(The client might speculate on the value of N and usually avoid a round trip.)
In the active attack he may change the value of N as seen by the client. I cannot see what this buys the attacker.
The attacker can also change the hash portion returned by the client but that will merely terminate the session at the server end. Changing both seems pointless.
The portion of the hash used for the symmetric encryption and message authentication must be enough conventional purposes.
The k bits of the hash transmitted in the clear for authentication must be enough to make a bluffing (guessing) attack pointless. An online attack that merely guesses values for K is not much different from protocol agnostic attacks, which this proposal does not address. Only a client table lookup and hash computation is imposed on the target of the attack.
I do not address forward secrecy or plausible denial, as such requirements are not uniform over applications.
Here is a cheap protocol to put ahead of the public key or key-agreement computation. It is for situations where the legitimate client authenticates itself.
A server has a number of semi-secrets, perhaps as many as legitimate clients. Each semi-secret is a 32 bit number S and a small guessable integer index I. A client must know one of the semi-secrets of the server. The first packet sent by the client to the server includes I of that semi-secret. The first packet from the server includes a 32 bit number N that it has not before used for this semi-secret. The client computes a secure hash of S and N and returns it to the server. The server computes then, or may have computed ahead of time, the same hash. If they agree the servers that it is talking to someone who indeed knows the semisecret.
When the hash does not match the server sends a message to the client so indicating. It also probably logs the event. It does not proceed with the key agreement protocol.
If the hash matches and the authentication fails then a black mark is made against the semisecret. After a few black marks the server cancels the semisecret.
Semi secrets are distributed thru the same channels that the authentication is distributed.
I must now determine why the hash does not serve as a symmetric crypto key. This idea is too simple not to have been thought of before. Perhaps it serves for authenticated clients. Diffie-Hellman works for non-authenticated clients.