You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As I was going through the code, I had a few questions around the private keys that sshizzle uses.
The Terraform script generates a CA key that is 2048 bits in size and is not configurable (I believe this is the snippet). For the CA key, would it make sense to make that 4096-bit by default, or at least make it configurable? The key is generated only once, and the additional cost of signing with a 4096-bit key instead of a 2048-bit one should be negligible.
Of course, anyone can simply use their own TF script, but defaults hold a lot of power :)
On the other hand, it makes sense that sshizzle-agent uses a 2048-bit RSA key, given that (if I understand correctly) a new key is generated every time the agent is started (presumably every time the client is rebooted, at least?). It's short-lived, and longer RSA keys take much longer to generate.
However, how about making sshizzle-agent configurable so users can choose what kind of key to use, possibly supporting ECC (like Ed25519) too? ECC keys are generated "instantly" and allow for much smaller signatures. SSH does support ECC keys (including Ed25519), and even if Azure Key Vault continues to use RSA for the CA (as support for ECC in AKV is more limited), it should be possible to use ECC for client certs regardless.
The text was updated successfully, but these errors were encountered:
As I was going through the code, I had a few questions around the private keys that sshizzle uses.
Of course, anyone can simply use their own TF script, but defaults hold a lot of power :)
However, how about making sshizzle-agent configurable so users can choose what kind of key to use, possibly supporting ECC (like Ed25519) too? ECC keys are generated "instantly" and allow for much smaller signatures. SSH does support ECC keys (including Ed25519), and even if Azure Key Vault continues to use RSA for the CA (as support for ECC in AKV is more limited), it should be possible to use ECC for client certs regardless.
The text was updated successfully, but these errors were encountered: