pub struct SharedSecret(/* private fields */);Expand description
The key-agreement shared secret, in big-endian order.
§Why there is one constructor and why it names the byte order
The spikes/tpm-ecdh spike discovered something easily overlooked:
NCryptSecretAgreement with Microsoft Platform Crypto Provider returns the shared
secret in little-endian order, whereas all pure P-256 implementations, including
p256, use the big-endian X-coordinate representation, as prescribed by RFC 5903 (ECDH
for IKE).
Byte order left to a comment is a bug waiting to happen: a reversed secret yields a different AEAD key; the slot will not open, appearing as “file corrupted”. The error would be found, but not at its actual source.
There is therefore exactly one constructor, and its name states the byte order. An implementation receiving NCrypt bytes must reverse them to invoke it truthfully; this cannot be silently forgotten, since the type has no other entry point.
Implementations§
Sourcepub fn from_be_bytes(bytes: [u8; 32]) -> Self
pub fn from_be_bytes(bytes: [u8; 32]) -> Self
The only constructor. Bytes must be big-endian.
Sourcepub fn ct_eq(&self, other: &Self) -> bool
pub fn ct_eq(&self, other: &Self) -> bool
Compare two secrets in constant time.
A named method rather than derived PartialEq: derivation would compare
bytes conventionally, returning early at the first difference,
which is a guessing oracle (I-13). A type for which == is unsafe should not
provide it at all.
Needed externally: the hardware agreement implementation must be checked against the software implementation using identical keys, and comparing secrets is the only way to do that.