Feature Request: Add ed25519 SSH Key Support for Secrets Management

[Cre-eD]

Feature Request: Add ed25519 SSH Key Support for Secrets Management

Summary

Add support for ed25519 SSH keys in addition to the currently supported RSA-2048 keys for the secrets management system.

Motivation

Currently, Simple Container's secrets management only supports RSA SSH keys (2048-bit) as documented in the secrets management guide. However, ed25519 has become the modern standard for SSH keys and offers several advantages:

Benefits of ed25519 Support:

1. Enhanced Security

   • Ed25519 provides security equivalent to ~3000-bit RSA keys
   • Resistant to timing attacks and side-channel attacks
   • Based on elliptic curve cryptography (Curve25519)

2. Performance Improvements

   • Significantly faster key generation (milliseconds vs seconds)
   • Faster signing and verification operations
   • Lower computational overhead for encryption/decryption

3. Smaller Key Size

   • 256-bit keys vs 2048-bit RSA keys
   • More compact public keys (68 characters vs 372+ characters)
   • Easier to manage and share with team members

4. Modern Standard

   • Recommended by security experts and organizations
   • Default key type in many modern SSH implementations
   • Growing ecosystem support (GitHub, GitLab, BitBucket all support ed25519)

5. User Convenience

   • Many developers already use ed25519 as their primary SSH key type
   • Eliminates the need to generate separate RSA keys just for Simple Container
   • Better alignment with modern security best practices

Current Limitations

As documented in the secrets management guide, users currently need to:

# Generate RSA key (current requirement)
ssh-keygen -t rsa -b 2048 -f ~/.ssh/id_rsa -N ""

Users with ed25519 keys must either:

• Generate a separate RSA key pair specifically for Simple Container
• Replace their existing ed25519 keys with RSA keys
• Manage multiple key pairs for different tools

Proposed Solution

Add support for ed25519 SSH keys alongside the existing RSA support:

1. Key Generation

Allow sc secrets init -g to generate ed25519 keys:

# Option 1: Auto-detect and use modern default
sc secrets init -g  # Should generate ed25519 by default

# Option 2: Explicit key type selection
sc secrets init -g --key-type ed25519
sc secrets init -g --key-type rsa  # Maintain backward compatibility

2. Key Detection

Automatically detect and support both key types:

# .sc/cfg.default.yaml - RSA keys
privateKeyPath: ~/.ssh/id_rsa
publicKeyPath: ~/.ssh/id_rsa.pub
projectName: simple-container-api

# .sc/cfg.default.yaml - Ed25519 keys
privateKeyPath: ~/.ssh/id_ed25519
publicKeyPath: ~/.ssh/id_ed25519.pub
projectName: simple-container-api

3. Team Collaboration

Support mixed key types within teams:

# Allow team members with different key types
sc secrets allow "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQ... user1@host"
sc secrets allow "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... user2@host"

4. Documentation Updates

Update the secrets management guide to reflect:

• Ed25519 as the recommended key type
• RSA support maintained for backward compatibility
• Mixed key type support in teams

Implementation Considerations

Backward Compatibility

• Maintain full support for existing RSA-2048 keys
• Existing projects should continue to work without changes
• Gradual migration path for existing users

Encryption Library

The Go standard library provides excellent support for ed25519:

import "crypto/ed25519"
import "golang.org/x/crypto/ssh"

Public Key Format

Support standard SSH public key formats:

• RSA: ssh-rsa AAAAB3NzaC1yc2E...
• Ed25519: ssh-ed25519 AAAAC3NzaC1lZDI1NTE5...

Hybrid Encryption Approach

Since ed25519 is a signing algorithm, consider using it in combination with:

• X25519 for key exchange (ECDH)
• ChaCha20-Poly1305 for symmetric encryption
• Or continue using RSA encryption scheme for actual secret encryption while using ed25519 for authentication/signing

Migration Path

For existing users:

# Step 1: Generate new ed25519 key
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519 -N ""

# Step 2: Update configuration
sc secrets init  # Auto-detects new ed25519 key

# Step 3: Re-encrypt secrets with new key
sc secrets allow "$(cat ~/.ssh/id_ed25519.pub)"
sc secrets hide --force

Use Cases

1. New Projects: Developers can use their existing ed25519 keys from day one
2. Security-Conscious Teams: Organizations can enforce ed25519 for enhanced security
3. CI/CD Pipelines: Faster key generation and operations in automated workflows
4. Large Teams: Smaller public keys are easier to manage and share
5. Modern Infrastructure: Alignment with current security best practices

Alternative Approaches

If full ed25519 support is complex, consider:

1. Phase 1: Support ed25519 for authentication/identification only
2. Phase 2: Implement hybrid encryption (ed25519 + symmetric cipher)
3. Phase 3: Full ed25519 integration with all features

Related Resources

• RFC 8032 - Edwards-Curve Digital Signature Algorithm (EdDSA)
• SSH Protocol Ed25519 Support - RFC 8709
• Go crypto/ed25519 documentation
• Comparing SSH Keys - RSA vs Ed25519

Expected Outcome

After implementing this feature:

✅ Users can use ed25519 SSH keys for secrets management
✅ Existing RSA-based projects continue to work without changes
✅ Teams can use mixed key types (RSA + ed25519)
✅ Faster cryptographic operations
✅ Better security posture
✅ Alignment with modern SSH key standards

Additional Notes

This enhancement would make Simple Container more accessible to modern development teams while maintaining backward compatibility. It represents an investment in security, performance, and user experience that aligns with current industry best practices.

[universe-ops]

resolved through #8