Alien-libsecp256k1

 view release on metacpan or  search on metacpan

libsecp256k1/CHANGELOG.md  view on Meta::CPAN

#### ABI Compatibility
The ABI is backward compatible with versions 0.4.0 and 0.3.x.

## [0.4.0] - 2023-09-04

#### Added
 - New module `ellswift` implements ElligatorSwift encoding for public keys and x-only Diffie-Hellman key exchange for them.
   ElligatorSwift permits representing secp256k1 public keys as 64-byte arrays which cannot be distinguished from uniformly random. See:
   - Header file `include/secp256k1_ellswift.h` which defines the new API.
   - Document `doc/ellswift.md` which explains the mathematical background of the scheme.
   - The [paper](https://eprint.iacr.org/2022/759) on which the scheme is based.
 - We now test the library with unreleased development snapshots of GCC and Clang. This gives us an early chance to catch miscompilations and constant-time issues introduced by the compiler (such as those that led to the previous two releases).

#### Fixed
 - Fixed symbol visibility in Windows DLL builds, where three internal library symbols were wrongly exported.

#### Changed
 - When consuming libsecp256k1 as a static library on Windows, the user must now define the `SECP256K1_STATIC` macro before including `secp256k1.h`.

#### ABI Compatibility

libsecp256k1/examples/examples_util.h  view on Meta::CPAN

#elif defined(__GNUC__)
    /* We use a memory barrier that scares the compiler away from optimizing out the memset.
     *
     * Quoting Adam Langley <agl@google.com> in commit ad1907fe73334d6c696c8539646c21b11178f20f
     * in BoringSSL (ISC License):
     *    As best as we can tell, this is sufficient to break any optimisations that
     *    might try to eliminate "superfluous" memsets.
     * This method used in memzero_explicit() the Linux kernel, too. Its advantage is that it is
     * pretty efficient, because the compiler can still implement the memset() efficiently,
     * just not remove it entirely. See "Dead Store Elimination (Still) Considered Harmful" by
     * Yang et al. (USENIX Security 2017) for more background.
     */
    memset(ptr, 0, len);
    __asm__ __volatile__("" : : "r"(ptr) : "memory");
#else
    void *(*volatile const volatile_memset)(void *, int, size_t) = memset;
    volatile_memset(ptr, 0, len);
#endif
}

libsecp256k1/include/secp256k1.h  view on Meta::CPAN

 *           0: incorrect or unparseable signature
 *  Args:    ctx:       pointer to a context object
 *  In:      sig:       the signature being verified.
 *           msghash32: the 32-byte message hash being verified.
 *                      The verifier must make sure to apply a cryptographic
 *                      hash function to the message by itself and not accept an
 *                      msghash32 value directly. Otherwise, it would be easy to
 *                      create a "valid" signature without knowledge of the
 *                      secret key. See also
 *                      https://bitcoin.stackexchange.com/a/81116/35586 for more
 *                      background on this topic.
 *           pubkey:    pointer to an initialized public key to verify with.
 *
 * To avoid accepting malleable signatures, only ECDSA signatures in lower-S
 * form are accepted.
 *
 * If you need to accept ECDSA signatures from sources that do not obey this
 * rule, apply secp256k1_ecdsa_signature_normalize to the signature prior to
 * verification, but be aware that doing so results in malleable signatures.
 *
 * For details, see the comments for that function.

libsecp256k1/include/secp256k1_ellswift.h  view on Meta::CPAN

 *
 * If the Y coordinate is relevant, it is given the same parity as t.
 *
 * Changes w.r.t. the paper:
 * - The u=0, t=0, and u^3+t^2+7=0 conditions result in decoding to the point
 *   at infinity in the paper. Here they are remapped to finite points.
 * - The paper uses an additional encoding bit for the parity of y. Here the
 *   parity of t is used (negating t does not affect the decoded x coordinate,
 *   so this is possible).
 *
 * For mathematical background about the scheme, see the doc/ellswift.md file.
 */

/** A pointer to a function used by secp256k1_ellswift_xdh to hash the shared X
 *  coordinate along with the encoded public keys to a uniform shared secret.
 *
 *  Returns: 1 if a shared secret was successfully computed.
 *           0 will cause secp256k1_ellswift_xdh to fail and return 0.
 *           Other return values are not allowed, and the behaviour of
 *           secp256k1_ellswift_xdh is undefined for other return values.
 *  Out:     output:     pointer to an array to be filled by the function

libsecp256k1/src/util.h  view on Meta::CPAN

#elif defined(__GNUC__)
    /* We use a memory barrier that scares the compiler away from optimizing out the memset.
     *
     * Quoting Adam Langley <agl@google.com> in commit ad1907fe73334d6c696c8539646c21b11178f20f
     * in BoringSSL (ISC License):
     *    As best as we can tell, this is sufficient to break any optimisations that
     *    might try to eliminate "superfluous" memsets.
     * This method is used in memzero_explicit() the Linux kernel, too. Its advantage is that it
     * is pretty efficient, because the compiler can still implement the memset() efficently,
     * just not remove it entirely. See "Dead Store Elimination (Still) Considered Harmful" by
     * Yang et al. (USENIX Security 2017) for more background.
     */
    memset(ptr, 0, len);
    __asm__ __volatile__("" : : "r"(ptr) : "memory");
#else
    void *(*volatile const volatile_memset)(void *, int, size_t) = memset;
    volatile_memset(ptr, 0, len);
#endif
#ifdef VERIFY
    SECP256K1_CHECKMEM_UNDEFINE(ptr, len);
#endif