Diffie-Hellman results are parsed as scalars during output recovery

[AaronFeickert]

When scanning for one-sided outputs, the client computes a Diffie-Hellman shared secret, serializes it to bytes, and then parses the bytes using modular reduction to a scalar. This scalar is then hashed and parsed as a scalar for use in commitment mask extraction. That scalar is then hashed again, parsed as a scalar, and used as input to a KDF for value decryption.

The relevant code:

• for non-stealth addresses
• for stealth addresses

While Diffie-Hellman exchange results are uniformly-distributed group elements, they need not be uniformly-distributed byte arrays. Performing scalar reduction prior to the other operations used for key derivation is nonstandard and could lead to collisions. A more standard and safe approach could be the following:

• Use the exchange result directly as input to the value encryption KDF
• If mask extraction is not guaranteed to provide its own KDF (with scalar output) for the rewind key, use the exchange result directly as input to a scalar-output KDF to produce the rewind key; otherwise, it may be safe to pass the exchange result directly to the extractor

Note that this should not apply to the method used for detecting stealth address matching. That code hashes the shared secret prior to parsing as a scalar.

[AaronFeickert]

Currently working on a fix for this. It uses separate KDFs that each take the shared secret as input: one for the spending key, another for the rewind key, and a third for the encryption key. This also takes advantage of the new DiffieHellmanSharedSecret type.