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.