[messaging] RFC: async NaCl relay

[Ben Harris]

On 23 Dec 2015 1:16 pm, "Max Skibinsky" <max at skibinsky.com> wrote:
>
>
> what if Mallory takes tomorrow's timestamps and precalculate 1M
> verify_token and 1M nonces satisfying their POW and then sends them
> within tomorrow timestamp window (which have to be non-zero to allow
> for weaker clients)? or I'm still misunderstanding your schema?

Only the server can calculate the HMAC in the verify_token.

> very interesting! so hpk becomes signing key only, are all encryption
> keys are ephemeral (exchanged as needed under hpk signature?). The
> elegance of this is clear on intuitive level - I'm curious what are
> the formal issues of using same key for auth and encryption and what
> sort of weakness that introduces? (just an RTFM link is fine if
> simpler) I presume that is the reason why Nacl itself uses different
> keys for crypto_box and crypto_sign?

No, I believe the Edwards curve is just more performant. I don't have an
article for you unfortunately (and I'm hardly an expert in this field), it
just avoids issues where outputs of one process can be used to attack other
process.

> I think we are one step away from fully anon messaging. yes, anybody
> can generate [a_pk,a_hpk] at will, yet by itself it's useless. they
> need to receive b_pk from somebody else first to be able to message
> them (and know their hpk).  let's say hpk is somehow leaked and that
> hpk is spammed with 1m garbage messages from 1m random hpks. to

It may not be your use case then - I just got the impression from your spec
that you wanted jax to be agnostic to the underlying end to end message
protocol.

But if you are linking the hpk to message protocol then it seems you want a
more integrated solution.

The other approach to spam is Pond's privacy preserving token style. It
might be worth considering if you wanted to avoid the server from being
able to determine sender-receiver relationships.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20151223/0c4d9428/attachment.html>