Hi,
I'd like to add a comment here (my final one).
I somehow got the feeling that some people on this mailing list actually don't
want the OMEMO standard to evolve, when it does not include the changes they
want.
Even though the Andy's ODR proposal is not generally in conflict with the
decisi
> From: Kevin Smith
> Sent: Thu Jun 08 09:35:45 CEST 2017
> [...] gather feedback from the community, build consensus or compromise as
> necessary, [...]
I don't want to be nitpicking here, but I had the feeling that the majority of
the community (as in, users and client developers, not necessa
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
> 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.
Easy solution (I a
> 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 pe
Hi,
> From: Sam Whited
> In theory this is the purpose of "experimental" XEPS, but in practice
> I think people mostly just get confused about what the "recommended"
> spec is and get annoyed that there are two specs with duplicate
> functionality. I personally don't like the idea of having multi
Hi all,
Just that I understand this topic correctly:
The intention is to put the currently implemented OMEMO (a.k.a. siacs OMEMO)
into the XEP and then no longer update that XEP and put all effort into
OMEMO-NEXT?
What is the reason to not continue develop OMEMO without UX breaking changes
(fin
Hi,
> "Remko Tronçon" wrote:
> On 31 May 2017 at 20:26, Chris Ballinger wrote:
>> What if instead of all this, we just funded a liberally licensed XEdDSA
>> reference implementation and got it audited?
>
> To be honest, I still think it'd be suboptimal. It would make the XEP still
> dependent on
Hi,
> "Remko Tronçon" wrote:
> Here's a proposal for the OMEMO key exchange that requires *no*
> changes to libsignal: Public Identity keys are Ed25519 keys with the
> highest bit (sign bit) 0.
>
> - LibSignal-based clients convert their internal Curve25519 identity key
> to Ed25519 right be
Hi Remko,
So just for the record (because you didn't answer that question from my
previous mail):
This is only an implementation detail and has no relevant influence (aka, at
most constant factor) on the cryptographic properties?
When changing the identity keys to Ed, will that mean that existi
Remko,
can you please describe the concrete benefits of your approach?
The only difference I can spot is that it's more implementation work for those
that use libsignal (which at this point in time seems to be all
implementations) and less for libsodium (which happens to not implement many
othe
Hi,
> - We change the Identity keys to be Ed25519 keys instead of Curve25519.
> Current client deployments are by default libsignal-based, and therefore
> have access to Curve25519-to-Ed25519 conversion methods to convert already
> authenticated keys, so they don't have to lose their keys.
> - We
12 matches
Mail list logo
