[RFC] self-signed certificates for LuCI

[Hauke Mehrtens]

On 8/31/20 8:34 PM, Michael Richardson wrote:
> 
> Stijn Tintel <stijn at linux-ipv6.be> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openwrt.org/pipermail/openwrt-devel/attachments/20200831/cdef4cc5/attachment.sig>