[jdev] Any thoughts on implementing end to end message encryption?
mat at squareconnect.com
Wed Nov 14 02:59:06 UTC 2012
To give you an understanding of our application, we have small embedded
devices that use PEP to publish changes to their state (for example, a
light is turned on, a temperature sensor sends a measurement, a lock is
unlocked). Anyone on it's roster who has indicated interest in that event
type gets the event using the server's PEP implementation.
I dont think I fully understand how the keys work. In PEP, the recipient of
the message is the account of the sender. The PEP service takes care of
forwarding it to each interested resource. How do we have a single
encrypted message that can be decrypted by multiple users? I think it is
late at night and my head is exploding with SMK's and CMK's.
On Tue, Nov 13, 2012 at 8:35 PM, Matthew Miller
<linuxwolf at outer-planes.net>wrote:
> It might still be possible to use PEP or pubsub, but it does require the
> publisher and subscribers to be available at the same time.
> I've be happy to adjust text to make it at least allowed.
> I should note that this draft is still in flux because of work ongoing in
> the JOSE WG at the IETF.
> - m&m
> On Nov 13, 2012 7:23 PM, "mat henshall" <mat at squareconnect.com> wrote:
>> Thanks Peter,
>> I had missed the later draft-miller-xmpp-e2e somehow in my poking at
>> One question is how do you accomplish encryption of messages that are
>> published through PEP or Pub-Sub? Seems that the draft-miller specifically
>> prohibits that (section 8)?
>> On Tue, Nov 13, 2012 at 7:37 PM, Peter Saint-Andre <stpeter at stpeter.im>wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>> On 11/13/12 4:49 PM, mat henshall wrote:
>>> > We have an application that needs to be able to encrypt and sign
>>> > messages and IQ stanza's that contain custom elements 'end to end'
>>> > from one client to another, possibly across multiple federated
>>> > services.
>>> > Looking at RFC 3923, ther seems to be very little practical
>>> > application of this specification.
>>> > Is there any reason?
>>> > Should I ignore this? If so what would the community suggest?
>>> We've tried 5+ times to build end-to-end encryption. We've failed each
>>> 1. PGP (XEP-0027) - never widely adopted, who has PGP keys?
>>> 2. SMIME+CPIM (RFC 3923) - checking off a security box for the IETF
>>> 3. xmlenc (never documented) - might be used somewhere, but those
>>> people aren't talking
>>> 4. ESessions (XEP-0116) - implemented once, no other adoption
>>> 5. XTLS (draft-meyer-xmpp-e2e-encryption) - experimental, didn't move
>>> At this point I think there are other solutions under discussion:
>>> 6. OTR - http://www.cypherpunks.ca/otr/
>>> 7. XMPP e2e - draft-miller-xmpp-e2e
>>> I sure hope we'll settle on one of those before the heat death of the
>>> universe. Your feedback is welcome. :)
>>> - --
>>> Peter Saint-Andre
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
>>> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
>>> -----END PGP SIGNATURE-----
>>> JDev mailing list
>>> Info: http://mail.jabber.org/mailman/listinfo/jdev
>>> Unsubscribe: JDev-unsubscribe at jabber.org
>> Mat Henshall
>> Founder and CEO, Square Connect, Inc.
>> San Jose, CA
>> cell: 650.814.7585
>> JDev mailing list
>> Info: http://mail.jabber.org/mailman/listinfo/jdev
>> Unsubscribe: JDev-unsubscribe at jabber.org
> JDev mailing list
> Info: http://mail.jabber.org/mailman/listinfo/jdev
> Unsubscribe: JDev-unsubscribe at jabber.org
Founder and CEO, Square Connect, Inc.
San Jose, CA
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the JDev