Re: [Standards] XEP-0384 and inbox/omemo-filetransfer: Variable length of MAC

Hi all, hi Goffi, On Mon, 12 Dec 2016 10:42:14 +0100 Goffi wrote: > Hello, > > Le dimanche 11 décembre 2016, 21:40:19 CET Andrey Gursky a écrit : > > Are there any major technical issues with omemo filetransfer that you > > couldn't solve? Can't they be solved in general o

[Standards] XEP-0384: Missing definition of key signing protocol

Hi, Now that OMEMO moved from Axolotl to Olm, the explicit definition of how keys must be signed and verified should be added into the XEP. Daniel, do you plan to keep the one from Axolotl? Thanks, Andrey ___ Standards mailing list Info:

Re: [Standards] inbox/omemo-filetransfer: Not possible to resume aborted transfer

Hi all, Daniel, Goffi, On Sun, 11 Dec 2016 19:12:26 +0100 Andrey Gursky wrote: > Hi, > > > An encryption header MUST only be used for one session. However when > > doing a rangend tranfer on a previously aborted file the key/IV pair > > MUST be reused and packed i

Re: [Standards] NEW: XEP-0384 (OMEMO Encryption)

Hi, > Version 0.1 of XEP-0384 (OMEMO Encryption) has been released. Congratulations! > Abstract: This specification defines a protocol for end-to-end > encryption in one-on-one chats that may have multiple clients per > account. > > Changelog: Initial version approved by the council. (XEP

[Standards] XEP-0384 and inbox/omemo-filetransfer: Variable length of MAC

Hi, > The 16 bytes key and the GCM authentication tag (The tag SHOULD have at > least 128 bit) are concatenated and for each intended recipient > device... Once received due to the predefined length of the first field (key), the length of the tag can be calculated. Considering OMEMO

[Standards] XEP-0384: Misleading naming of KEY/IV tags

Hi, Considering "4.5 Sending a message": there is a KEY/IV pair and a KEY/IV elements, which could be easily confused. Moreover the KEY element consists of encrypted data, but IV not. What do you think about changing the naming of the KEY element to something more explicit like "ENCRYPTED_KEY"?

[Standards] XEP-0384: Using encryption for MAC but not for IV

Hi, Please consider adding the clarification of why MAC/authentication tag is being encrypted but IV is left unencrypted and not both left unencrypted or vice versa or both encrypted. Thanks, Andrey ___ Standards mailing list Info:

[Standards] inbox/omemo-filetransfer: Not possible to resume aborted transfer

Hi, > An encryption header MUST only be used for one session. However when > doing a rangend tranfer on a previously aborted file the key/IV pair > MUST be reused and packed into a new header to keep the integrity of > the file. This is a nice catch. But I have two issues with it. Once jingle

Re: [Standards] XEP-0384 and inbox/omemo-filetransfer: Variable length of MAC

Daniel, On Sun, 11 Dec 2016 19:45:47 +0100 Daniel Gultsch wrote: > On Dec 11, 2016 7:07 PM, "Andrey Gursky" <andrey.gur...@e-mail.ua> wrote: > > > Hi, > > > > > The 16 bytes key and the GCM authentication tag (The tag SHOULD have at > > > l

Re: [Standards] OMEMO and Olm

Hi, On Wed, 17 May 2017 16:59:53 +0100 Dave Cridland wrote: [ cut ] > A lengthy discussion ensued on this list, involving both Matthew > Hodgson and others who clearly know a lot more about Crypto than I do. > None of their arguments were answered. Remko supplied a PR to match > these. It seems

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

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 Paul, 12.06.2017, 22:04, "Vanitas Vitae" <vanitasvi...@riseup.net>: 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

Re: [Standards] XEP-0384 OMEMO questions

Hi Klaus, On 2017-09-18 15:27, Klaus Herberth wrote: Hi Paul, thanks for reading that lengthy email. If I understand you correctly, the complete magic happens in the key element and there is no description in the XEP or in the linked "signal protocol" which describes it. So all

Re: [Standards] Network IO best practices

Hi Daniel, On 2018-06-10 07:09, Daniel Corbe wrote: Hi, First time implementor of anything XMPP-related, much less outside of the use of a library for dealing with XMPP. The chosen language here is Go and the few XMPP libraries that exist in our world are hilariously incomplete. So I’m