[Standards] Ciphers-XEP?

[Vanitas Vitae]

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 the use of different hash functions.

Does such a thing exist for (symmetric) ciphers? If not, why not? It
would make it much easier to replace outdated ciphers where they might
be used. In my case such a XEP would be especially useful, since it
would enable me to achieve "jingle-like" agility for ciphers.

Let me know what you think :)

Vanitasvitae



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

Re: [Standards] OMEMO Discussion Summary 2017

[Vanitas Vitae]

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

https://blogs.fsfe.org/vanitasvitae/2017/06/28/fourth-week-of-gsoc-and-omemo-thoughts/




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

Re: [Standards] OMEMO Discussion Summary 2017

[Vanitas Vitae]

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 entirely incompatible
> markets.

In my opinion it is dangerous to try to make MIKEY-SAKKE and OMEMO
compatible to one another/unite them.

If I remember correctly, MIKEY-SAKKE has "master-key" capabilities
(which might of course be a valid use case for enterprises) allowing a
third (administrative) party to get access to messages.

We should not try to work such functionality into OMEMO, because once
OMEMO has such a feature, it'll be only a matter of time untill the next
"anti-terror" law demands that feature to be activated for everyone by
default. So as annoying as it is to have two competing standards, I
think it is the way to go.

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 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

[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

[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] Don't let today be the day we bury OMEMO

[Vanitas Vitae]

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 into the/a XEP and all future standardizing work is 
> put into OMEMO-NEXT (not using XEdDSA) which will then become the next 
> version of the XEP (maybe in years). There won't be any work or updates on 
> XEdDSA-based OMEMO.
> b) The OMEMO-siacs is put into the/a XEP and both protocols are developed 
> independently (learning from each other), keeping the XEdDSA-based OMEMO 
> alife for some time, including changes like ODR and at some point (maybe in 
> years) move over to OMEMO-NEXT.
> c) The OMEMO-siacs is put into the/a XEP and both protocols are developed 
> independently (learning from each other), keeping the XEdDSA-based OMEMO 
> alife for some time, including changes like ODR and nobody cares about 
> OMEMO-NEXT
>
> I don't care about which XEP number exactly is used for what. Seriously XEP 
> numbers are for developers and not for users and if we want XMPP to survive 
> we have to put the effort into the users, so the majority of XMPP developers 
> should not care about which XEP has which number, as long as it supports the 
> protocols used by the users, right?
>
> Ignat.
>
>
>> 
>> From: Kevin Smith 
>> Sent: Wed Jun 07 22:57:16 CEST 2017
>> To: XMPP Standards 
>> Subject: Re: [Standards] Don't let today be the day we bury OMEMO
>>
>> I think that’s what the compromise proposal achieves, yes.
>>
> ___
> 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] Don't let today be the day we bury OMEMO

[Vanitas Vitae]

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 
>> I can understand that argument, but I think a lot of people want to have the 
>> currently deployed thing-that-isn’t-OMEMO (OMEMO-siacs) in XEP-0384. I’d 
>> rather it was documented in a different XEP too, but putting it in 384 is 
>> part of the compromise.
>>
> 1. A lot of people don't give a f*** on what is in XEP-384, those people are 
> called users and they build the large majority of the XMPP network.
> 2. I think we should adapt to the fact that the thing-that-isn’t-OMEMO is 
> what most users (again the majority) recognize as OMEMO. Maybe we should 
> start calling it OMEMO and the-thing-that-is-in-the-XEP-but-nobody-cares 
> shall be XEP-OMEMO? OMEMO did exist before it was a XEP so obviously OMEMO is 
> not solely defined by what is in the XEP.
>
> Ignat.
> ___
> 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 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

