[Remops] New Zax-style nymserver with forward secrecy

[Jeremy Bentham Admin]

Tom - thanks for the input - see my comments below...

On Thu, Aug 14, 2014 at 07:12:46AM -0500, Tom Ritter wrote:
>(Cross-Posting to messaging, context below)
>
>I guess I missed this in May, but this is cool, thanks a lot for
>working on it! I have the following, somewhat high-level thoughts:
>
> - Axolotl will not fully ratchet for months in many use cases, merely
>derive new Message Keys from the Chain Key. This is because it's not
>common for you to send configuration messages to the nymserv once it's
>up and running well.  I don't think Axolotl was designed to be
>primarily a one-way communication method, but I don't think it's
>insecure in that situation either.

The way I've set things up, the nym user is one side of the axolotl
conversation and the server is the other. So when a message is
received for the nym, this ratchets one side and when a message is
sent from the nym this ratchets the other side. As a result, a full
ratchet will occur as often as there is a send/receive pair. For
multiple sends or receives in a row, you are (of course) correct.

> - Unless one was doing something very unusual and scary[0] this
>doesn't change the story from other methods - but this does now
>require someone to maintain linkable state with their nym. They can't
>carry that information around memorized.

Each nym has an axolotl database with the key state on the server, and
the user has the corresponding database with their client. Databases
are encrypted on disk. These databases maintain the state.

If things should somehow get out of sync, the nym user can resync in
a fairly simple fashion. Messages sent/received during the unsynced
period are of course undecryptable.

> - How does it handle out of order or missing messages? Does it derive
>message keys and cache them until it can decrypt? Does it store those
>keys indefinitely?

Missing message keys are generated and cached for a period of time
(default 2 days). Once that period of time is up, the key is deleted
from the cache and the message is undecryptable. This period of time
can be changed easily if desired.

> - A GUI with no pictures? :(

Here you go...

https://felipedau.github.io/nymphemeral/usage/usage.html


>-tom
>
>[0] like https://ritter.vg/blog-non_persistent_pgp.html
>
>On 13 August 2014 10:54, Jeremy Bentham Admin
><jeremyadmin at anemone.mooo.com> wrote:
>> I wanted to let people know that we have developed a nice GUI client
>> script for using the enhanced Zax-style nymserver at nym.now.im.
>> The 'enhanced' nymserver uses ephemeral encryption on all
>> non-configuration messages sent to and received from the nymserver.
>>
>> The new GUI client is written in python and supports nym
>> creation/deletion/reconfiguration as well as receiving messages
>> addressed to the nym via a.a.m and sending messages from the nym.
>>
>> Source code and installation instructions for the GUI client are at:
>>
>> https://github.com/felipedau/nymphemeral
>>
>> Source code for the enhanced nymserver is cloned from Zax's original
>> nymserver code (thanks Zax!) and is at:
>>
>> https://github.com/rxcomm/nymserv
>>
>> Finally, details on how the ephemeral encryption works, as well as
>> the nymserver's public key and some other information are at:
>>
>> http://nym.now.im/nymserver
>>
>> As always, feedback is appreciated. For a bit more time, I am running
>> the nymserver logs in full debug mode so consider the operation
>> experimental and don't use it for anything sensitive at this point. I
>> will make a further announcement in a few weeks when I shut down the
>> logging and move the nymserver into production mode.
>>
>> A couple of other notes: 1) The nymserver should also function as a
>> standard Zax-style nymserver, with or without symmetric encryption. 2)
>> It is not recommended to use both ephemeral and symmetric encryption
>> simultaneously. 3) More details on ephemeral encryption (why it is
>> important, as well some details about the Axolotl protocol used with
>> nym.now.im) can be found at https://github.com/rxcomm/pyaxo
>>
>>
>>
>> On Thu, May 01, 2014 at 04:46:39PM +0200, Jeremy Bentham Admin wrote:
>>>
>>> I've been having some fun playing with Zax's nymserver script.
>>>
>>> I added the use of ephemeral symmetric encryption keys for forward
>>> secrecy on posts to a.a.m as well as mail sent to the nymserver's
>>> send address. Ephemeral keys are managed using the Axolotl protocol.
>>>
>>> Before I turn this loose, I'd appreciate some feedback on how
>>> things work. Details for using the nymserver, including the public
>>> key and a script to handle client-side ephemeral encryption can be
>>> found at:
>>>
>>>  http://nym.now.im/nymserver/
>>>
>>> Right now you should consider this nymserver in beta mode. I'm running
>>> full debug output on the logs. Don't use it for anything sensitive.
>>>
>>> I'll post my code after I get some feedback and make sure things are
>>> working okay.  Making the changes was pretty straightforward, thanks
>>> to Zax's neat coding style.
>>>
>>> Let me know what you think.
>>>
>>> --
>>> Jeremy Bentham Remailer Admin
>>> Key fingerprint = D7DE B0DF E6F9 9256 A070  B841 1942 840B 8743 B6B5
>>
>>
>>
>>
>> --
>> Jeremy Bentham Remailer Admin
>> Key fingerprint = D7DE B0DF E6F9 9256 A070  B841 1942 840B 8743 B6B5
>>
>> _______________________________________________
>> Remops mailing list
>> Remops at lists.mixmin.net
>> http://lists.mixmin.net/mailman/listinfo/remops
>>

-- 
Jeremy Bentham Remailer Admin
Key fingerprint = D7DE B0DF E6F9 9256 A070  B841 1942 840B 8743 B6B5
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.mixmin.net/pipermail/remops/attachments/20140814/0bc0fe92/attachment.sig>