Explicitly ban the identity point as an Ethereum Schnorr public key (002)

This doesn't have a well-defined affine representation. k256's behavior,
mapping it to (0, 0), means this would've been rejected anyways (so this isn't
a change of any current behavior), but it's best not to rely on such an
implementation detail.
This commit is contained in:
Luke Parker
2025-04-12 08:37:41 -04:00
parent bef90b2f1a
commit 33018bf6da
2 changed files with 10 additions and 1 deletions

View File

@@ -1,5 +1,5 @@
use subtle::Choice; use subtle::Choice;
use group::ff::PrimeField; use group::{ff::PrimeField, Group};
use k256::{ use k256::{
elliptic_curve::{ elliptic_curve::{
ops::Reduce, ops::Reduce,
@@ -22,6 +22,10 @@ impl PublicKey {
/// bounds such as parity). /// bounds such as parity).
#[must_use] #[must_use]
pub fn new(A: ProjectivePoint) -> Option<PublicKey> { pub fn new(A: ProjectivePoint) -> Option<PublicKey> {
if bool::from(A.is_identity()) {
None?;
}
let affine = A.to_affine(); let affine = A.to_affine();
// Only allow even keys to save a word within Ethereum // Only allow even keys to save a word within Ethereum

View File

@@ -27,6 +27,11 @@ pub(crate) fn test_key() -> (Scalar, PublicKey) {
} }
} }
#[test]
fn test_identity_key() {
assert!(PublicKey::new(ProjectivePoint::IDENTITY).is_none());
}
#[test] #[test]
fn test_odd_key() { fn test_odd_key() {
// We generate a valid key to ensure there's not some distinct reason this key is invalid // We generate a valid key to ensure there's not some distinct reason this key is invalid