You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: