Earlier quoted context omitted.
> which is kind of on margin even classically Is it though? It requires around 2^128 operations to be broken. It does not seem very marginal to me. It is not like AES where you have to deal with batch-attacks or cryptographic hash functions where collisions for a n-length output require only sqrt(2^n) attempts.
That’s not how it works! That 128 bits is theoretical upper bound, not necessarily an achievable security rate. That’s the point of margin.
SSH Keygen – RSA, DSA, Ecdsa, EdDSA
41–45 of 45 posts
Re: SSH Keygen – RSA, DSA, Ecdsa, EdDSA
#42This isn't that complicated. The answer is, simply: ED25519 if you're using modern services that support it. or RSA (4096 or at least 2048 bits) for services that cannot handle ED25519 (including AWS -- yes, still, even in 2020.) So you should probably generate both to cover most possible scenarios: ssh -t ed25519 # for most purposes (not AWS) ssh -t rsa -b 4096 # for when you're not using something like Userify
It should be "ssh-keygen", not "ssh". ssh-keygen -t ed25519 ssh-keygen -t rsa -b 4096
Re: SSH Keygen – RSA, DSA, Ecdsa, EdDSA
#43The only downside to Ed25519 is that it will fall to quantum computing before RSA 4096.
And the only downside to RSA 4096 is that it will fall before Niederreiter using binary Goppa codes?
The number of usable qubits in a single computation is expensive and has been growing slowly and until that changes I figure it's more likely to be surprised by a break of ed25519 but not RSA 4096 than to be surprised by a break of both.
Re: SSH Keygen – RSA, DSA, Ecdsa, EdDSA
#44Earlier quoted context omitted.
This is outdated in terms of recommending bcrypt blindly. Bcrypt has some flaws (leading null bytes, being only "cpu hard") that are addressed by newer hashing functions. Argon2 in independent mode or hybrid mode seems to be the most common recommendation among security luminaries today.
https://news.ycombinator.com/item?id=24286955