SecureLogShipper

A secure log transport tool that encrypts security log data using hybrid AES+RSA encryption before sending it over the network — designed to protect sensitive SIEM/NIDS log data (like alerts from NetWatchman) while in transit.

Why This Matters

Security logs often contain sensitive information — internal IP addresses, usernames, attack patterns, and system details. If sent across a network in plain text, anyone intercepting that traffic (e.g., via packet sniffing) could read it directly. SecureLogShipper ensures that even if traffic is intercepted, the log content remains unreadable without the correct decryption keys.

How It Works

SecureLogShipper uses hybrid encryption — the same core approach used by TLS/HTTPS to secure web traffic:

1. Receiver generates an RSA key pair (public + private) on first run, and reuses the same pair on subsequent runs.
2. Sender reads log entries from a file and, for each entry:
   • Generates a fresh, random AES key
   • Encrypts the log message using that AES key (AES is fast and ideal for bulk data)
   • Encrypts the AES key itself using the Receiver's RSA public key (protects the key while it travels)
3. Sender transmits the encrypted log + encrypted AES key + IV to the Receiver over a TCP connection.
4. Receiver uses its RSA private key to decrypt the AES key, then uses that recovered AES key to decrypt the actual log message.
5. Decrypted logs are saved to received_logs.txt.

sequenceDiagram
    participant S as Sender
    participant R as Receiver

    Note over R: Generate/load RSA key pair<br/>(public + private)
    R->>S: Share RSA public key (public_key.pem)

    Note over S: Read log line from file
    Note over S: Generate random AES key + IV
    Note over S: Encrypt log content with AES key
    Note over S: Encrypt AES key with RSA public key

    S->>R: Send (encrypted AES key, IV, encrypted log)

    Note over R: Decrypt AES key using RSA private key
    Note over R: Decrypt log using recovered AES key
    Note over R: Save to received_logs.txt

Loading

Why Hybrid Encryption?

• AES alone is fast but requires securely sharing a key beforehand — a hard problem on its own.
• RSA alone is secure for small data but far too slow for encrypting large volumes of log data.
• Combining them: AES handles the actual log data efficiently, while RSA only has to protect the small AES key — giving both speed and strong security.
• A fresh AES key per log entry means that even if one key were ever compromised, it wouldn't expose any other messages (a property known as forward secrecy).

Tech Stack

• C# / .NET 10
• System.Security.Cryptography (AES + RSA)
• TCP sockets for network transport

Project Structure

SecureLogShipper/
├── Crypto/          # Shared encryption logic (AesHelper, RsaHelper)
├── Sender/          # Reads logs, encrypts, sends over network
├── Receiver/         # Listens, decrypts, saves logs

How to Run

1. Start the Receiver first (it generates its RSA key pair on first run, and listens for connections):

   cd Receiver
   dotnet run
   

2. In a separate terminal, run the Sender (it reads sample_logs.txt and sends each line, encrypted, to the Receiver):

   cd Sender
   dotnet run
   

3. Decrypted logs will appear in the Receiver's console output and be saved to Receiver/received_logs.txt.

Sample Output

Sender:

Connected to Receiver!
Sent encrypted log: [2026-07-05 08:12:03] ALERT: Telnet Connection Detected | Severity: HIGH | MITRE: T1040 | Src: 192.168.1.10:51322 | Dst: 192.168.1.20:23 | Direction: outbound
...
All logs sent!

Receiver:

Receiver listening on port 5000...
Sender connected!
Decrypted log: [2026-07-05 08:12:03] ALERT: Telnet Connection Detected | Severity: HIGH | MITRE: T1040 | Src: 192.168.1.10:51322 | Dst: 192.168.1.20:23 | Direction: outbound
...

Design Decisions

• Why RSA-2048? Currently the industry-standard minimum key size for RSA, balancing security and performance.
• Why generate a new AES key per log entry, rather than reusing one? Limits the impact of any single compromised key and mirrors how real-world protocols like TLS handle key negotiation per session.
• Why not just use a shared secret key? A pre-shared AES key alone would require securely distributing that key beforehand — the exact problem hybrid encryption avoids by using RSA for key exchange.

Future Improvements

• Real-time file watching (currently reads the log file once per run)
• TLS-wrapped connection instead of raw TCP, for additional transport-layer protection
• Key rotation and expiration for the RSA key pair
• Integration with real SIEM/NIDS tools like NetWatchman for live log ingestion
• Error handling for dropped connections and malformed data

Author

Tony Doumit — built as part of a self-directed cybersecurity portfolio project, extending prior work on SIEM (LogSentry) and NIDS (NetWatchman) tools.

License

MIT License — feel free to use this project for learning purposes.