[JDEV] Encrypted xml transfer, was servers specifying from fields

[Mathew A Johnston]

To me, not being able to send messages encrypted to a user when they're
not online is unacceptable... Perhaps we need an encrypted 'datagram'
namespace, and an encrypted 'session' namespace? Session would generate a
session key, datagram would just use plain old public key
crypto? ([p|g]pg)

I'm trying to get this encrypted 'datagram' namespace into jabber because
I want to be able to send url type messages that are encrypted, and
include decryption information incase the referenced file requires
decryption; a sort of secure reference to an encrypted file online. I'd
also like to make a client which automatically handles downloading and
decrypting files that it's given reference to (if the user chooses so of
course). Not allowing encrypted xml that's to be parsed to be sent
encrypted means that I'd be sending the url non encrypted, then sending
the decryption info in a normal encrypted message and isnt going to allow
that automation that I desire; also, what happens if I just want the url
its self to be secure and for the client to let the user click on
it/bookmark/etc?

For higher securty session based stuff, like chats or whiteboards or
something where both clients have to be online, using session key stuff
looks good... but for sending one time messages that are not session
based, session keys sound like a tonne of overhead, no?

Mathew Johnston 


On Sun, 4 Mar 2001, David Waite wrote:

> *grin*, I'll propose something as soon as I get my Applied Cryptography
> book back ;-) It has been popular as of late.
> 
> Since we already have a requirement of PGP in the clients (that wouldn't
> go away, as it works well for encrypted messages sent to offline store),
> there would just be a key negotiation between the two parties  - perhaps
> the first PGP-sent message will have a portion of the key enclosed as
> well in a separate block, as an 'offer' to support the alternate method
> of encryption. Having both people provide part of the final key should
> be enough to prevent replay. This key could be considered in some way
> tied to the 'thread' of conversation. I haven't considered any way to
> refresh the key, other than starting a new chat. Because this method
> wouldn't work for offline messages (the key would be lost when the other
> person came online), messages would just be required to be sent to a
> particular user resource (which will give a 404 error if they
> disconnect).
> 
> I guess thats an overview of what I'm thinking. Maybe I should look at
> rijndael (see, I *can* spel it write!)
> 
> -David Waite
> 
> Mathew A Johnston wrote:
> 
> > David, how do you plan to negotiate a session key?
> >
> > Mathew Johnston
> >
> > _______________________________________________
> > jdev mailing list
> > jdev at jabber.org
> > http://mailman.jabber.org/listinfo/jdev
> 
> 
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev
>