[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

[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
___

[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
___

Re: [Standards] OMEMO Key Agreement

[Vanitas Vitae]

+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 v Google), so some similarities
> are inevitable. Obviously translating code line-by-line is a
> derivative work, but if you're implementing a crypto specification,
> there are only so many ways to do a low level crypto operation without
> jumping through hoops to look like you aren't copying some existing
> code. 
>
> This is all so ridiculous. If I arrange funding for a permissive
> XEdDSA implementation and audit can we stop making personal attacks
> and move on from this nonsense? 
>
> On Wed, May 31, 2017 at 12:59 PM, Dave Cridland  > wrote:
>
> On 31 May 2017 at 20:50, Sam Whited  > wrote:
> > On Wed, May 31, 2017 at 2:35 PM, Dave Cridland
> > wrote:
> >> I call bullshit.
> >>
> >> He copy and pasted some code (and the comments!).
> >>
> >> The fact he did this then submitted it to another project without
> >> attribution and flouting the licensing is actually besides the
> point -
> >> I have no idea in what parallel universe you can say that because
> >> someone can copy and paste the code from one file to another this
> >> means the spec is fine and anyone could knock out an
> implementation.
> >
> > Anyone with an Ed25519 library can already create an implementation,
> > as I've explained, none of that code is owed by OWS, it's all either
> > from the public domain reference implementation, or it's simple math
> > that many other libraries implement. If you're worried about
> copying a
> > handful of
> > lines from signal, go copy them from any other ed25519
> > implementation.
>
> I really appreciate you trying to explain which parallel universe I
> might have found myself in.
>
> But you did copy, amongst possibly other things, a constant-time
> conditional-swap routine, along with the comments, from the
> "additional" directory of a GPL library, so I can only assume that
> copyright law works an entirely different way in this parallel
> universe. Is it like patents in my universe, where a defence is that
> the invention is obvious to one skilled in the art? We don't have that
> defence for copyright in my universe.
>
> But your argument that XEdDSA is simple enough for anyone to implement
> by copying other people's code is noted.
>
> Dave.
> ___
> 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] OMEMO and Olm

[Vanitas Vitae]

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

Re: [Standards] OMEMO and Olm

[Vanitas Vitae]

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. 
>
> Other than that, I agree with your summary. 
>
>
>> Either way, are there any other points speaking against Andys PR?
> Yes: the wire format isn't specified (how is chain length etc. authenticated)

So if that last part is resolved (which shouldn't be a big deal), then
Andys PR would be an accpetable compromise for everyone, am I right?
Its nice to see some progress in that case :)

Vanitasvitae



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

Re: [Standards] OMEMO and Olm

[Vanitas Vitae]

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, and so on. I suspect it's just fashion,
> but it'd make me a lot happier to be using crypto primitives that
> everyone else was, too, nonetheless.
>
> Dave.

So to summarize the current state of the discussion:

There are concerns about the usage of XEdDSA, which could be solved by
either implementing the XEdDSA conversion function in a non-GPL way
(which could also then be used in Olm), or by using two seperate keys
instead of just one. Afaik Andys PR does not cover the later option
right now, but I guess that could be easily added.

Either way, are there any other points speaking against Andys PR? I have
the feeling, that XEdDSA is the only real blocker right now (again,
which can be solved).

Vanitasvitae



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

Re: [Standards] OMEMO and Olm

[Vanitas Vitae]

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?

Vanitasvitae



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

Re: [Standards] OMEMO and Olm

[Vanitas Vitae]

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 can just fork libsignal and
olm and make the required changes. Clients can then use those libraries
without having to reinvent the wheel.

Also I aggree that it is quite important to have the XEP updated so that
there is less confusion about it using Olm.

Vanitasvitae


Am 24.05.2017 um 22:55 schrieb Andreas Straub:
> Hey all,
>
> it has been brought to my attention that my recent silence on this
> matter is being perceived as "unresponsiveness", so I guess I should
> clear up a few things.
>
> I haven't commented on this issue in a while because I don't feel I
> have anything significant to add at this point. Most of the arguments
> have been made (by me and others) months ago, and nothing significant
> has changed. I generally try to refrain from repeating things others
> have already said, especially on mailing lists, and I guess I just
> wasn't aware that that's exactly what the XSF process required me to
> do in this case. Sorry about that. So let me try to sum up where we
> stand right now.
>
> First, for a bit of additional background, I suppose I should clear up
> the misconception that (under my proposed changes) OMEMO would be
> "moving away from OLM". As far as I'm concerned, OMEMO wasn't ever
> actually on OLM. Due to the poor standardization of signal-protocol at
> the time, we changed the spec to using OLM, but this was never
> actually implemented. There were plans to switch over, but before
> anyone got around to putting in the (not insignificant amount of)
> work, the standardization issues with signal-protocol resolved
> themselves (in particular, the whole "any implementation would be a
> derivative of ours and hence bound by the GPL" thing isn't true
> anymore, as there is a complete spec that's placed in the public
> domain). So as far as we were aware at the time, the singular
> roadblock that prevented us from standardizing on signal-protocol back
> in the day was gone, and there was no longer a strong argument for
> proceeding with this changeover, which would've meant a lot of effort
> for existing implementations at basically no concrete benefit.
>
> Hence, the main impetus driving me to work up a new revision was to
> *move the spec back in line with the real world*, not some kind of
> "political" move or anything of the sort as has been insinuated on
> this list. We've had an increasing number of developers interested in
> implementing OMEMO for different clients, and it's really dumb to have
> to tell everybody to ignore what the standard (that you yourself
> wrote) says.
>
> So what I care about is resolving this situation in a way that
> actually helps people. I want people to be able to implement this
> protocol without reading others' code or asking around which parts of
> a spec to ignore and which ones to follow. Staying in this limbo, as
> was suggested on this list at some point ("it's experimental, you can
> just stay on your private namespace for now") is in my opinion
> antithetical to the whole idea of even having a standard in the first
> place.
>
> As far as I can tell, switching to OLM does not help anyone. I am not
> aware of any individual, organization, or company that is interested
> in implementing OMEMO but *can't* due to licensing issues. The
> original criticism of lacking specification is resolved. The spec is
> public domain, and it contains everything you need to roll your own
> library. But apparently, the goalposts have moved, and we now also
> require a permissively licensed implementation.
>
> Yes, it's true that there's currently no such thing for XEdDSA, but is
> this actually a concrete problem for anyone? As far as I'm aware, this
> has always been a purely hypothetical debate. If I'm wrong here,
> please speak up! In any case, when it comes down to it, implementing
> this yourself really isn't that complex. You can re-use existing EdDSA
> code, all you need to do is write the key conversion code yourself,
> for which there is pseudo-code in the standard, which maps fairly
> directly to well-known mathematical primitives, for which you can also
> re-use existing code. The main novel idea in XEdDSA is resolving an
> ambiguity in the conversion by forcing a sign bit to 0, and that's
> about it. Your code doesn't have to be constant-time and if you do it
> wrong, the signature just won't verify. I agree that it's never ideal
> to have to do stuff like this yourself, but this also isn't quite as
> "playing with fire" as some folks are making it out to be. In any
> case, I really doubt that this is the one big thing that would hinder
> such hypothetical implementors from adopting OMEMO.
>
> To make a long story short, I remain unconvinced that switching to 

Re: [Standards] OMEMO and Olm

[Vanitas Vitae]

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) :)
https://github.com/vanitasvitae/vanitasvitae.github.io/raw/master/bachelorthesis.pdf



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

