• How could you get secp256k1 elliptic curve adopted as a standard by OpenSSH?
• Step 1: Research and Justify the Need
• Step 2: Engage the Community
• Step 3: Develop a Prototype Implementation
• Step 4: Submit and Iterate
• Challenges and Realistic Expectations

§How could you get secp256k1 elliptic curve adopted as a standard by OpenSSH?

Getting a new elliptic curve like secp256k1 (widely used in Bitcoin and Nostr for its security properties) adopted into OpenSSH as a supported key type would be a significant undertaking. OpenSSH prioritizes security, portability, and backward compatibility, so proposals need strong justification, thorough implementation, and community buy-in. It’s not impossible—curves like Ed25519 were added after similar processes—but it requires persistence and technical expertise. Below, I’ll outline a realistic step-by-step approach based on how OpenBSD/OpenSSH handles contributions, drawing from their documentation and past feature adoptions.

§Step 1: Research and Justify the Need

• Understand the Current Landscape: Review OpenSSH’s supported key types (e.g., via ssh -Q key). It already supports ECDSA on NIST curves (like secp256r1) and Ed25519 (on Curve25519), but not secp256k1. Identify why secp256k1 would be beneficial—e.g., better integration with crypto ecosystems like Bitcoin/Nostr, potential performance advantages, or resistance to certain attacks (secp256k1 has safeguards against some side-channel vulnerabilities).
• Check Standards and Precedents: secp256k1 is defined in SEC 2 (by Certicom) and used in FIPS 186-4, but it’s not as universally standardized for SSH as NIST curves. Look for IETF RFCs (e.g., RFC 5656 for ECDSA in SSH) and see if there’s an existing draft or proposal for secp256k1 in SSH. If not, you might need to propose one via the IETF’s CURDLE working group, as SSH protocol extensions often start there.
• Gather Evidence: Collect benchmarks, security analyses, and use cases (e.g., “Enables seamless SSH auth with Nostr keys”). Reference implementations in libraries like OpenSSL or libsecp256k1 (from Bitcoin Core).

§Step 2: Engage the Community

• Join Mailing Lists: The primary venue is the OpenBSD tech@openbsd.org mailing list (or misc@ for general discussion). Introduce your idea politely, explaining the benefits and addressing potential concerns like added code complexity or attack surface. Be prepared for scrutiny—OpenBSD developers are security-focused and may push back if it doesn’t align with their “secure by default” philosophy.
• Discuss on Relevant Forums: Post on openssh-unix-dev@mindrot.org (the OpenSSH-specific list) for portability feedback. If it ties into broader crypto standards, engage the IETF CURDLE list. Share your research from Step 1 to build credibility.
• Build Alliances: Reach out to key maintainers (e.g., via public channels) like Damien Miller or Markus Friedl, who have worked on crypto features. If there’s interest from other projects (e.g., Linux distros or Nostr communities), rally support letters or endorsements.

§Step 3: Develop a Prototype Implementation

• Fork and Patch: Clone the OpenSSH portable repository (from GitHub mirror or OpenBSD CVS). Implement support for secp256k1-based keys, likely by extending the ECDSA code path (e.g., in key.c, ssh-ecdsa.c, and related files). Use an existing library like OpenSSL (which supports secp256k1 via EC_KEY APIs) or integrate libsecp256k1 for better performance/security.
• Key Implementation Details:
  • Add curve parameters (OID, prime, etc.) to the code.
  • Support key generation, signing/verification, and host key algorithms (e.g., “ecdsa-sha2-secp256k1”).
  • Ensure compatibility with SSH protocol (RFC 5656).
  • Write tests for ssh-keygen, sshd, and ssh.
• Security Audit: Self-audit for vulnerabilities (e.g., constant-time operations to prevent timing attacks). Use tools like Valgrind or fuzzers.
• Portability: Test on multiple platforms (OpenBSD, Linux, macOS, Windows via MSYS2) to ensure it works with the “portable” version.

§Step 4: Submit and Iterate

• Propose the Patch: Send a diff or pull request to the mailing list with your prototype. Include documentation updates (e.g., man pages for ssh-keygen -t ecdsa-secp256k1).
• Handle Feedback: Expect revisions—developers might request changes for code style, security, or minimalism. Iterate based on input.
• Advocate for Inclusion: If the patch is solid, it could land in an OpenBSD release first, then propagate to OpenSSH portable. Releases happen roughly every 6 months with OpenBSD versions.

§Challenges and Realistic Expectations

• Timeframe: This could take months to years. Ed25519 support was added in OpenSSH 6.5 (2014) after years of crypto community discussion.
• Potential Roadblocks:
  • Security Concerns: secp256k1 isn’t a NIST curve, and OpenBSD avoids anything with potential backdoors or weak standardization.
  • Code Bloat: They prefer lean code; if it requires bundling a new library, that might be a non-starter.
  • Adoption: Even if added, widespread use depends on clients/servers updating.
  • Alternatives: They might suggest using existing curves or user-defined keys via extensions.
• Success Factors: Strong rationale (e.g., growing Nostr/Bitcoin use), clean code, and persistence. If it’s rejected, you could maintain a fork or plugin (e.g., via OpenSSH’s multiplexing for custom auth).

If you’re serious about pursuing this, start with the mailing lists and share your use case—community feedback is key. I can help brainstorm a sample email pitch or point to resources if you provide more details on your motivation!