ClawSec is a modern encrypted network tool that provides AES-256-GCM encryption for secure data transfer. It evolved from Cryptcat with completely rewritten cryptography using current best practices.
- No SSH keys or certificates needed
- Single static binary (37KB)
- Works on embedded systems
- Quick temporary file transfers
- Simpler for one-off connections
ClawSec uses industry-standard cryptography (AES-256-GCM, PBKDF2) but has not been independently audited. Use for:
- Development/testing environments
- Internal network transfers
- Non-critical data transfer
For production systems, consider professionally audited solutions like SSH/OpenSSH.
git clone https://github.com/LF3551/ClawSec.git
cd ClawSec
./install.sh- OpenSSL 3.x
- C/C++ compiler (GCC or Clang)
- POSIX-compatible system (Linux, BSD, macOS)
Not currently. ClawSec requires a POSIX system. Consider using WSL (Windows Subsystem for Linux).
# Server
./clawsec -l -p 4444 -k "ChatPass" -c
# Client
./clawsec -k "ChatPass" -c server-ip 4444Both sides will see timestamped messages with colored output.
# Server (target machine)
./clawsec -l -p 8888 -k "ShellPass" -e /bin/bash
# Client (your machine)
./clawsec -k "ShellPass" server-ip 8888Interactive programs (vim, nano, top) work with PTY support.
# Receiver
./clawsec -v -l -p 9999 -k "Password" > file.txt
# Sender
./clawsec -v -k "Password" receiver-ip 9999 < file.txtUse -v flag to see transfer statistics.
Yes. Both endpoints must use the exact same password for encryption/decryption.
You'll see: [AESGCM] Decrypt error: Authentication failed
The GCM authentication tag prevents decryption with wrong passwords.
No. The -k option is required for security. There is no default password.
# Linux with systemd
sudo cp clawsec.service /etc/systemd/system/
sudo systemctl enable clawsec
sudo systemctl start clawsecClawSec uses:
- AES-256-GCM (NIST approved)
- X25519 ECDHE (Perfect Forward Secrecy)
- PBKDF2 with 100k iterations
- Cryptographically secure random IVs
- GCM authentication tags
- Replay protection (sequence counters)
- TLS 1.3 camouflage (
--obfs tls) - Packet padding and timing jitter (
--pad,--jitter)
It lacks:
- PKI/certificate infrastructure (uses password-based auth)
- Independent security audit
Minimum 12 characters with mix of:
- Uppercase letters
- Lowercase letters
- Numbers
- Symbols
Without the password, intercepted data is encrypted and authenticated. An attacker would see random bytes and cannot decrypt or modify the data.
No. ClawSec operates at the TCP/UDP level, not HTTP. It creates its own encrypted channel. However, --obfs tls wraps traffic in a real TLS 1.3 session, making it look like HTTPS to network observers.
Add the -k option with a password:
./clawsec -l -p 8888 -k "YourPassword"Passwords don't match between client and server. Verify both use identical passwords.
Use -e flag for reverse shell mode which provides PTY support:
./clawsec -l -p 8888 -k "Pass" -e /bin/bashMake sure both sides use -c flag:
# Server
./clawsec -l -p 4444 -k "Pass" -c
# Client
./clawsec -k "Pass" -c server-ip 4444Combine --obfs tls for TLS 1.3 camouflage with --fingerprint chrome to look like real browser traffic:
# Server
./clawsec -l -p 443 -k "Pass" --obfs tls
# Client (looks like Chrome to DPI)
./clawsec -k "Pass" --fingerprint chrome server 443DPI systems identify tools by their TLS ClientHello pattern (JA3/JA4 hash). OpenSSL's default ClientHello stands out as a non-browser client. --fingerprint chrome|firefox|safari shapes ClawSec's ClientHello to match a real browser — cipher suites, curves, ALPN, extensions.
No. --fingerprint is client-side only — it shapes the outgoing ClientHello. The server doesn't need it.
REALITY-like active probing resistance. When a browser/DPI probe connects to your port, they see a real website. Only ClawSec clients that send the correct knock sequence get the encrypted tunnel:
# Server: DPI probes see real nginx
./clawsec -l -p 443 -k "Pass" --fallback 127.0.0.1:80
# Client: sends knock, gets tunnel
./clawsec -k "Pass" --fallback 127.0.0.1:80 server 443
# DPI probe: sees real nginx
curl https://server:443 # → nginx welcome pageEncrypted Client Hello — adds a GREASE ECH extension to the TLS ClientHello, hiding the SNI (server name) from DPI. Automatically enables TLS mode.
Multiplexes up to 64 connections over a single encrypted tunnel. Think of it as encrypted port forwarding with connection pooling:
# Server: forward to internal web server
./clawsec -l -p 4430 -k "Pass" -L internal:80 --mux
# Client: 64 concurrent connections on localhost:8080
./clawsec -k "Pass" -p 8080 --mux server 4430Yes. Maximum stealth configuration:
# Server
./clawsec -l -p 443 -k "Pass" --fallback 127.0.0.1:80 --ech --pad --jitter 100 --tofu --pq
# Client (looks exactly like Chrome connecting to a real site, with MITM detection + quantum resistance)
./clawsec -k "Pass" --fingerprint chrome --fallback 127.0.0.1:80 --ech --pad --jitter 100 --tofu --pq server 443Trust On First Use — like SSH's known_hosts. The server generates a persistent Ed25519 identity key. On first connection, the client saves the server's fingerprint. On reconnection, it verifies the fingerprint hasn't changed. If it has — you get a big warning (possible MITM).
Yes. The server signs its ephemeral key, the client verifies. Both must use --tofu.
Post-quantum hybrid key exchange. Adds ML-KEM-768 (CRYSTALS-Kyber) on top of X25519 ECDHE. Both classical and quantum-resistant shared secrets are combined, so the session key is secure against both classical and quantum adversaries ("Harvest Now, Decrypt Later" protection). Requires OpenSSL >= 3.5.
Yes. Both sides must use --pq for the ML-KEM key encapsulation exchange to work. You can combine --pq with --tofu for identity verification + quantum resistance.
--obfs tlswraps traffic in a real TLS 1.3 session (required for all stealth features)--fingerprintadditionally shapes the TLS ClientHello to look like a specific browser--obfs tlsis needed on both sides,--fingerprintis client-only--fingerprintauto-enables--obfs tls
- Check server is running
- Verify correct port number
- Check firewall settings
- Ensure correct IP address
brew install openssl@3
export CPPFLAGS="-I/opt/homebrew/opt/openssl@3/include"
export LDFLAGS="-L/opt/homebrew/opt/openssl@3/lib"
cd src && make clean && make linuxdocker build -t clawsec .
# For chat mode
docker run -p 8888:8888 clawsec -l -p 8888 -k "Password" -c
# For reverse shell
docker run -p 8888:8888 clawsec -l -p 8888 -k "Password" -e /bin/shdocker-compose upkubectl apply -f kubernetes.yamlEdit the Secret in kubernetes.yaml:
stringData:
password: "YourNewPassword"No. ClawSec 2.0 uses a completely different protocol and encryption. It cannot communicate with legacy Cryptcat.
- Linux (x86_64, ARM)
- macOS (Intel, Apple Silicon)
- FreeBSD
- NetBSD
- OpenBSD
- Solaris
Yes. ClawSec works on ARM platforms including Raspberry Pi.
See CONTRIBUTING.md for guidelines.
Email maintainers privately. Do not open public issues for security vulnerabilities.
- GitHub Issues: https://github.com/LF3551/ClawSec/issues
- Documentation: README.md, SECURITY.md
- Examples: EXAMPLE_USAGE.md
Not currently. Use GitHub Discussions or Issues.