Rust: Add conversion between raw types and safe wrappers

[dknopik]

This enables use cases where users want to perform some computations using the blst_* functions, but also use the blst::{min_pk,min_sig}::* types elsewhere.

[dot-asm]

This needs to be renamed to core::convert::TryFrom. You can choose to do nothing and I'll change it on commit :-)

[dknopik]

ah, of course. good catch!

[dot-asm]

I'd argue against this (as well as TryFrom below). Secret key interfaces should discourage copying of the secret key material, not encourage it(*). Well, one can say that this is inconsistent with the fact that SecretKey has Clone (auto-derived) trait. I'd argue that it was a mistake, unfortunately removing it constitutes a breaking change :-( As alternative I'd suggest a reference transmute. This naturally entails adding #repr(transparent) to the structure definition.

(*) Granted, Rust common practices don't appear to be really conducive to handling secret key material.

[dknopik]

Sounds reasonable. Would you rather change these methods to do the transmutation or leave it to the user?

[dot-asm]

I'm torn on this. I appreciate the fact that suggested from_scalar_unchecked is marked unsafe, because it makes the user pay attention. But it's impossible to mark impl<'a> From<&'a blst_scalar> for &'a SecretKey unsafe and as result it will appear safe to the user. On the other hand it's a convenience method that doesn't make a copy of the secret key material, hence there is no strong reason for making the user pay as much attention... So I suppose it's appropriate to internalize the unsafe transmute...

However, as it turns out it's impossible to have both From<&'a blst_scalar> and TryFrom<&'a blst_scalar> for &'a SecretKey. So I suppose one can add

        impl<'a> core::convert::TryFrom<&'a blst_scalar> for &'a SecretKey {
            type Error = BLST_ERROR;

            fn try_from(value: &'a blst_scalar) -> Result<Self, Self::Error> {
                unsafe {
                    if !blst_sk_check(value) {
                        return Err(BLST_ERROR::BLST_BAD_ENCODING);
                    }
                    Ok(transmute::<_, _>(value))
                }
            }
        }

And leave the option to perform the raw unchecked transmute to the user.

[dot-asm]

As for referred PR to sigp/achor. Note that there are blst_sk_{add,sub,mul}_n_check that operate on scalars as opposed to fr_t...

[dknopik]

As for referred PR to sigp/achor. Note that there are blst_sk_{add,sub,mul}_n_check that operate on scalars as opposed to fr_t...

Thanks for looking at that. Can you elaborate? Forgive my ignorance, what would be the main motivator to operate on scalars instead? It seems to be slower (maybe due to the checks?). Is it a correctness issue?

[dot-asm]

Forgive my ignorance, what would be the main motivator to operate on scalars instead?

The assumption is that conversion between field elements and scalars is more than likely to entail copying of the secret key material, which is considered undesirable. The subroutines in question do spend a handful additional cycles to check if the result is zero, and I'm surprised that you notice. Well, unless you're performing some "zoomed-in" micro-/nano-/picobenchmarks. Or running on non-x86_64 or non-aarch64 platforms. Otherwise the difference should be virtually inconceivable on the grand scale of a complete operation.

[dknopik]

The subroutines in question do spend a handful additional cycles to check if the result is zero, and I'm surprised that you notice.

Yeah, my bad - I was benchmarking incorrectly, the difference is in fact unnoticeable. Thanks for the advice, will keep it in mind as soon as I clean my implementation up with regard to cleaning up key material.

[dot-asm]

Thanks!