Re: [Standards] OMEMO and Olm

[Vanitas Vitae]

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

Vanitasvitae



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

Re: [Standards] OMEMO (XEP-0384) use of X3DH / XEdDSA

[Vanitas Vitae]

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, implementable algorithm
>> + No need to change existing identity keys
>> - This weakens the forward secrecy. I don't know enough about it
>> to understand the consequence.
> This requires huge changes in all OMEMO implementations, and there are
> quite few already: https://omemo.top
> Also, weakening crypto is not an idea I can become friends with :(
Also if I'm correct, there is no Olm library for java at the moment, so
again there is a missing implementation.


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

Re: [Standards] OMEMO (XEP-0384) use of X3DH / XEdDSA

[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, implementable algorithm
> + No need to change existing identity keys
> - This weakens the forward secrecy. I don't know enough about it
> to understand the consequence.
This requires huge changes in all OMEMO implementations, and there are
quite few already: https://omemo.top
Also, weakening crypto is not an idea I can become friends with :(
> 3. We stay with XEdDSA (the primitive on which X3DH relies) 
>
> + No need to change existing identity keys
> + This approach has been audited.
> - Currently, no permissible implementation exists (or I couldn't
> find one at least). It's not clear when or if this will ever happen,
> and whether it will become widespread across crypto libraries. I don't
> know how these things generally go. I have only seen an issue for this
> in the LibSodium tracker (
> https://github.com/jedisct1/libsodium/issues/335
>  )
I guess its only a matter of time until a permissive implementation
comes along. I mean, the interest in strong crypto is there and the
Signal protocol was praised by nearly every cryptographer on the planet,
so I'm expecting independent implementations of the protocol pretty soon.

Vanitasvitae


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

Re: [Standards] Some thoughts on possible OMEMO trust models

[Vanitas Vitae]

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 grand scheme of things?
>
> A server-level attacker should not be able to add trust between
> devices (only
> remove it by breaking the signatures or removing items or nodes from the
> pubsub).
>
> Likewise, a device-level attacker should not be able to add trust between
> devices other than the device it is controlling. Again, removal is
> possible
> via PubSub.
Sorry, for being unclear. What my concern is, what happens, when an
attacker with access to one device messes with the signatures.

Let's assume, You have device A and B. A trusted a lot of contacts
devices including Bobs device b. Now you have a newer device B, with
that you trusted A and by doing so, have transitive trust in devices
trusted by A (like Bobs b).

What happens, when an attacker that compromised Bobs account, gets
access to A and trusts a foreign malicious device c, which is logged in
with Bobs details, so that A now trusts b and c.

Since B trusted A, B now also trusts c. The attacker hadn't to get
direct access to B, but by compromising A (which is higher in the trust
hierarchy), he compromised B's "trust situation".

I hope my writing isn't too confusing (so much repeating words...).

Kind regards
vanitasvitae



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

[Standards] Some thoughts on possible OMEMO trust models

[Vanitas Vitae]

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 OMEMO device, I have to do a trust
decision on every one of my devices.
* Whenever I revoke one of my devices, I have to inform all of my
contacts and everyone has to manually distrust the device
* Whenever a contact revokes a device, I have to distrust it on every
one of my devices.

(The third and fourth point might be invalid, because the one that
revokes their device can clear all active devices and also change their
xmpp accounts password, preventing the stolen/lost device to log in and
become active again)

So currently it is very annoying to keep trust synchronized across all
devices. This also makes OMEMO poorly usable for IoT, since most IoT
devices have no usable interface to make trust decisions.

I thought a little about it and here is what I came up with. Variant I
contains some ideas for some kind of web-of-trust for eg. chat devices
that have a usable configuration interface.
Variant II could be used for IoT devices with poor configuration interfaces.

Variant I:
Let's assume, I use device A and trusted some contact devices.
What I could do is:
* Whenever I trust a device "a" on my device A, I sign the fingerprint
of "a"'s identity key with my own identity key and upload the signature
to a private pubsub node (lets call it the "trust-node-A").
* When I start to use a new device B, I can fetch the contents of A's
trust-node. When I decide on B, that I trust device A, I can check all
the signatures in A's trust-node and automatically  have transitive
trust all devices trusted by A.

The downside of this is, that there is a "trust gradient", meaning that
older devices are higher up in the trust hierarchy than newer ones (what
happens, when you lose device A?) Also distrusting devices might be a
problem:
For distrusting a device, we could sign not only the fingerprint of the
device, but also a state indicator like "trust:FINGERPRINT"
(trust-proof) or "distrust:FINGERPRINT" (distrust-proof). That way,
devices could automatically ignore/delete trust-proofs, when there is
one or more distrust-proof.
Possible problem: What happens when an attacker distrusts all your
devices or creates paradox trust decisions? Eg. assume we have devices
A,B,C. A trusts B, B trusts C, C trusts A.
B distrusts A, C distrusts B, A distrusts C. How to resolve? You might
decide by counting, which device is trusted/distrusted by the majority
of device, but that would defeat the purpose of the whole system, since
again trust decisions must be made on each device. Is there something
useful for this in the OpenPGP-World?

It would be easier to have a single trust-node, that simply contains a
trust-proof for trusted devices and/or a distrust-proof for untrusted
devices. That way paradox situations are impossible.
Unfortunately it is not possible (or is it?) to use a single trust-node,
since we do not have a signature key that is shared between all devices.


Variant II:
This could be handy for IoT and is less complicated (I hope :D).
Since IoT devices often do not have an easy to use interface for
configuration, it might be a hassle to do trust decisions on them (which
other devices should be trusted).
To improve this, we might add a master-device, so each device only must
trust the master. The master decides, which devices are trusted by
signing their identity keys and publishing the signature on the
trust-node. Each thing looks up the trust-node to decide, which other
things to trust. When a device is not in the trust node, it must be
distrusted.
(I don't know, how IoT is done with xmpp. In this model, all things have
the same jid. I don't know, whether this is also possible with unique
jids for each thing.)

You might as well create different trust-nodes for different "groups" of
devices. That way you could group devices together. When a device
fetches the trust-nodes, it has to trust only those devices, that it is
in a group with together and distrust all devices that it does not share
a group with.


So what do you think of this?

Vanitasvitae





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