Hi everybody!
During the course of me researching how to implement encrypted Jingle
file transfer, I came across XEP-0300 (Use of Cryptographic Hash
Functions in XMPP) that holds a list of hash functions along with
related namespaces. The XEP is used in XEP-0234 (Jingle File Transfer)
to enable
Hi!
In my recent GSoC blog post I included a small overview of the OMEMO
discussion and available options for future development. I thought this
might help someone who did not follow the discussion the past weeks.
Note: The post contains my personal opinion :)
Hi Dave :)
Am 22.06.2017 um 00:03 schrieb Dave Cridland:
> With OX dead in the water, that leaves MIKEY-SAKKE, for the enterprise
> and (UK) government, and OMEMO, for the consumer.
>
> It's mildly annoying to have two entirely incompatible crypto
> protocols, but in fairness they're two almost
Hi Dave!
Am 15.06.2017 um 11:21 schrieb Dave Cridland:
>> Flow is kindly hosting a HTML version of my WiP proposal at
>> http://geekplace.eu/xeps/xep-jet/xep-jet.html so you no longer have to
>> dig through the XML :)
> If it's worth people looking at it, it's worth submitting it.
>
> Dave.
I'm
Hi Remko!
I also think, that PSE (partial stanza encryption) should be handled by
OMEMO or OX themselves. For now I'll just focus on encrypting the file
transfer itself.
Flow is kindly hosting a HTML version of my WiP proposal at
http://geekplace.eu/xeps/xep-jet/xep-jet.html so you no longer
Hi again!
Sorry for frequent posts. Here is a link directly to the xml document:
https://github.com/vanitasvitae/xeps/blob/EncJingleFileTrans/xep-ejft.xml
Vanitasvitae
Am 13.06.2017 um 00:37 schrieb Vanitas Vitae:
> Hi all!
>
> I have written a very basic xep-like-document which
Hi all!
I have written a very basic xep-like-document which (roughly!) sketches
out the most basic way I imagine encrypted Jingle file transfer. This is
just a very naive way of doing things and it also does not hide
metadata. Nevertheless I'd be glad to get some feedback and improvement
Hi Andrey :)
Am 12.06.2017 um 21:36 schrieb Andrey Gursky:
> I see two primary disadvantages of this approach:
>
> 1) From a programmer point of view: the KEY/IV pair must be cached for
>each file, which IMHO are harder to achieve:
>- if the application crashes, you lose the ability to
I think Tobias is currently writing a summary of the discussion
including the compromise, so lets just wait for that :)
Am 07.06.2017 um 23:15 schrieb Ignat Gavrilov:
> Before anyone (including me) gets outrageous here, I wonder what this
> compromise is exactly:
>
> a) The OMEMO-siacs is put
I agree. Its not exactly nice to deny the existing implementations the
name OMEMO, since those implementations are what gave OMEMO its
reputation, so could we please agree on the fact, that existing
implementations are OMEMO?
Am 07.06.2017 um 22:46 schrieb Ignat Gavrilov:
>> From: Kevin Smith
Hi Andrey!
Am 07.06.2017 um 20:20 schrieb Andrey Gursky:
> [ snip ]
>
> Since files are mostly too big to be transfered at once, the data is
> actually transferred in chunks. If you consider the Goffi's proposal,
> then you have only some chunks of data to transfer, no files in
> general. What
Hi Goffi!
I actually already thought about the securiy element as well. It seems
like there are two different possibilities here:
* Implement the security element
o - leaves metadata in the clear
o + more flexible and easier to implement
o + integrates better into existing
Hi Remko!
Thank you for your suggestion. I didn't knew about xmlenc, but it looks
like it is (for now) only available for java, so restricting algorithms
etc. definitely sounds like a good idea.
Am 04.06.2017 um 15:31 schrieb Remko Tronçon:
> Hi Vanitasvitae!
>
> I wonder if it would make sense
Hi!
As part of my GSoC project I'd like to think of a way to enable
end-to-end encrypted Jingle file transfer. It should be possible for
participants to exchange files encrypted by exchanging a key using the
encryption scheme of their choice (OMEMO, OpenPGP, OTR...).
Some nice-to-have properties
+1
Am 31.05.2017 um 22:16 schrieb Chris Ballinger:
> I think it's obvious at this point that making an independent
> implementation of XEdDSA is possible without relying on any GPL OWS
> code. There are only so many ways of writing extremely concise code
> (see the rangeCheck function in Oracle
Am 25.05.2017 um 16:37 schrieb Remko Tronçon:
> Don't forget the other part of your mail: if it also comes with one of
> your
> 2 other proposals (split ed25519/curve25519 identity keys, or
> (widespread) permissibly
> licensed implementation of XEdDSA)
>
> Remko
>
Sure :)
signature.asc
Am 25.05.2017 um 15:49 schrieb Remko Tronçon:
>> There are concerns about the usage of XEdDSA, which could be solved by
>> either implementing the XEdDSA conversion function in a non-GPL way
> This would help, but I'll still feel very uneasy until it is available in an
> accepted crypto library.
Am 25.05.2017 um 15:25 schrieb Dave Cridland:
> Perhaps. Ed25519 and EdDSA are used (or proposed to be) in many places
> (DNSSEC, TLS, etc), so it *is* natural that it's implemented much more
> widely. But of course, that also raises the question of why XEdDSA is
> not proposed in DNSSEC, TLS,
Hi!
Am 25.05.2017 um 10:47 schrieb Dave Cridland:
> Rightly or wrongly, there are other benefits of using Olm, such as
> interoperability with Matrix, the availability of existing low and
> high level libraries, etc.
Correct me if I'm wrong, but there is still no java implementation, right?
Hi Andy!
Thank you for your statement.
I think it's important to stress, that your proposed "ODR" is a good
compromise between using libsignal and using Olm, since it enables both
libraries to be used (with some modifications). This is way better than
changing the whole base library, since you
Am 19.05.2017 um 15:02 schrieb Germán Márquez Mejía:
> BTW I just submitted my bachelor thesis on this topic:
>
> https://userpage.fu-berlin.de/mancho/OMEMO.pdf (in German)
Just for completion, here is mine (also OMEMO, also German) :)
> I look forward to reading the discussion on this list...
Sure ;)
My goal is to create a XEP for encrypted Jingle file transfer (probably
OMEMO as well as other crypto).
Since I'm pretty much a noob when it comes to writing XEPs, the mailing
list is probably the best place to get feedback :)
Am 31.03.2017 um 11:21 schrieb Vanitas Vitae:
>
> Am 31.03.2017 um 11:04 schrieb Remko Tronçon:
>> 1. We go back to Olm's protocol of establishing an initial shared
>> secret, using regular 3DH instead of X3DH.
>>
>> + Moves us back to an audited, implementa
Am 31.03.2017 um 11:04 schrieb Remko Tronçon:
> 1. We go back to Olm's protocol of establishing an initial shared
> secret, using regular 3DH instead of X3DH.
>
> + Moves us back to an audited, implementable algorithm
> + No need to change existing identity keys
> - This weakens the
Am 20.02.2017 um 07:50 schrieb Jonas Wielicki:
> > Possible problem: What happens when an attacker distrusts all your
> > devices or creates paradox trust decisions?
>
> Hold on, what kind of attacker? Please state an attacker model here:
> what can
> the attacker do, where does it sit in the
Hi!
As part of my bachelor thesis I thought about future development of the
OMEMO protocol extension (xep-0384).
Some downsides of the current OMEMO usage are:
* Whenever I add a new OMEMO device, I have to redo trust decisions for
each device of all my contacts.
* Whenever a contact adds a new
26 matches
Mail list logo
