51–60 of 60 posts
Earlier quoted context omitted.
Is it a coincidence the generated keys start with the same first 3 letters (“MII…”)?
Nope. See https://www.thedigitalcatonline.com/blog/2018/04/25/rsa-keys... for example: "Please note that, due to the structure of the underlying ASN.1 structure, RSA PEM bodies start always with the same characters: MIG for 1024 bit keys, MII for 2048 and 4096 bit ones."
Earlier quoted context omitted.
> Curious to know if/when the OpenSSH folks will add Ed448 Yeah, it's a little weird feeling to downgrade in best-estimate security level to go from 4096 bit RSA to ed25519. Ed448 avoids that concern.
RSA 3072 has the 'comparable' security of AES 128: * https://www.keylength.com/en/4/ Going to 4096 doesn't get you much given you have weaker links in the security chain. The next step up would be AES 192 and RSA 7680, and then AES 256 with RSA 15360.
Even when AES and ECC have similar security they have different behavior in terms of multi-target attacks and the curve for success probability vs computation invested are quite different.
You're also not limited to use AES 128 with ssh, ChaCha20-Poly1305 is a nice choice.
Earlier quoted context omitted.
Somehow I've never heard of Curve448 or the company Rambus. It's giving me (unfounded) Crypto AG vibes. https://en.wikipedia.org/wiki/Crypto_AG
This comment is cringe enough that it is making the rounds on multiple Slacks. It's fine that you've never heard of Curve448. That just means you're not a cryptography engineer. Most people aren't! But if you're not one of those, be a little careful about connecting the dots to things like "Crypto AG". Saying "I've never heard of Curve448, it sounds sketchy" is a little like a systems programmer saying "I've never he…
Earlier quoted context omitted.
Last I checked, Azure didn't support Ed25519 keys, so manual fallback to RSA will now be required. https://feedback.azure.com/d365community/idea/1dca6716-dc25-...
That wouldn’t surprise me at all. I recently had issues with an EC2 instance in AWS that I couldn’t auth to, with an Ed25519-based key. Turns out they didn’t even support it until ~2021. These instances were created before then. It took quite a while to figure out what was going on.
Earlier quoted context omitted.
That seems like specifically Azure DevOps, not the Azure platform generally? I assume any OS running inside Azure Compute, or any other managed services will support Ed25519 fine?
The API for creating Azure VMs doesn't support specifying an ED25519 key. https://docs.microsoft.com/en-us/azure/virtual-machines/linu... But once you've created the VM you can log in and replace that RSA key with an ED25519 one just like any standard Linux install, via ssh-copy-id or manually updating authorized_keys or whatever you want. So you just need a throwaway RSA key for the initial deployment.
Earlier quoted context omitted.
This comment is cringe enough that it is making the rounds on multiple Slacks. It's fine that you've never heard of Curve448. That just means you're not a cryptography engineer. Most people aren't! But if you're not one of those, be a little careful about connecting the dots to things like "Crypto AG". Saying "I've never heard of Curve448, it sounds sketchy" is a little like a systems programmer saying "I've never he…
Damage control slacks?
Earlier quoted context omitted.
If you are doing hundreds or thousands of SSH connections per second, you are doing something wrong. At least in 99.9% of cases. Github might be different, but not the rest of the world.
The comments about Ed25519 versus Ed448 were meant for the general case of their use, and not (necessarily) strictly in the use for SSH. However, the reason for Ed25519 use in OpenSSH is because the keys are much smaller, and easier to cut/paste/etc, for the same security factor. The fact that they are faster for signing is a bonus. * https://lists.mindrot.org/pipermail/openssh-unix-dev/2023-Se... RFC 8032 § 7.1. Tes…
Earlier quoted context omitted.
Damage control slacks?
No, Curve448 is as good as can be per the public knowledge, see https://safecurves.cr.yp.to/ . What one could expect given Rambus history is undisclosed patents, possibly the most efficient hardware implementation. They have been known to get their tech standardized (not disclosing IP claims) and come back at adopters with patent violation suits.
Earlier quoted context omitted.
No, Curve448 is as good as can be per the public knowledge, see https://safecurves.cr.yp.to/ . What one could expect given Rambus history is undisclosed patents, possibly the most efficient hardware implementation. They have been known to get their tech standardized (not disclosing IP claims) and come back at adopters with patent violation suits.
Curve448 was published almost 10 years ago. What aspects of it could have been patented, and what patents does Rambus have covering those claims?
I'm not really concerned but I also understand why one wouldn't implement anything Rambus related given their history of patent trolling...
Earlier quoted context omitted.
Nope. See https://www.thedigitalcatonline.com/blog/2018/04/25/rsa-keys... for example: "Please note that, due to the structure of the underlying ASN.1 structure, RSA PEM bodies start always with the same characters: MIG for 1024 bit keys, MII for 2048 and 4096 bit ones."
Seems like this would be susceptible to an Inference Attack.