16 Nov, 2018

2 commits

  • ecc_point_mult is supposed to be used with a regularized scalar,
    otherwise, it's possible to deduce the position of the top bit of the
    scalar with timing attack. This is important when the scalar is a
    private key.

    ecc_point_mult is already using a regular algorithm (i.e. having an
    operation flow independent of the input scalar) but regularization step
    is not implemented.

    Arrange scalar to always have fixed top bit by adding a multiple of the
    curve order (n).

    References:
    The constant time regularization step is based on micro-ecc by Kenneth
    MacKay and also referenced in the literature (Bernstein, D. J., & Lange,
    T. (2017). Montgomery curves and the Montgomery ladder. (Cryptology
    ePrint Archive; Vol. 2017/293). s.l.: IACR. Chapter 4.6.2.)

    Signed-off-by: Vitaly Chikunov
    Cc: kernel-hardening@lists.openwall.com
    Signed-off-by: Herbert Xu

    Vitaly Chikunov
     
  • Currently used scalar multiplication algorithm (Matthieu Rivain, 2011)
    have invalid values for scalar == 1, n-1, and for regularized version
    n-2, which was previously not checked. Verify that they are not used as
    private keys.

    Signed-off-by: Vitaly Chikunov
    Signed-off-by: Herbert Xu

    Vitaly Chikunov
     

09 Jul, 2018

1 commit

  • According to SP800-56A section 5.6.2.1, the public key to be processed
    for the ECDH operation shall be checked for appropriateness. When the
    public key is considered to be an ephemeral key, the partial validation
    test as defined in SP800-56A section 5.6.2.3.4 can be applied.

    The partial verification test requires the presence of the field
    elements of a and b. For the implemented NIST curves, b is defined in
    FIPS 186-4 appendix D.1.2. The element a is implicitly given with the
    Weierstrass equation given in D.1.2 where a = p - 3.

    Without the test, the NIST ACVP testing fails. After adding this check,
    the NIST ACVP testing passes.

    Signed-off-by: Stephan Mueller
    Signed-off-by: Herbert Xu

    Stephan Mueller
     

21 Apr, 2018

1 commit

  • On the quest to remove all VLAs from the kernel[1], this avoids VLAs
    by just using the maximum allocation size (4 bytes) for stack arrays.
    All the VLAs in ecc were either 3 or 4 bytes (or a multiple), so just
    make it 4 bytes all the time. Initialization routines are adjusted to
    check that ndigits does not end up larger than the arrays.

    This includes a removal of the earlier attempt at this fix from
    commit a963834b4742 ("crypto/ecc: Remove stack VLA usage")

    [1] https://lkml.org/lkml/2018/3/7/621

    Signed-off-by: Kees Cook
    Signed-off-by: Herbert Xu

    Kees Cook
     

16 Mar, 2018

1 commit

  • On the quest to remove all VLAs from the kernel[1], this switches to
    a pair of kmalloc regions instead of using the stack. This also moves
    the get_random_bytes() after all allocations (and drops the needless
    "nbytes" variable).

    [1] https://lkml.org/lkml/2018/3/7/621

    Signed-off-by: Kees Cook
    Reviewed-by: Tudor Ambarus
    Signed-off-by: Herbert Xu

    Kees Cook
     

29 Nov, 2017

1 commit

  • If crypto_get_default_rng returns an error, the
    function ecc_gen_privkey should return an error.
    Instead, it currently tries to use the default_rng
    nevertheless, thus creating a kernel panic with a
    NULL pointer dereference.
    Returning the error directly, as was supposedly
    intended when looking at the code, fixes this.

    Signed-off-by: Pierre Ducroquet
    Reviewed-by: PrasannaKumar Muralidharan
    Signed-off-by: Herbert Xu

    Pierre
     

10 Jun, 2017

4 commits


24 Jun, 2016

1 commit


23 Jun, 2016

1 commit