SecureS2S

Pure asymmetric encryption is computationally expensive for bulk data (RSA-2048 encrypts ~250 bytes per operation). Pure symmetric encryption cannot solve the key distribution problem — two peers with no prior shared secret cannot agree on a key without an out-of-band channel.

Implemented a hybrid protocol where RSA-2048 is used exclusively for a one-time session key exchange, and AES-256-GCM handles all subsequent message traffic. The public key and the encrypted session key are both sent through the framed transport layer rather than raw sendall/recv calls, so the handshake is immune to the same partial-read issues as the message stream.

The RSA key pair is ephemeral — generated fresh on each run. While the current implementation does not preserve the private key across restarts, the architecture cleanly separates the asymmetric key-exchange layer from the symmetric encryption layer, making it straightforward to swap in ECDHE in the future. A pure-RSA approach for all messages would waste CPU and cap message size at the key modulus.

Textbook RSA (raw encryption without padding) is deterministic and malleable — an attacker can encrypt guesses and compare ciphertexts, or manipulate ciphertexts to produce predictable plaintext changes.

Applied OAEP (Optimal Asymmetric Encryption Padding) with SHA-256 as both the hash and MGF1 hash function.

OAEP introduces randomness and redundancy so that the same plaintext encrypts to different ciphertexts each time, and decryption fails (with high probability) if the ciphertext was tampered with. The alternative considered was PKCS#1 v1.5 padding, which is simpler but has known padding-oracle attack surfaces (Bleichenbacher, Manger). OAEP eliminates these classes of attacks at the cost of ~10 extra bytes per encryption.

Encryption without integrity checking (e.g., AES-CBC + HMAC separately) complicates the implementation and can introduce subtle bugs like padding-oracle attacks or tag-verification timing leaks.

Used AES-GCM, an authenticated encryption (AEAD) mode that combines confidentiality and integrity in a single primitive. Each message generates a fresh 96-bit nonce via os.urandom(12) and appends it to the ciphertext.

NIST SP 800-38D recommends a 96-bit nonce for AES-GCM as the optimal trade-off between security and message-size limits. Using kernel-level entropy (os.urandom) instead of a counter means nonce reuse is probabilistically infeasible — you would need roughly 2^48 messages for a 50% collision probability. The alternative (AES-CBC + HMAC-SHA256 in encrypt-then-MAC order) would require careful coordination of two keys and two primitives. GCM eliminates this coordination risk by design.

TCP is a byte stream, not a message protocol — it makes no guarantee that one sendall() call on one end corresponds to one recv() call on the other. A single recv(4096) can return a partial message, a fully buffered message, or several concatenated messages depending on network timing, which silently corrupts AES-GCM decryption (wrong nonce boundary, truncated tag) or the RSA handshake itself.

Added a small framing layer to crypto.py: send_framed() prefixes every payload with a 4-byte big-endian length header via struct.pack, and recv_framed() reads that header first, then loops on recv_exact() until the declared number of bytes has actually arrived. Every socket write and read in both servers — the public key, the wrapped session key, and every encrypted chat message — now goes through this layer instead of calling socket.sendall()/recv() directly.

A fixed-size length header is the simplest framing scheme that fully solves the boundary problem without adding a parser or a delimiter that could collide with binary ciphertext. The alternative of using a delimiter byte (like newline) is unsafe here because the payloads are raw encrypted bytes that can legitimately contain any byte value, including the delimiter itself. recv_exact() is a short blocking loop that keeps calling recv() until the requested number of bytes is collected or the socket closes, which is the standard fix for TCP short reads.

TCP sockets are inherently symmetrical but Python's input() blocks the calling thread. If the send and receive loops share a single thread, the user cannot receive messages while typing, or cannot send while waiting for a message. On top of that, the receive loop may need to send an ACK before the outbound socket to the peer has finished connecting.

Split the communication into two daemon threads per server — one dedicated to receiving, one to sending. Two threading.Event flags coordinate them: key_established gates outgoing chat messages until the session key is derived, and send_ready gates any outbound write (including ACKs fired from the receive thread) until the outbound socket has actually finished connecting.

A single-threaded select/poll-based event loop would work but adds complexity (selectors module, non-blocking I/O, manual buffering) with no benefit for a two-peer interactive chat. Threading keeps each logical path (send, receive) as a simple blocking loop. Splitting the synchronization into two separate events, instead of one, was necessary because the receive thread needs to send ACKs independently of whether the user has started typing — a single "ready" flag conflated two different preconditions.

TCP guarantees delivery at the transport layer but gives no application-level signal that the remote peer has read and decrypted a message. A successful sendall() only means the kernel accepted the data — not that it was processed successfully. Firing that ACK also risks a deadlock if the outbound socket to the peer has not connected yet.

Built a lightweight application-level ACK protocol. When a peer receives a non-ACK message, it calls send_ack(), which first waits (with a 5-second timeout) on the send_ready event before encrypting and framing the literal __ACK__ under the session key. The sender displays "(Arrived)" when it decrypts an __ACK__. Any failure — a timed-out wait or a socket error — is caught and reported instead of crashing the receive loop.

The __ACK__ protocol verifies that the entire cryptographic pipeline — decrypt, decode, display — completed successfully. A corrupted ciphertext, a wrong key, or a deserialization error would all prevent the ACK from being sent, so the sender knows immediately that delivery failed. The __ACK__ messages themselves are encrypted and framed identically to normal messages, so a passive network observer cannot distinguish ACKs from data messages by pattern alone. The timeout on send_ready avoids the receive thread hanging forever if the outbound connection never comes up.

When two threads write to stdout simultaneously (one printing an incoming message, one refreshing the input() prompt), the output overlaps and garbles the display.

Implemented a safe_print() function that acquires a threading.Lock, clears the current input line with a carriage return and spaces, writes the message, then re-draws the prompt.

The print_lock serializes all terminal output so that message printing and prompt drawing never interleave. The carriage return + spaces technique overwrites any partial user input that was being typed — this is the standard solution for single-line terminal interfaces where you do not want a full curses dependency.