End-to-End Encryption: All message content is encrypted using WebRTC's built-in DTLS encryption. This means your messages are encrypted directly in your browser and can only be decrypted by your peer's browser. No server, network administrator, or third party can read your messages.
The encryption happens at the transport layer through the browser's WebRTC implementation, which uses industry-standard DTLS (Datagram Transport Layer Security) protocols.
How It Works: The Flow
Writer
Share Secrets
Generate Invite Token
O1Click "Generate Invite" to create a WebRTC offer token with your connection details and fingerprint. Share the 8-word token with your colleague.
Waiting for answer...
Wait for your colleague to paste their answer token.
Paste Answer Token
A1Paste the answer token from your colleague to establish the direct WebRTC connection.
Verify Security Code
SASCompare the 6-word security code with your colleague through a separate channel (phone, in person). Check the box when codes match.
Share Secret
Type your secret in the text area. It's encrypted end-to-end and sent directly to your colleague.
Reader
Receive Secrets
Waiting for invite...
Wait for your colleague to send you their invite token.
Paste Invite Token
O1Paste the invite token from your colleague. Your browser will generate an answer token automatically.
Share Answer Token
A1Copy the answer token and send it back to your colleague to complete the connection handshake.
Verify Security Code
SASCompare the 6-word security code with your colleague through a separate channel (phone, in person). Check the box when codes match.
Receive Secret
View the secret in the text area. It arrives encrypted and is only decrypted in your browser.
Peer Authentication
Short Authentication String SAS: To ensure you're communicating with the intended person and not a man-in-the-middle attacker, Naisho uses a Short Authentication String derived from both peers' DTLS fingerprints.
The SAS is computed by:
- Taking the DTLS fingerprints from both peers
- Sorting them alphabetically to ensure consistent ordering
- Computing SHA-256 of the concatenated fingerprints
- Extracting 6 diceware words from the hash
You must compare this SAS code with your peer through a separate, trusted channel (like in person, phone call, or secure messaging). If the codes match, you can be confident you're communicating securely.
Token Security
Diceword Display System
Naisho uses a nice trick to make tokens human-shareable while maintaining security:
- What you see: 8 human-readable words like
apple banana cherry dog elephant forest garden house - What gets copied: Compressed base64url token like
eyJ2IjoxLCJyb2xlIjoid3JpdGVyIiwic2RwT2ZmZXIi... - Security: The dicewords are just a visual representation - the actual cryptographic token is what's transmitted
Signaling Token Safety
The invite O1 and answer A1 tokens contain connection information but no message content.
Token TTL: Invite tokens expire after 3 minutes, significantly reducing the attack window.
Even if these tokens are intercepted or tampered with by an attacker:
- The attacker cannot read your messages (they're end-to-end encrypted)
- Any tampering will cause the SAS verification to fail
- You'll know something is wrong when your SAS codes don't match
- Expired tokens provide detailed error messages indicating how long ago they expired
This is why the SAS verification step is mandatory - it protects against tampering with the signaling process.
Privacy Considerations
- •IP Addresses: Your IP address will be visible to your peer through the direct connection
- •No Server Storage: No messages or connection data are stored on any server
Threat Model
What Naisho Protects Against
Network-Level Attacks
All data is encrypted end-to-end using DTLS. Even if an attacker intercepts network traffic, they cannot decrypt the message content without breaking modern cryptography.
Man-in-the-Middle Attacks
The mandatory SAS verification ensures both parties are connected to each other and not an attacker. Any tampering with connection details causes SAS codes to mismatch, immediately alerting users.
Server-Side Compromise
No servers ever see your message content. The connection is peer-to-peer, and even if Naisho's infrastructure were compromised, attackers would gain no access to secrets.
Token Replay Attacks
Invite tokens expire after 3 minutes, limiting the window for replay attacks. Old tokens are automatically rejected with clear error messages.
What Naisho Cannot Protect Against
Endpoint Compromise
If your device or browser is compromised (malware, keyloggers, remote access), the attacker can see everything you see. Naisho's encryption happens in the browser, so it cannot protect against threats that have already compromised your endpoint.
Social Engineering
An attacker who convinces you to share tokens with them or skip SAS verification can impersonate your intended peer. Always verify the SAS code through a trusted out-of-band channel.
Physical Surveillance
Screen sharing, shoulder surfing, or cameras can expose secrets as you type them. Be aware of your physical environment when handling sensitive information.
Traffic Analysis
While message content is encrypted, metadata like connection timing, duration, and the fact that two IP addresses are communicating is visible to network observers. Naisho does not provide anonymity or hide communication patterns.
For questions or security concerns, please review the source code on GitHub.