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

Split the communication into two daemon threads per server — one dedicated to receiving, one to sending. The key establishment is coordinated with a threading.Event so that messages are not sent before the session key is available.

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, making the code readable and correct by construction.

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.

Built a lightweight application-level ACK protocol. When a peer receives a non-ACK message, it replies with the literal __ACK__ encrypted under the session key. The sender displays "(Arrived)" when it decrypts an __ACK__.

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, so a passive network observer cannot distinguish ACKs from data messages by pattern alone.

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.