pep/blog.bouah.net
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Reword parts about omemo lib/MIT, and device keys

Browse source 
Signed-off-by: Maxime “pep” Buquet <pep@bouah.net>
This commit is contained in:
Maxime “pep” Buquet 2019-02-25 13:20:12 +00:00
parent 8d75a9962e
commit 7b333d7df5
1 changed files with 5 additions and 7 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

12
content/posts/slixmpp-omemo-release.md
View file

@ -50,18 +50,16 @@ The [python-omemo] library that is used -- developed by Syndace -- is a complete
reimplementation of the Signal Protocol unlike [python-axolotl], which is a reimplementation of the Signal Protocol unlike [python-axolotl], which is a
port of the original library implemented in Signal. port of the original library implemented in Signal.
The only bits that prevent him for releasing his library under MIT is the There are bits that prevent him from releasing his library under MIT at the
wireformat, that has to be the same as the original implementation as moment, I am not entirely sure to grasp all the details but this is being
specified in [XEP-0384][OMEMO]. Providing that we define another wireformat worked on.
for all OMEMO implementations to use, this restriction will go away (still
easier said than done.)
[python-axolotl]: https://pypi.org/project/python-axolotl/ [python-axolotl]: https://pypi.org/project/python-axolotl/
## Why OMEMO? ## Why OMEMO?
There is still lots of things to be improved in the OMEMO specification. There are still lots of things to be improved in the OMEMO specification.
I would personally like to see what is usually called _Full Stanza Encryption_ I would personally like to see what is usually called _Full Stanza Encryption_
added to the spec. Today, an OMEMO implementation will only encrypt the added to the spec. Today, an OMEMO implementation will only encrypt the
@ -71,7 +69,7 @@ disable them, for privacy-conscious implementations.
I would also like to drop _Forward Secrecy_, in the context of Instant I would also like to drop _Forward Secrecy_, in the context of Instant
Messaging. And I would like to have a better way to manage all these device Messaging. And I would like to have a better way to manage all these device
keys, and I know there are people working on this already. keys, fortunately there are people working on this already.
Not having all these options (or having them, in the case of _Forward Not having all these options (or having them, in the case of _Forward
Secrecy_) heavily degrades user experience in my opinion, and that is my main Secrecy_) heavily degrades user experience in my opinion, and that is my main