All posts

FIPS 140-3 Compliance for Mosh: Building Secure and Resilient Remote Connections

I had been testing Mosh over a high-latency link, pushing encrypted data across unpredictable networks. The goal: make it FIPS 140-3 compliant without losing the resilience that makes Mosh shine. FIPS 140-3 is the current U.S. government standard for cryptographic modules. It defines strict requirements for encryption algorithms, key handling, and module integrity. Passing it isn’t a checkbox; it’s a deep rework of every cryptographic path in the code. Mosh (Mobile Shell) already provides stabl

Free White Paper

FIPS 140-3 + VNC Secure Access: The Complete Guide

Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.

Free. No spam. Unsubscribe anytime.

I had been testing Mosh over a high-latency link, pushing encrypted data across unpredictable networks. The goal: make it FIPS 140-3 compliant without losing the resilience that makes Mosh shine. FIPS 140-3 is the current U.S. government standard for cryptographic modules. It defines strict requirements for encryption algorithms, key handling, and module integrity. Passing it isn’t a checkbox; it’s a deep rework of every cryptographic path in the code.

Mosh (Mobile Shell) already provides stable SSH-like connections over roaming networks, seamlessly keeping sessions alive as IPs and connections change. But FIPS 140-3 changes the game: only approved ciphers, secure random number generation, and validated cryptographic libraries can be used. This means replacing or reconfiguring the defaults, removing anything that fails certification, and mapping network resilience to a FIPS-compliant crypto backbone.

The first step is identifying cryptography used by Mosh. Its reliance on AES-256 in OCB mode, for example, collides with FIPS rules, which don’t approve OCB. To comply, Mosh needs alternatives like AES-GCM or AES-CBC, only implemented through modules tested and validated by NIST. Every algorithm call should route through a FIPS-validated library such as OpenSSL built in FIPS mode. The entropy source must be vetted. Self-tests on startup must verify crypto integrity.

Continue reading? Get the full guide.

FIPS 140-3 + VNC Secure Access: Architecture Patterns & Best Practices

Free. No spam. Unsubscribe anytime.

Once the code paths are clean, configuration matters. Operating systems must run with the cryptographic module in FIPS mode. Key exchange must be locked to FIPS-approved DH groups or ECC curves. Session rekeying must meet FIPS intervals. Logs must capture module status without leaking sensitive keys or state. Non-compliant fallbacks must be removed entirely, not just disabled.

Testing is relentless. You verify every handshake, every packet, every reconnection. You simulate high jitter, packet loss, and roaming, ensuring that FIPS 140-3 changes don’t break Mosh’s promise of an unbroken session. You harden against downgrade attacks. You validate with official FIPS test vectors and use continuous monitoring to catch regressions.

The result is Mosh that satisfies federal requirements while keeping its magic: the instant response, the roaming tolerance, the persistence under brutal network conditions. This is the rare case where strict compliance and superior UX truly meet.

If you want to see what secure, resilient, and FIPS 140-3 ready remote connections can look like in practice, build it live in minutes on hoop.dev and cut the time from idea to reality.

Get started

See hoop.dev in action

One gateway for every database, container, and AI agent. Deploy in minutes.

Get a demoMore posts