Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve key exchange by having the server maintain a pool of RSA keys #13

Open
nuvious opened this issue Jul 15, 2024 · 0 comments
Open

Comments

@nuvious
Copy link
Owner

nuvious commented Jul 15, 2024

Current implementation has the server generate an RSA key after initial receipt of a connection from a new client. This offsets the client and server key exchange by 8 bytes requiring the server to initially set its host id to a random 8 byte value and the client having to send an extra random 8 byte value. There is also a latency cost in the server generating an RSA key during the initial connection which could be detected.

Instead, have the server maintain a pool of RSA keys. When a new client connects it should pull from the pool of keys and use the N modulus to set the initial host-id for the connection. After enough 8 byte segments of the N modulus are transmitted both the client and server send a keep-alive command to confirm receipt and establishment of the covert channel connection. For non-covert channel connections the server will not receive the expected keep alive message and can mark the client as a non-covert channel client and issue random connection ids for subsequent connections.

Using a pool of keys would allow an 8 byte reduction in the total key exchange transactions and the pool of RSA keys can be maintained via a separate key generation thread that keeps a queue filled to a specified number of keys desired. This would also eliminate any latency incurred by generating the key upon connection.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant