Re: [Standards] Encrypted Jingle File Transfer

[Andrey Gursky]

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 application crashes, you lose the ability to resume a
  transfer.
- if the OS session (e.g. DE, X-Server) crashes, the same.
- if the OS crashes, the same
and nasty to implement:
- if the application is restarted too often, additional file might 
be

  needed?
- if the application is restarted too rarely, additional events 
must

  be issued for cleanup?


I get your points here. But is it really that big of a deal? I mean how
often does the X-server/OS session crash?


Well, if you're on the bleeding edge of the XMPP development, it doesn't 
mean, that you're not also on experimental versions of other components 
:) which could lead to loosing access to the running XMPP client.



Also the caching must only
happen on initiator side. When resuming the transfer, the initiator
can/must simply retransmit the key. I don't know, if conventional XMPP
applications are implemented in a way that allows file transfers to be
resumed across application restarts, so you might have a point there :)


Resuming of file transfer is trivial in general: no need to cache data, 
keys or remember something else. Just point your client to save the file 
under the same name which already exists, then the length of that file 
could be queried and transmitted to the sender. You could look how 
wget/curl work.



 2) Security
Using the same KEY/IV pair to encrypt the same data is allowed. 
But
intentionally making use of this would increase the chances to 
break

security, e.g. the file has been overwritten inbetween, thus
violating the requirement.


Note that this only happens on a per-file basis. I wouldn't consider
this much of a deal. I might be wrong of course.


If "possible reusing KEY/IV" could be easily avoided, better to avoid it 
sooner.



 Other disadvantages:

 - Not possible to use the already received part of file, which is
   useful for audio/video.
 - Unnecessary re-encryption of the whole file.
 - More processing time.
 - Higher memory / disk (cache) consumption.
 - Doesn't work for streams.


Can we maybe tackle all these points by using a stream cipher?


AES-GCM is already a one. The question is only when to append MAC, so 
that a piece could be not only decrypted but also 
authentication-verified. Just use either a fixed length of a chunk (e.g. 
8, 16, 64 KByte) or a 16 bit length field (as in TLS) and specify the 
particular length during a handshake.



 That's why I'm tending to the "chunk" approach now.

 Andrey


Jingle File Transfer does support resuming. Adding encryption is a 
wanted thing (thank you for working on it!), provided you're not 
dropping other features (that are not in contradiction to a new 
encryption feature).


Regards,
Andrey
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Encrypted Jingle File Transfer

[Vanitas Vitae]

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 not familiar with the proposal process. When thats the next step,
I'll soon do :)

Greetings Vanitasvitae
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Encrypted Jingle File Transfer

[Dave Cridland]

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.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Encrypted Jingle File Transfer

[Vanitas Vitae]

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 to
dig through the XML :)

Greetings Vanitasvitae

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Encrypted Jingle File Transfer

[Remko Tronçon]

> 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 need to decide whether to encrypt, not what. 

I do think this belongs in the OMEMO XEP (and that the OMEMO XEP needs to 
change to generic stanza encryption instead of just 'message body'), such that 
this XEP only has to focus on defining encryption of the data stream. 

Remko
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Encrypted Jingle File Transfer

[Vanitas Vitae]

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!) 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
> suggestions :)
>
> https://github.com/vanitasvitae/xeps/tree/EncJingleFileTrans
>
> Greetings Vanitasvitae
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Encrypted Jingle File Transfer

[Vanitas Vitae]

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
suggestions :)

https://github.com/vanitasvitae/xeps/tree/EncJingleFileTrans

Greetings Vanitasvitae
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Encrypted Jingle File Transfer

[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 application crashes, you lose the ability to resume a
>  transfer.
>- if the OS session (e.g. DE, X-Server) crashes, the same.
>- if the OS crashes, the same
>and nasty to implement:
>- if the application is restarted too often, additional file might be
>  needed?
>- if the application is restarted too rarely, additional events must 
>  be issued for cleanup?

I get your points here. But is it really that big of a deal? I mean how
often does the X-server/OS session crash? Also the caching must only
happen on initiator side. When resuming the transfer, the initiator
can/must simply retransmit the key. I don't know, if conventional XMPP
applications are implemented in a way that allows file transfers to be
resumed across application restarts, so you might have a point there :)

> 2) Security
>Using the same KEY/IV pair to encrypt the same data is allowed. But
>intentionally making use of this would increase the chances to break
>security, e.g. the file has been overwritten inbetween, thus
>violating the requirement.

Note that this only happens on a per-file basis. I wouldn't consider
this much of a deal. I might be wrong of course.

> Other disadvantages:
>
> - Not possible to use the already received part of file, which is
>   useful for audio/video.
> - Unnecessary re-encryption of the whole file.
> - More processing time.
> - Higher memory / disk (cache) consumption.
> - Doesn't work for streams.

Can we maybe tackle all these points by using a stream cipher?

> That's why I'm tending to the "chunk" approach now.
>
> Andrey

Vanitasvitae

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Encrypted Jingle File Transfer

[Andrey Gursky]

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,
> > then you have only some chunks of data to transfer, no files in
> > general. What happens if a transfer has been interrupted? You should be
> > able to resume it. But can you do it?
> >
> > With conventional cyphers, there is no problem: what has been received
> > can be decrypted. The size of a partial received file then can be sent
> > during session initialization. The sender should start with encryption
> > only after receiving this information.
> >
> > A problem arises once you switch to newer authenticated cyphers like
> > AES GCM. Even if the whole data is pre-encrypted (in opposite to the
> > on-the-fly encryption)
> That was my plan so far. Pre-encrypt the data makes file transfer much
> easier (same is false for streams unfortunatelly).
> > and thus it is possible to obtain the
> > authentication block, which could be sent in advance. Still it
> > shouldn't be possible to decrypt the partially received data, because
> > it is not possible to verify the authentication partially [*]. 
> That is true.
> > Thus the
> > only way I see is to encrypt data chunks separately. 
> I don't see why this is necessary for file encryption. When the
> transmission fails, the receiver can simply ask for another attempt the
> transmit the encrypted data from offset n.
> A precondition would be that either the sender keeps the key/encrypted
> file, or the receiver sends back the key on re-initiation (Its generally
> a nice idea to let the initiator deliver the key). Since the encrypted
> data is then the same as in the previous transfer, the transmission can
> continue from the point where it stopped or am I completely missing
> something? :)

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 resume a
 transfer.
   - if the OS session (e.g. DE, X-Server) crashes, the same.
   - if the OS crashes, the same
   and nasty to implement:
   - if the application is restarted too often, additional file might be
 needed?
   - if the application is restarted too rarely, additional events must 
 be issued for cleanup?

2) Security
   Using the same KEY/IV pair to encrypt the same data is allowed. But
   intentionally making use of this would increase the chances to break
   security, e.g. the file has been overwritten inbetween, thus
   violating the requirement.

Other disadvantages:

- Not possible to use the already received part of file, which is
  useful for audio/video.
- Unnecessary re-encryption of the whole file.
- More processing time.
- Higher memory / disk (cache) consumption.
- Doesn't work for streams.

That's why I'm tending to the "chunk" approach now.

Andrey
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Encrypted Jingle File Transfer

[Vanitas Vitae]

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 happens if a transfer has been interrupted? You should be
> able to resume it. But can you do it?
>
> With conventional cyphers, there is no problem: what has been received
> can be decrypted. The size of a partial received file then can be sent
> during session initialization. The sender should start with encryption
> only after receiving this information.
>
> A problem arises once you switch to newer authenticated cyphers like
> AES GCM. Even if the whole data is pre-encrypted (in opposite to the
> on-the-fly encryption)
That was my plan so far. Pre-encrypt the data makes file transfer much
easier (same is false for streams unfortunatelly).
> and thus it is possible to obtain the
> authentication block, which could be sent in advance. Still it
> shouldn't be possible to decrypt the partially received data, because
> it is not possible to verify the authentication partially [*]. 
That is true.
> Thus the
> only way I see is to encrypt data chunks separately. 
I don't see why this is necessary for file encryption. When the
transmission fails, the receiver can simply ask for another attempt the
transmit the encrypted data from offset n.
A precondition would be that either the sender keeps the key/encrypted
file, or the receiver sends back the key on re-initiation (Its generally
a nice idea to let the initiator deliver the key). Since the encrypted
data is then the same as in the previous transfer, the transmission can
continue from the point where it stopped or am I completely missing
something? :)

Vanitasvitae

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Encrypted Jingle File Transfer

[Andrey Gursky]

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
> encryption scheme of their choice (OMEMO, OpenPGP, OTR...).
> 
> Some nice-to-have properties I can think of are:
> 
>  1. authenticity and integrity (recipient must be sure, the content was
> sent by the sender and has not been tampered with)
>  2. All known transport methods can be used
>  3. no leaking of metadata about the file (filename, size, extension,
> type, hash etc.)
> 
> First of all I have to point out that I'm pretty new to the XMPP
> community, so there are most definitely things I forgot/did not think of :)
> I threw together a naive first approach to solve the problem and
> sketched it out as session-initiate jingle elements.
> The main idea is, that the session-initiate stanza contains an AES key
> used to decrypt the file that will be sent during the session.
> This key is - along with metadata about the file - encrypted using the
> encryption method of choice. The recipient would decrypt the key and
> information, than the user would accept the transfer and later use the
> key to decrypt the file.

[ 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 happens if a transfer has been interrupted? You should be
able to resume it. But can you do it?

With conventional cyphers, there is no problem: what has been received
can be decrypted. The size of a partial received file then can be sent
during session initialization. The sender should start with encryption
only after receiving this information.

A problem arises once you switch to newer authenticated cyphers like
AES GCM. Even if the whole data is pre-encrypted (in opposite to the
on-the-fly encryption) and thus it is possible to obtain the
authentication block, which could be sent in advance. Still it
shouldn't be possible to decrypt the partially received data, because
it is not possible to verify the authentication partially [*]. Thus the
only way I see is to encrypt data chunks separately. Say for every 64
KB, which is a conventional size for file I/O operations buffer. While
it is not necessary to use a new KEY for every new data chunk, it seems
it is unavoidable to use a new IV [1]. An agreement can be made, that
consecutive IVs are not random, but incremented. This could be even
considered as an advantage, since this will guarantee, that for a
particular KEY, there will be no same IV, which would be fatal. And for
one KEY the total amount of data that can be encrypted is big enough.

Regards,
Andrey


[*] Would be nice to obtain the current value of the authentication
block and send it with every data chunk, but who knows, whether it
wouldn't break the security [1].
[1] https://bouncycastle.org/devmailarchive/msg14988.html
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Encrypted Jingle File Transfer

[Vanitas Vitae]

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 XEPs
  o implementations that do not support this can still transfer the
(encrypted) file/stream (not sure, if this is positive/negative)
  * Transport metadata and key serialized/xmlenc encrypted
  o + hides metadata
  o - not trivial to do
  o - more likely to require addon-XEPs

While the second solution is more preferable from a privacy standpoint,
I'm thinking of going the first route first and maybe later tackle the
second way.


Am 06.06.2017 um 16:36 schrieb Goffi:
> I would like that we avoid something tied to File Transfert, so we can
> use
> encryption with any application (or transport), and for this we need
> to have encryption layer between application and transport.

I thought about it and in theory the "partial-stanza-encryption" method
should also be applicable on other applications like voice/video. This
requires some more thought though...

Vanitasvitae
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Encrypted Jingle File Transfer

[Goffi]

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 time right now), but may I suggest that you have a 
look a security preconditions (https://xmpp.org/extensions/
xep-0166.html#preconditions) which is exactly there for encryption.

I would like that we avoid something tied to File Transfert, so we can use 
encryption with any application (or transport), and for this we need to have 
encryption layer between application and transport.

Please keep us up to date on this list, I would follow your work.

Thanks and good luck
Goffi
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Encrypted Jingle File Transfer

[Dave Cridland]

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 Jun 2017 16:47, "Fabian Beutel"  wrote:

> 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/2016-October/031475.html
> https://mail.jabber.org/pipermail/standards/2016-September/031440.html
>
>
> Basically, I would love to see a specification which describes how to
> transparently encrypt arbitrary stanzas (or parts of stanzas).
> This should be kept in a separate XEP from encrypted
> Jingle-Filetransfer, however, the latter could then refer to the
> stanza-encryption-XEP for not leaking meta data etc.
>
> Best regards,
> Fabian
>
>
> On 04.06.2017 15:31, Remko Tronçon wrote:
> > 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.
> >
> > For example, if you want to encrypt the entire  metadata:
> >
> > 
> >   
> > 
> >   BASE64ENCODED...
> >   BASE64ENCODED...
> >   ...
> > 
> >   
> >>action='session-initiate'
> >initiator='romeo@montague.example/dr4hcr0st3lup4c'
> >sid='851ba2'>
> >   
> > 
> >   
> >   http://www.w3.org/2001/04/xmlenc#;
> > Type="http://www.w3.org/2001/04/xmlenc#Element;>
> >  > Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
> > http://www.w3.org/2000/09/xmldsig#;>
> >   omemo
> > 
> > 
> >
> > /7VSyS4tbcfsq7JYhZRgQE8bNkiyUJKi68FdmdoA2PIRjGumbfI35X2om/
> 4mbfHteCAEBATpsr/l/HvQf7GERGtvmuupNFh7reGeSWl8waj
> wwYyfQi9BM6MfjZKi8D9Q94FhWz2p0LMVEjduI9svzKOf/
> uLI3JolK39nH70ezvyYebybpasDxC51SypmVU1p
> > 
> >   
> > 
> >   
> >   
> > 
> >
> > Or, if you just want to encrypt only parts of the  (e.g. not the
> hash)
> >
> > 
> >   
> > 
> >   BASE64ENCODED...
> >   BASE64ENCODED...
> >   ...
> > 
> >   
> >>action='session-initiate'
> >initiator='romeo@montague.example/dr4hcr0st3lup4c'
> >sid='851ba2'>
> >   
> > 
> >   
> >  > algo='sha-1'>w0mcJylzCn+AfvuGdqkty2+KP48=
> >
> > 
> > http://www.w3.org/2001/04/xmlenc#;
> > Type="http://www.w3.org/2001/04/xmlenc#Content;>
> >> Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
> >   http://www.w3.org/2000/09/xmldsig#;>
> > omemo
> >   
> >   
> >
> > /7VSyS4tbcfsq7JYhZRgQE8bNkiyUJKi68FdmdoA2PIRjGumbfI35X2om/
> 4mbfHteCAEBATpsr/l/HvQf7GERGtvmuupNFh7reGeSWl8waj
> wwYyfQi9BM6MfjZKi8D9Q94FhWz2p0LMVEjduI9svzKOf/
> uLI3JolK39nH70ezvyYebybpasDxC51SypmVU1p
> >   
> > 
> >   
> > 
> >   
> >   
> > 
> >
> > KeyInfo could be used to distinguish where the key material is coming
> > from for encryption (e.g. OMEMO element at the top of the IQ).
> >
> > I'm not saying xmlenc is very elegant, and it's very broad, but it has
> > the advantage that you may get an implementation for free in your
> > language? It might need some restricting of possible algorithms/keys/...
> > for clients that need to implement this themselves if they don't have
> > xmlenc available.
> >
> > Remko
> >
> >
> > ___
> > Standards mailing list
> > Info: https://mail.jabber.org/mailman/listinfo/standards
> > Unsubscribe: standards-unsubscr...@xmpp.org
> > ___
> >
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Encrypted Jingle File Transfer

[Fabian Beutel]

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/2016-October/031475.html
https://mail.jabber.org/pipermail/standards/2016-September/031440.html


Basically, I would love to see a specification which describes how to
transparently encrypt arbitrary stanzas (or parts of stanzas).
This should be kept in a separate XEP from encrypted
Jingle-Filetransfer, however, the latter could then refer to the
stanza-encryption-XEP for not leaking meta data etc.

Best regards,
Fabian


On 04.06.2017 15:31, Remko Tronçon wrote:
> 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. 
> 
> For example, if you want to encrypt the entire  metadata:
> 
> 
>   
> 
>   BASE64ENCODED...
>   BASE64ENCODED...
>   ...
> 
>   
>   action='session-initiate'
>initiator='romeo@montague.example/dr4hcr0st3lup4c'
>sid='851ba2'>
>   
> 
>   
>   http://www.w3.org/2001/04/xmlenc#;
> Type="http://www.w3.org/2001/04/xmlenc#Element;>
>  Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
> http://www.w3.org/2000/09/xmldsig#;>
>   omemo
> 
> 
>  
> /7VSyS4tbcfsq7JYhZRgQE8bNkiyUJKi68FdmdoA2PIRjGumbfI35X2om/4mbfHteCAEBATpsr/l/HvQf7GERGtvmuupNFh7reGeSWl8wajwwYyfQi9BM6MfjZKi8D9Q94FhWz2p0LMVEjduI9svzKOf/uLI3JolK39nH70ezvyYebybpasDxC51SypmVU1p
> 
>
> 
>   
>   
> 
> 
> Or, if you just want to encrypt only parts of the  (e.g. not the hash)
> 
> 
>   
> 
>   BASE64ENCODED...
>   BASE64ENCODED...
>   ...
> 
>   
>   action='session-initiate'
>initiator='romeo@montague.example/dr4hcr0st3lup4c'
>sid='851ba2'>
>   
> 
>   
>  algo='sha-1'>w0mcJylzCn+AfvuGdqkty2+KP48=
> 
> 
> http://www.w3.org/2001/04/xmlenc#;
> Type="http://www.w3.org/2001/04/xmlenc#Content;>
>Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
>   http://www.w3.org/2000/09/xmldsig#;>
> omemo
>   
>   
>   
> /7VSyS4tbcfsq7JYhZRgQE8bNkiyUJKi68FdmdoA2PIRjGumbfI35X2om/4mbfHteCAEBATpsr/l/HvQf7GERGtvmuupNFh7reGeSWl8wajwwYyfQi9BM6MfjZKi8D9Q94FhWz2p0LMVEjduI9svzKOf/uLI3JolK39nH70ezvyYebybpasDxC51SypmVU1p
>   
>  
>   
> 
>   
>   
> 
> 
> KeyInfo could be used to distinguish where the key material is coming
> from for encryption (e.g. OMEMO element at the top of the IQ).
> 
> I'm not saying xmlenc is very elegant, and it's very broad, but it has
> the advantage that you may get an implementation for free in your
> language? It might need some restricting of possible algorithms/keys/...
> for clients that need to implement this themselves if they don't have
> xmlenc available.
> 
> Remko
> 
> 
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
> 

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Encrypted Jingle File Transfer

[Remko Tronçon]

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, which has bindings
in many languages:

   https://www.aleksey.com/xmlsec/

I used that to play around with xmlsec recently.

Remko



>
> Am 04.06.2017 um 15:31 schrieb Remko Tronçon:
>
> 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.
>
> For example, if you want to encrypt the entire  metadata:
>
> 
>   
> 
>   BASE64ENCODED...
>   BASE64ENCODED...
>   ...
> 
>   
>   action='session-initiate'
>initiator='romeo@montague.example/dr4hcr0st3lup4c'
>sid='851ba2'>
>   
> 
>   
>   http://www.w3.org/2001/04/xmlenc#; Type="
> http://www.w3.org/2001/04/xmlenc#Element;>
> http://www.w3.org/
> 2001/04/xmlenc#aes256-cbc"/>
> http://www.w3.org/2000/09/xmldsig#;>
>   omemo
> 
> 
>   /7VSyS4tbcfsq7JYhZRgQE8bNkiyUJK
> i68FdmdoA2PIRjGumbfI35X2om/4mbfHteCAEBATpsr/l/
> HvQf7GERGtvmuupNFh7reGeSWl8wajwwYyfQi9BM6MfjZKi8D9Q94FhWz2p0
> LMVEjduI9svzKOf/uLI3JolK39nH70ezvyYebybpasDxC51SypmVU1p
> 
>   
> 
>   
>   
> 
>
> Or, if you just want to encrypt only parts of the  (e.g. not the
> hash)
>
> 
>   
> 
>   BASE64ENCODED...
>   BASE64ENCODED...
>   ...
> 
>   
>   action='session-initiate'
>initiator='romeo@montague.example/dr4hcr0st3lup4c'
>sid='851ba2'>
>   
> 
>   
> w0mcJylzCn+
> AfvuGdqkty2+KP48=
>
> 
> http://www.w3.org/2001/04/xmlenc#; Type="
> http://www.w3.org/2001/04/xmlenc#Content;>
>   http://www.w3.org/
> 2001/04/xmlenc#aes256-cbc"/>
>   http://www.w3.org/2000/09/xmldsig#;>
> omemo
>   
>   
>
> /7VSyS4tbcfsq7JYhZRgQE8bNkiyUJKi68FdmdoA2PIRjGumbfI35X2om/
> 4mbfHteCAEBATpsr/l/HvQf7GERGtvmuupNFh7reGeSWl8waj
> wwYyfQi9BM6MfjZKi8D9Q94FhWz2p0LMVEjduI9svzKOf/
> uLI3JolK39nH70ezvyYebybpasDxC51SypmVU1p
>   
> 
>   
> 
>   
>   
> 
>
> KeyInfo could be used to distinguish where the key material is coming from
> for encryption (e.g. OMEMO element at the top of the IQ).
>
> I'm not saying xmlenc is very elegant, and it's very broad, but it has the
> advantage that you may get an implementation for free in your language? It
> might need some restricting of possible algorithms/keys/... for clients
> that need to implement this themselves if they don't have xmlenc available.
>
> Remko
>
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
>
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Encrypted Jingle File Transfer

[Vanitas Vitae]

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 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. 
>
> For example, if you want to encrypt the entire  metadata:
>
> 
>   
> 
>   BASE64ENCODED...
>   BASE64ENCODED...
>   ...
> 
>   
>   action='session-initiate'
>initiator='romeo@montague.example/dr4hcr0st3lup4c'
>sid='851ba2'>
>   
> 
>   
>   http://www.w3.org/2001/04/xmlenc#;
> Type="http://www.w3.org/2001/04/xmlenc#Element;>
>  Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
> http://www.w3.org/2000/09/xmldsig#;>
>   omemo
> 
> 
>  
> /7VSyS4tbcfsq7JYhZRgQE8bNkiyUJKi68FdmdoA2PIRjGumbfI35X2om/4mbfHteCAEBATpsr/l/HvQf7GERGtvmuupNFh7reGeSWl8wajwwYyfQi9BM6MfjZKi8D9Q94FhWz2p0LMVEjduI9svzKOf/uLI3JolK39nH70ezvyYebybpasDxC51SypmVU1p
> 
>
> 
>   
>   
> 
>
> Or, if you just want to encrypt only parts of the  (e.g. not the
> hash)
>
> 
>   
> 
>   BASE64ENCODED...
>   BASE64ENCODED...
>   ...
> 
>   
>   action='session-initiate'
>initiator='romeo@montague.example/dr4hcr0st3lup4c'
>sid='851ba2'>
>   
> 
>   
>  algo='sha-1'>w0mcJylzCn+AfvuGdqkty2+KP48=
>
> 
> http://www.w3.org/2001/04/xmlenc#;
> Type="http://www.w3.org/2001/04/xmlenc#Content;>
>Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
>   http://www.w3.org/2000/09/xmldsig#;>
> omemo
>   
>   
>   
> /7VSyS4tbcfsq7JYhZRgQE8bNkiyUJKi68FdmdoA2PIRjGumbfI35X2om/4mbfHteCAEBATpsr/l/HvQf7GERGtvmuupNFh7reGeSWl8wajwwYyfQi9BM6MfjZKi8D9Q94FhWz2p0LMVEjduI9svzKOf/uLI3JolK39nH70ezvyYebybpasDxC51SypmVU1p
>   
>  
>   
> 
>   
>   
> 
>
> KeyInfo could be used to distinguish where the key material is coming
> from for encryption (e.g. OMEMO element at the top of the IQ).
>
> I'm not saying xmlenc is very elegant, and it's very broad, but it has
> the advantage that you may get an implementation for free in your
> language? It might need some restricting of possible
> algorithms/keys/... for clients that need to implement this themselves
> if they don't have xmlenc available.
>
> Remko
>
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Encrypted Jingle File Transfer

[Remko Tronçon]

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.

For example, if you want to encrypt the entire  metadata:


  

  BASE64ENCODED...
  BASE64ENCODED...
  ...

  
  
  

  
  http://www.w3.org/2001/04/xmlenc#; Type="
http://www.w3.org/2001/04/xmlenc#Element;>
http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
http://www.w3.org/2000/09/xmldsig#;>
  omemo



/7VSyS4tbcfsq7JYhZRgQE8bNkiyUJKi68FdmdoA2PIRjGumbfI35X2om/4mbfHteCAEBATpsr/l/HvQf7GERGtvmuupNFh7reGeSWl8wajwwYyfQi9BM6MfjZKi8D9Q94FhWz2p0LMVEjduI9svzKOf/uLI3JolK39nH70ezvyYebybpasDxC51SypmVU1p

  

  
  


Or, if you just want to encrypt only parts of the  (e.g. not the hash)


  

  BASE64ENCODED...
  BASE64ENCODED...
  ...

  
  
  

  
w0mcJylzCn+AfvuGdqkty2+KP48=


http://www.w3.org/2001/04/xmlenc#; Type="
http://www.w3.org/2001/04/xmlenc#Content;>
  http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
  http://www.w3.org/2000/09/xmldsig#;>
omemo
  
  

/7VSyS4tbcfsq7JYhZRgQE8bNkiyUJKi68FdmdoA2PIRjGumbfI35X2om/4mbfHteCAEBATpsr/l/HvQf7GERGtvmuupNFh7reGeSWl8wajwwYyfQi9BM6MfjZKi8D9Q94FhWz2p0LMVEjduI9svzKOf/uLI3JolK39nH70ezvyYebybpasDxC51SypmVU1p
  

  

  
  


KeyInfo could be used to distinguish where the key material is coming from
for encryption (e.g. OMEMO element at the top of the IQ).

I'm not saying xmlenc is very elegant, and it's very broad, but it has the
advantage that you may get an implementation for free in your language? It
might need some restricting of possible algorithms/keys/... for clients
that need to implement this themselves if they don't have xmlenc available.

Remko
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] Encrypted Jingle File Transfer

[Vanitas Vitae]

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 I can think of are:

 1. authenticity and integrity (recipient must be sure, the content was
sent by the sender and has not been tampered with)
 2. All known transport methods can be used
 3. no leaking of metadata about the file (filename, size, extension,
type, hash etc.)

First of all I have to point out that I'm pretty new to the XMPP
community, so there are most definitely things I forgot/did not think of :)
I threw together a naive first approach to solve the problem and
sketched it out as session-initiate jingle elements.
The main idea is, that the session-initiate stanza contains an AES key
used to decrypt the file that will be sent during the session.
This key is - along with metadata about the file - encrypted using the
encryption method of choice. The recipient would decrypt the key and
information, than the user would accept the transfer and later use the
key to decrypt the file.


  ##OpenPGP##

  

  

  
  
  

  BASE64-ENCODED-ENCRYPTED-METADATA

  

 

  

 
  ##OMEMO##

  

  

  
BASE64ENCODED...
BASE64ENCODED...

BASE64ENCODED...
  
  
BASE64-ENCODED-ENCRYPTED-METADATA
  

  

  

 
 
Decrypted BASE64-ENCODED-ENCRYPTED-METADATA string is of the following form:
 
###
KEY-TYPE=AES-GCM-256\n 
  (or whatever)
FILE-KEY=BASE64-ENCODED-AES-KEY-FOR-THE-FILE\n
ADD=ADDITIONAL-PARAMETERS\n 
  (iv, salt etc.)
META=BASE64-ENCODED-XML-DESCRIPTION-ELEMENT 
  ()
###
 
 
Notes:
 - There are certainly issues with XML (Namespaces etc.) since I have no
clue what I'm doing and how to do stuff properly
 - Multiple layers of B64 -> Overhead. Better solution?
 - Crypto-XEP unusual behavior (eg. payload != body of message...)
 - Crypto MUST ensure authenticity (signatures or encrypted authtag...)

What do you think of my sketch? Please let me know about all the things
I have forgotten/not considered :)
I also created this pad to keep track of development:
https://piratenpad.de/p/Encrypted_Jingle_File_Transfer

Greetings Vanitasvitae
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___