Encryption
How PinkyBond encrypts messages and calls
Everything she shares with you is encrypted on her phone and decrypted on yours. Our server forwards sealed envelopes it cannot open. We never hold the key.
Built on platform cryptography
We did not write our own crypto. On iPhone we use Apple's CryptoKit. On Android we use Google's Tink. Curve25519 key agreement, HKDF-SHA256 and AES-256-GCM on both, pinned to each other by shared test vectors, so an iPhone and an Android phone produce byte-for-byte identical ciphertext.
Key agreement
Curve25519 (X25519) ECDH
Encryption
AES-256-GCM
Key derivation
HKDF-SHA256
What we do, and what we don't
Every row is checkable. The last three are where we fall short of the best messengers, and we would rather you read that here than find it out later.
| Dimension | PinkyBond |
|---|---|
| Encryption | AES-256-GCM, end-to-end between the two phones |
| Key agreement | Curve25519 (X25519) ECDH, then HKDF-SHA256 |
| Implementation | Apple CryptoKit on iPhone, Google Tink on Android — byte-for-byte interoperable |
| Key storage | iOS Keychain / Android Keystore, hardware-backed where available |
| Pairing | QR code in person, or a 6-character code / link exchanged remotely; both public keys exchanged |
| Verification | A 6-digit code on both phones confirms no one sat in the middle |
| Account | None — no phone number, no email, no password |
| Server access to message and call content | None. We never hold the key. |
| What the relay stores | Pairing id, message type, timestamp, size, ciphertext — deleted once delivered, at most 30 days |
| Photos, videos and files | Up to 2 GB, sealed with a fresh key per file that only your two phones hold; deleted once downloaded, at most 30 days. To a partner app that has not updated yet: up to 25 MB under the pairing key, kept 30 days |
| Call log | Which phone called, when, voice or video, the outcome and duration — readable by our server, kept 90 days, deleted when you unpair. Never the audio or video. |
| Push notifications | Carry no text; the phone decrypts locally |
| Safety Mode | Yes — her phone sends neutral substitute data instead of her real status. Your app shows no indicator, though the flag itself is in the snapshot. |
| Forward secrecy | No — one key per pairing |
| Open source | No |
| Independent audit | Not yet |
How pairing works
No phone number. No email. No account. In the same room, she shows a QR code and you scan it. Apart, she sends you a 6-character code or a link. Either way both phones exchange public keys, derive the same secret, and show a 6-digit verification code so the two of you can confirm no one sat in the middle.
She taps “Pair with partner” in PinkyBloom
Her phone generates a Curve25519 key pair (Apple CryptoKit on iPhone, Google Tink on Android)
She shows a QR code, or sends you a 6-character code or link if you are apart
You scan or enter it in PinkyBond, and your phone generates its own key pair
Your public key travels back to her the same way; both phones now hold both public keys
Each phone runs ECDH and HKDF-SHA256 to derive the same shared secret — nothing secret crosses the network
The shared secret is stored in the iOS Keychain or the Android Keystore
A 6-digit verification code appears on both phones; if they match, no one sat in the middle
The Blind Relay
Our server is a mailbox for sealed envelopes. It holds ciphertext only until the other phone picks it up and then deletes it — after 30 days at most, if that phone stays offline. It never holds a key. Push notifications carry no text; the phone decrypts locally.
PinkyBloom
Encrypts on her phone
Blind Relay
Holds ciphertext until delivered, 30 days at most
Cannot decrypt
PinkyBond
Decrypts on your phone
Everything our server stores about a message, a file and a call:
pairingId
Identifier for the pairing; not a name, number or email
senderRole
Which app sent it: PinkyBloom or PinkyBond
messageType
What kind of envelope it is — for example a chat message, a status snapshot, a receipt or a call setup — never what is inside
timestamp
When it was sent
ciphertext
AES-256-GCM blob we cannot open; its length is the only thing we can measure
retention
Deleted as soon as the other phone receives it; 30 days at most if it stays offline
relayReceipts
After delivery, a record with no content: which message it was and whether it was delivered or expired. Kept 30 days, so the sender’s phone can show “not delivered”
mediaObjects
Photos, voice notes, videos and files up to 2 GB, stored on Cloudflare R2 as ciphertext under a fresh key per file that travels only inside the encrypted message. Deleted once your partner’s phone has downloaded it; 30 days at most
callLog
Which of the two phones called, when, voice or video, answered, missed or declined, and how long it lasted. Readable by our server — that is how a phone that was off still learns about a missed call. Kept 90 days, deleted when you unpair. Never audio or video
Calls
Voice and video are peer-to-peer WebRTC with DTLS-SRTP and fresh keys for every call. The call setup rides the encrypted relay like any message. Before media flows, your phone checks the peer's DTLS fingerprint against a key derived from the pairing secret; a failed check aborts the call.
When a network blocks a direct path, a relay forwards packets it cannot read. No media server ever hears a call, and no call is recorded. It works iPhone to Android. What our server does keep is a call log — which phone called, when, voice or video, the outcome and how long it lasted — for 90 days, so a partner whose phone was off still sees the missed call. More on /calls.
Safety Mode
Encryption protects her data from outsiders and from us. Safety Mode is for the case where the person on the other end is the concern. She can pause sharing at any time, and he is never notified. She can also turn on Safety Mode, which substitutes neutral data he cannot distinguish from a real update.
When Safety Mode is active, the partner sees:
Phase
“Follicular”
Mood
“Good”
Energy
3 (Moderate)
The neutral data is encrypted and sent through the normal relay, so it looks the same as a real update in transit and on his screen.
