On Tue, Mar 29, 2016 at 12:17 PM Emilia Käsper <r...@openssl.org> wrote:
> While we're at this, shouldn't we then also check the length in oct2priv? > (And > either reject or reduce mod n.) Afaics it accepts arbitrary BNs currently, > which means some keys can be parsed but cannot be re-encoded? > Probably. BoringSSL rejects keys that are too large. One compatibility note though: although RFC 5915 and SEC 1 (not sure about X9.62) requires that the private key in an ECPrivateKey structure be exactly the byte length of the order, OpenSSL prior to 30cd4ff294252c4b6a4b69cbef6a5b4117705d22 removed leading zeros, so ECPrivateKey parsers need to allow for short inputs. David -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4393 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev