Struct libsecp256k1::Signature

source · [−]

pub struct Signature {
    pub r: Scalar,
    pub s: Scalar,
}

Expand description

An ECDSA signature.

Fields

r: Scalars: Scalar

Implementations

source

impl Signature

source

pub fn parse_overflowing(p: &[u8 ; 64]) -> Signature

Parse an possibly overflowing signature.

A SECP256K1 signature is usually required to be within 0 and curve order. This function, however, allows signatures larger than curve order by taking the signature and minus curve order.

Note that while this function is technically safe, it is non-standard, meaning you will have compatibility issues if you also use other SECP256K1 libraries. It’s not recommended to use this function. Please use parse_standard instead.

source

pub fn parse_standard(p: &[u8 ; 64]) -> Result<Signature, Error>

Parse a standard SECP256K1 signature. The signature is required to be within 0 and curve order. Returns error if it overflows.

source

pub fn parse_overflowing_slice(p: &[u8 ]) -> Result<Signature, Error>

Parse a possibly overflowing signature slice. See also parse_overflowing.

It’s not recommended to use this function. Please use parse_standard_slice instead.

source

pub fn parse_standard_slice(p: &[u8 ]) -> Result<Signature, Error>

Parse a standard signature slice. See also parse_standard.

source

pub fn parse_der(p: &[u8 ]) -> Result<Signature, Error>

Parse a DER-encoded byte slice to a signature.

source

pub fn parse_der_lax(p: &[u8 ]) -> Result<Signature, Error>

Converts a “lax DER”-encoded byte slice to a signature. This is basically only useful for validating signatures in the Bitcoin blockchain from before 2016. It should never be used in new applications. This library does not support serializing to this “format”

source

pub fn normalize_s(&mut self)

Normalizes a signature to a “low S” form. In ECDSA, signatures are of the form (r, s) where r and s are numbers lying in some finite field. The verification equation will pass for (r, s) iff it passes for (r, -s), so it is possible to ``modify’’ signatures in transit by flipping the sign of s. This does not constitute a forgery since the signed message still cannot be changed, but for some applications, changing even the signature itself can be a problem. Such applications require a “strong signature”. It is believed that ECDSA is a strong signature except for this ambiguity in the sign of s, so to accommodate these applications libsecp256k1 will only accept signatures for which s is in the lower half of the field range. This eliminates the ambiguity.

However, for some systems, signatures with high s-values are considered valid. (For example, parsing the historic Bitcoin blockchain requires this.) For these applications we provide this normalization function, which ensures that the s value lies in the lower half of its range.

source