Re: [Standards] Encrypted Jingle File Transfer

Hi Paul, 12.06.2017, 22:04, "Vanitas Vitae" : 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

Re: [Standards] Encrypted Jingle File Transfer

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

Re: [Standards] Encrypted Jingle File Transfer

On 15 June 2017 at 09:16, Vanitas Vitae wrote: > 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.

Re: [Standards] Encrypted Jingle File Transfer

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

Re: [Standards] Encrypted Jingle File Transfer

> On 6 Jun 2017, at 13:02, Dave Cridland wrote: > > it might well be worth looking at XEP-0200 for full-stanza encryption Yeah, makes sense. Something like xmlenc gives you precise control over which parts you encrypt, but we probably don't need (or even want) that. This

Re: [Standards] Encrypted Jingle File Transfer

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 (roughly!)

Re: [Standards] Encrypted Jingle File Transfer

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

Re: [Standards] Encrypted Jingle File Transfer

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

Re: [Standards] Encrypted Jingle File Transfer

Hi Vanitas, On Wed, 7 Jun 2017 20:30:48 +0200 Vanitas Vitae wrote: > 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, >

Re: [Standards] Encrypted Jingle File Transfer

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

Re: [Standards] Encrypted Jingle File Transfer

Hi Vanitas, On Sun, 4 Jun 2017 15:01:45 +0200 Vanitas Vitae wrote: > 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 >

Re: [Standards] Encrypted Jingle File Transfer

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

Re: [Standards] Encrypted Jingle File Transfer

Le dimanche 4 juin 2017, 15:01:45 CEST Vanitas Vitae a écrit : > Hi! > > As part of my GSoC project I'd like to think of a way to enable > end-to-end encrypted Jingle file transfer. [...] Hi, really nice to see somebody working on that. I haven't read your stuff in details yet (running out of

Re: [Standards] Encrypted Jingle File Transfer

While based on the old eSessions specification, it might well be worth looking at XEP-0200 for full-stanza encryption. ISTR it was implemented by Gajim back in the day, but I may be wrong - this specification was last updated just over a decade ago.#, and my memory really isn't *that* good... On

Re: [Standards] Encrypted Jingle File Transfer

Hey, I very much like the idea of having the option to encrypt complete stanzas! I think this could be implemented transparently and would allow all kind of jingle session meta data to be secret. I wrote about this on this list on two occasions already:

Re: [Standards] Encrypted Jingle File Transfer

On 4 June 2017 at 15:45, Vanitas Vitae wrote: > 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. > FYI, there's also XMLSec, the

Re: [Standards] Encrypted Jingle File Transfer

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

Re: [Standards] Encrypted Jingle File Transfer

Hi Vanitasvitae! I wonder if it would make sense to use something like xmlenc to have a 'generic' way to encrypt (parts of) stanzas. This way, you can decouple the encryption key info etc. from the things you want to encrypt, and you can choose to encrypt entire elements, or just parts of

[Standards] Encrypted Jingle File Transfer

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