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 to achieve:
- if the a
On Donnerstag, 15. Juni 2017 11:23:24 CEST Vanitas Vitae wrote:
> I'm not familiar with the proposal process. When thats the next step,
> I'll soon do :)
It is documented in XEP-0001, which you should at least glance over. It also
links to XEP-0143 which covers guidelines for authors and it menti
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
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.
Dave.
_
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 have
> 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 way,
clients just ne
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!) ske
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
suggestio
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
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,
>
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 hap
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
> encryptio
On 06.06.2017 17:11, Vanitas Vitae wrote:
> * Implement the security element
> o - leaves metadata in the clear
> o + more flexible and easier to implement
> o + integrates better into existing XEPs
> o implementations that do not support this can still transfer the
>
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 XEP
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 t
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 4
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:
https://mail.jabber.org/pipermail/standards
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 LibXML2-based C library, whi
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 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 elements
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
21 matches
Mail list logo