Difference between revisions of "Tech pages/OMEMO/Quickstart"

Jump to navigation Jump to search
m
Fix another link.
m (Fix another link.)
 
(2 intermediate revisions by 2 users not shown)
Line 15: Line 15:
Every session has a fingerprint. (The identity key) Offer the user the abiltiy to decide wether to trust each fingerprint. You only send messages to trusted fingerprints where the device id is active. If there are no trusted fingerprints display a dialog offering the user to trust them. If there are new fingerprints (from new devices) offer the user to trust them. So essentially every jid-deviceid-fingerprint tuple has two values (inactive/active and undecided/trusted/untrusted)
Every session has a fingerprint. (The identity key) Offer the user the abiltiy to decide wether to trust each fingerprint. You only send messages to trusted fingerprints where the device id is active. If there are no trusted fingerprints display a dialog offering the user to trust them. If there are new fingerprints (from new devices) offer the user to trust them. So essentially every jid-deviceid-fingerprint tuple has two values (inactive/active and undecided/trusted/untrusted)


A good trust model to implement is [https://gultsch.de/trust.html|Blind Trust Before Verification (BTBV)]
A good trust model to implement is [https://gultsch.de/trust.html Blind Trust Before Verification (BTBV)]
 
===Further Reading / Background===
Some explanatory articles about the encryption behind the OMEMO protocol can be found below:
* [https://blog.jabberhead.tk/2019/04/04/shaking-hands-with-omemo-x3dh/ Shaking Hands With OMEMO - About the X3DH Handshake]
* [https://blog.jabberhead.tk/2019/04/15/closer-look-at-the-double-ratchet/ Closer Look at the Double Ratchet]
 
Some hints about possible pitfalls:
* [https://blog.jabberhead.tk/2019/12/13/pitfalls-for-omemo-implementations-part-1-inactive-devices/ Pitfalls for OMEMO Implementations - Part 1: Inactive Devices]
63

edits

Navigation menu