Derive the same ECDH secret at both ends
02The sender creates a fresh P-256 key pair for a message. Each endpoint combines its own private key with the other endpoint’s public key.
This separate candidate has the right 65-byte encoding and 0x04 prefix but is not on P-256. The mandatory curve validation fails before ECDH use. A length/prefix check is not enough.
Source for this drawing: RFC 8291 · Read RFC section 3.1 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
A public point must be validated before it is used for ECDH.
- The application server generates a new ECDH key pair when sending a push message. Its public key is carried in the body’s keyid field; the receiver key pair belongs to the subscription.
- Uncompressed P-256 public points occupy 65 bytes: a 0x04 prefix followed by two 32-byte coordinates. The shape and length alone do not validate a point.
- ECDH(sender private, receiver public) and ECDH(receiver private, sender public) produce the same shared secret. The published example produces 32 bytes.
- The user agent and application MUST verify received public keys are on P-256: not infinity, coordinates in range, and a solution of the curve equation. Failure stops key use; no secret should be derived from that invalid point.
The fixed public points are checked by native cryptographic APIs in regression tests. The picture’s invalid-point case is separate from the valid published exchange. The displayed fixed values are public RFC test data, not keys to reuse for real messages. These illustrations do not send notifications or implement a production encryptor.
Read the RFC section ↗