moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-24 18:22:24 -05:00
Code Issues Releases Wiki Activity

improve introduction

Browse Source
This commit is contained in:
Melvin Keskin 2019-03-16 17:21:55 +01:00
parent 3076f32686
commit 4e403e5bd2
1 changed files with 17 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

30
inbox/automatic-trust-transfer.xml
View File

@ -41,28 +41,32 @@
</header> </header>
<section1 topic='Introduction' anchor='intro'> <section1 topic='Introduction' anchor='intro'>
<p> <p>
ATT is used for automatically establishing secure channels protected against active attacks between a new device and existing ones after a single mutual manual authentication between the new device and one of the existing ones. ATT is used in conjunction with &xep0384; for automatically establishing secure channels protected against active attacks between a new device and existing ones after a single mutual manual authentication between the new device and one of the existing ones.
It preserves the security level as if all devices had authenticated their keys manually. It preserves the security level as if all devices had authenticated their keys manually.
A trusted third party is not required since a usual OMEMO message is used for transferring the information needed to authenticate a key or revoke the trust in that key. A trusted third party is not required since an ordinary OMEMO message is used for transferring the information needed to authenticate a public identity key or revoke the trust in that key.
Additionally, it preserves the anonymity of the authentication and revocation since those messages are only sent to devices with authenticated keys. Additionally, it preserves the anonymity of the authentication and revocation since those messages are only sent to devices with authenticated public identity keys.
That means an attacker cannot detect whether an authentication or revocation took place. That means an attacker cannot detect whether an authentication or revocation took place.
</p> </p>
<p> <p>
End-to-end encryption without verifying the authenticity of the keys enables users to protect their communication against passive attacks. End-to-end encryption without verifying the authenticity of the exchanged public identity keys only enables users to protect their communication against passive attacks.
This means an attacker cannot read the transferred messages without manipulating the exchanged keys. This means an attacker cannot read encrypted messages in transit without actively intervening in the key exchange.
But without any other precautions active attacks are still possible. However, without any other precautions active attacks are still possible.
If an attacker replaces the exchanged keys with a malicious key, the end-to-end encrypted messages can be read and manipulated by the attacker. If an attacker replaces the exchanged keys with malicious ones, the end-to-end encrypted messages can be read and manipulated by the attacker.
</p> </p>
<p> <p>
When using &xep0384;, a public identity key is transmitted over a channel which is not protected against active attacks. When using OMEMO, a public identity key is transmitted over a channel which is not protected against active attacks.
That key has to be authenticated by the receiving device over a channel which is protected against active attacks to maintain the confidentiality of sent OMEMO messages and ensuring the authenticity and integrity of received OMEMO messages. That key has to be authenticated by the receiving device over a channel which is protected against active attacks to maintain the confidentiality of sent OMEMO messages and ensuring the authenticity and integrity of received OMEMO messages.
</p> </p>
<p> <p>
When using OMEMO, each device has a different identity key. When using OMEMO, each device has a unique identity key.
That makes it possible for new devices to use end-to-end encryption protecting against passive attacks without transmitting the private key over a secure channel from an existing device to the new one. For that reason it is not necessary to copy an existing private identity key to a new device enabling it to use end-to-end encryption.
However, the downside of this approach is that it increases the number of authentications. Additionally, it can be used to stop encrypting for a specific device.
Without ATT all authentications have to be done manually. For example, that could be done automatically after a given number of sent messages without any reaction from the receiving device that would forward the double ratchet to ensure forward and backward secrecy.
With ATT though, only one mutal manual authentication per new key is required. </p>
<p>
However, the downside of that approach is that it increases the number of key authentications users need to do for each new device to be protected against active attacks.
Without ATT all n-1 mutual authentications per new key have to be done manually.
With ATT though, only one mutual manual authentication per new key is required.
</p> </p>
</section1> </section1>
<section1 topic='Glossary' anchor='glossary'> <section1 topic='Glossary' anchor='glossary'>