Struct tor_hscrypto::pk::HsClientIntroAuthKey

pub struct HsClientIntroAuthKey(/* private fields */);

👎Deprecated: This key type is not used in the protocol implemented today.

First type of client authorization key, used for the introduction protocol. (KP_hsc_intro_auth)

This is used to sign a nonce included in an extension in the encrypted portion of an introduce cell.

Methods from Deref<Target = PublicKey>

pub fn to_bytes(&self) -> [u8; 32]

Convert this public key to a byte array.

pub fn as_bytes(&self) -> &[u8; 32]

View this public key as a byte array.

pub fn is_weak(&self) -> bool

Returns whether this is a weak public key, i.e., if this public key has low order.

A weak public key can be used to generate a signature that’s valid for almost every message. [Self::verify_strict] denies weak keys, but if you want to check for this property before verification, then use this method.

pub fn verify_strict( &self, message: &[u8], signature: &Signature ) -> Result<(), Error>

Strictly verify a signature on a message with this keypair’s public key.

On The (Multiple) Sources of Malleability in Ed25519 Signatures

This version of verification is technically non-RFC8032 compliant. The following explains why.

1. Scalar Malleability

The authors of the RFC explicitly stated that verification of an ed25519 signature must fail if the scalar s is not properly reduced mod $\ell$:

To verify a signature on a message M using public key A, with F being 0 for Ed25519ctx, 1 for Ed25519ph, and if Ed25519ctx or Ed25519ph is being used, C being the context, first split the signature into two 32-octet halves. Decode the first half as a point R, and the second half as an integer S, in the range 0 <= s < L. Decode the public key A as point A’. If any of the decodings fail (including S being out of range), the signature is invalid.)

All verify_*() functions within ed25519-dalek perform this check.

2. Point malleability

The authors of the RFC added in a malleability check to step #3 in §5.1.7, for small torsion components in the R value of the signature, which is not strictly required, as they state:

Check the group equation [8][S]B = [8]R + [8][k]A’. It’s sufficient, but not required, to instead check [S]B = R + [k]A’.

History of Malleability Checks

As originally defined (cf. the “Malleability” section in the README of this repo), ed25519 signatures didn’t consider any form of malleability to be an issue. Later the scalar malleability was considered important. Still later, particularly with interests in cryptocurrency design and in unique identities (e.g. for Signal users, Tor onion services, etc.), the group element malleability became a concern.

However, libraries had already been created to conform to the original definition. One well-used library in particular even implemented the group element malleability check, but only for batch verification! Which meant that even using the same library, a single signature could verify fine individually, but suddenly, when verifying it with a bunch of other signatures, the whole batch would fail!

“Strict” Verification

This method performs both of the above signature malleability checks.

It must be done as a separate method because one doesn’t simply get to change the definition of a cryptographic primitive ten years after-the-fact with zero consideration for backwards compatibility in hardware and protocols which have it already have the older definition baked in.

Return

Returns Ok(()) if the signature is valid, and Err otherwise.

pub fn to_montgomery(&self) -> MontgomeryPoint

Convert this verifying key into Montgomery form.

This can be used for performing X25519 Diffie-Hellman using Ed25519 keys. The output of this function is a valid X25519 public key whose secret key is sk.to_scalar_bytes(), where sk is a valid signing key for this VerifyingKey.

Note

We do NOT recommend this usage of a signing/verifying key. Signing keys are usually long-term keys, while keys used for key exchange should rather be ephemeral. If you can help it, use a separate key for encryption.

For more information on the security of systems which use the same keys for both signing and Diffie-Hellman, see the paper On using the same key pair for Ed25519 and an X25519 based KEM.

Trait Implementations

impl AsRef<VerifyingKey> for HsClientIntroAuthKey

fn as_ref(&self) -> &PublicKey

Converts this type into a shared reference of the (usually inferred) input type.

impl Clone for HsClientIntroAuthKey

fn clone(&self) -> HsClientIntroAuthKey

Returns a copy of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for HsClientIntroAuthKey

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Deref for HsClientIntroAuthKey

type Target = VerifyingKey

The resulting type after dereferencing.

fn deref(&self) -> &Self::Target

Dereferences the value.

impl From<HsClientIntroAuthKey> for PublicKey

fn from(original: HsClientIntroAuthKey) -> Self

Converts to this type from the input type.

impl From<VerifyingKey> for HsClientIntroAuthKey

fn from(original: PublicKey) -> HsClientIntroAuthKey

Converts to this type from the input type.