On 8/31/20 8:34 PM, Michael Richardson wrote: > > Stijn Tintel <[email protected]> wrote: > >> The question came up if we really want RSA certificates for LuCI or if > >> the faster and "more modern" ECC P-256 wouldn't be a better choice. > >> > >> If px5g is added to the next release, certificates are generated on > >> first boot and most users are unlikely to manually recreate RSA ones, > >> not? > >> > >> So the question, shouldn't we drop all crypto options from the new > >> px5g implementation and _only_ offer P-256? Whoever wants something > >> else than the default may use px5g-mbedtls or some OpenSSL based tool? > > > I'm no expert, but I recently came across this article: > > https://gravitational.com/blog/comparing-ssh-keys/ > > While it is about SSH keys, it talks mostly about algorithms used, and > > the article suggests using either RSA or Ed25519, not DSA or ECDSA. > > Yes, both DSA and some forms of ECDSA require a good random number. > If the random number can be predicted, then an observer can actually derive > the *private* key from the signature! Scared the pants off me when I learnt > this 20 years ago.
The need for random numbers in ECDSA signatures is very bad, Sony did this wrong in the Play station 3 and leaked their private signing key: https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm#Security > There are ways to use ECDSA where the number input is derived in a way that > is not subject to this attack, and most libraries do that now. > DSA/DSS has all sorts of other stupid things that make it way worse than RSA > (despite what the GNUPG team said for a few years a decade ago) There is deterministic ECDSA which avoids the need for random numbers for signing, mbedtls supports this and we activated it some years ago. https://tools.ietf.org/html/rfc6979 We should check if wolfssl also uses it. > > Additionally, https://safecurves.cr.yp.to/ claims neither P-256 nor > > P-384 are safe. > > Bernstein has maintained for sometime that the NIST/Certicom curves were > derived in a specific way that permitted some secret factorization. > > I understand his concern, and given the choice, I would use EdDSA in new work > rather than ECDSA. > But, browsers do not support EdDSA well yet, so ECDSA it is for now. > However, to date (despite Snowden) only the NSA knows what they did to > P256/P384, if they did anything. I would suspect that if they can do > something, it's not that cheap, and they can't undo all communication > magically. (Like in the movie _Sneakers_) Yes the 3 curves specified by the NIST (p256, p384, and p521) are the only ones supported by all browsers. If there are backdoors in them, they are probably all affected, but such a backdoor should only allow to do an activate MitM and not for passive eavesdropping. > > Based on this information, I would NAK this. Unless an expert proves me > > wrong. > > I would NAK on _only_ P256. I am fine with P-256 by default. > I see no reason to support RSA. > I would always want a second curve deployed, and for that I'd pick one of > the brainpool curves: will browsers support them, I have no idea. > EdDSA is really a different algorithm, and browsers do not support them yet. I would just support RSA in addition, if all the NIST curves are broken, I would not use the brainpool curves but something else. Hauke
signature.asc
Description: OpenPGP digital signature
_______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
