Page MenuHomePhabricator

Mixmaster GUI Options
Closed, WontfixPublic

Description

The purpose of this ticket is to explore the GUI choices for Mixmaster and nymservers that run natively on Linux for documentation/inclusion for Whonix. The lack of GUIs and the complexity of using remailers made them not viable for most groups except those with degrees in Computer Science. This led to most users missing out on a great alternative to conventional email. Lack of adoption hurts the level of anonymity provided by the Mixmaster network.

Researched choices:

  • Pyano - a simple python based webinterface by Paranoici a tech activist collective.

http://pyanon.sourceforge.net

  • Nymphemeral - great python GUI. Well documented by the

authors. Feature-rich and optionally supports new nym server
types that understand protocols like axolotl and forward secrecy.

https://pypi.python.org/pypi/nymphemeral
http://lists.mixmin.net/pipermail/remops/2014-September/001042.html
https://moderncrypto.org/mail-archive/messaging/2014/000590.html
http://k0rx.com/blog/2014/09/nymphemeral.html
https://github.com/felipedau/nymphemeral

TO-DO:

  • Discuss code signing and upstream inclusion with nymphemeral dev - Done

https://github.com/felipedau/nymphemeral/issues/3

  • Contact Pyano devs and see if they can move from the Apache dependency to something smaller like libmicrohttpd (which is also packaged in Debian).

https://www.whonix.org/pipermail/whonix-devel/2015-June/000378.html

  • Document secure install of nymphemeral when it becomes possible or see if it can be integrated into Whonix

Details

Impact
Normal

Related Objects

Event Timeline

HulaHoop created this task.Jun 30 2015, 1:27 AM
HulaHoop claimed this task.
HulaHoop raised the priority of this task from to Normal.
HulaHoop updated the task description. (Show Details)
HulaHoop set Impact to Normal.
HulaHoop added a subscriber: HulaHoop.
HulaHoop updated the task description. (Show Details)Jun 30 2015, 1:30 AM
HulaHoop updated the task description. (Show Details)Jun 30 2015, 1:54 AM
HulaHoop updated the task description. (Show Details)Jun 30 2015, 2:01 AM
HulaHoop updated the task description. (Show Details)Jun 30 2015, 6:37 PM

Testing efforts will only be focused on nymphemeral because its the most promising. Takes care of the complexities of header formatting and newsgroup message retrieval.

Testing Status report:

"Error while manipulating mix.cfg"
Its not clear what the conflict stems from. Expected settings and defaults between Whonix's Mixmaster instance and nymphemeral's installation advice could be the cause:
https://nymphemeral.readthedocs.org/en/stable/install/mixmaster.html

dau added a subscriber: dau.EditedJul 2 2015, 9:13 PM

I am not sure if I should be posting here. But apparently I am allowed to.

In T367#5802, @HulaHoop wrote:

Testing efforts will only be focused on nymphemeral because its the most promising. Takes care of the complexities of header formatting and newsgroup message retrieval.
Testing Status report:
"Error while manipulating mix.cfg"
Its not clear what the conflict stems from. Expected settings and defaults between Whonix's Mixmaster instance and nymphemeral's installation advice could be the cause:
https://nymphemeral.readthedocs.org/en/stable/install/mixmaster.html

That error means that an IOError was raised when acessing the config file in your Mixmaster installation. As it is mentioned in the documentation, you can edit ~/.config/nymphemeral/nymphemeral.cfg to point to your Mixmaster installation (the default is ~/Mix), which is probably the cause of the error. There is also the possibility that your Mixmaster version uses a name for the config file other than mix.cfg.

Unfortunately we do not have a GUI for the settings and ~/Mix is usually the default directory when the user installs Mixmaster. Manually editing nymphemeral.cfg under the [mixmaster] section to point to the correct directory and config file will fix the issue. I assume Whonix already comes with Mixmaster installed, but probably somewhere else.

Thanks for using nymphemeral!
-Felipe

In T367#5805, @dau wrote:

I am not sure if I should be posting here. But apparently I am allowed to.

No worries. It's open to public. Anything constructive to this ticket. Your welcome here. Your post looks very constructive.

I assume Whonix already comes with Mixmaster installed, but probably somewhere else.

Yes. Current Whonix stuff, related to mixmaster:

Thanks for following up Felipe. Yes it turns out the Mixmaster file paths needed adjustment like you said. There is probably an instal location discrepancy between the compiled Mixmaster and the one installed from Debian. I changed the cfg file path to point to where we have it but there is probably something else I'm missing to get it to work. Nymphemeral configuration now:

[mixmaster]
base_folder = /usr/bin/mixmaster
binary = /usr/bin/mixmaster
cfg = /home/user/.Mix/mix.cfg

sudo dpkg -L mixmaster output:

/.
/var
/var/log
/var/log/mixmaster
/var/lib
/var/lib/mixmaster
/etc
/etc/init.d
/etc/init.d/mixmaster
/etc/cron.daily
/etc/cron.daily/mixmaster
/etc/logrotate.d
/etc/logrotate.d/mixmaster
/etc/ppp
/etc/ppp/ip-up.d
/etc/ppp/ip-up.d/mixmaster
/etc/mixmaster
/etc/mixmaster/update.conf
/etc/mixmaster/network.conf
/etc/mixmaster/allpingers.txt
/etc/mixmaster/remailer.conf
/etc/mixmaster/filter.conf
/etc/mixmaster/client.conf
/etc/mixmaster/remailer
/etc/mixmaster/remailer/end.hlp
/etc/mixmaster/remailer/news.hlp
/etc/mixmaster/remailer/pgponly.hlp
/etc/mixmaster/remailer/pgp.hlp
/etc/mixmaster/remailer/type1.hlp
/etc/mixmaster/remailer/mix.hlp
/etc/mixmaster/remailer/intro.hlp
/etc/mixmaster/remailer/usage.txt.in
/etc/mixmaster/remailer/reply.txt.in
/etc/mixmaster/remailer/blocked.txt.in
/etc/mixmaster/remailer/abuse.txt.in
/etc/mixmaster/remailer/dest.alw
/etc/mixmaster/remailer/header.blk
/etc/mixmaster/remailer/adminkey.txt
/etc/mixmaster/remailer/pop3.cfg
/usr
/usr/lib
/usr/lib/mixmaster
/usr/lib/mixmaster/mixmaster-rebuild
/usr/share
/usr/share/menu
/usr/share/menu/mixmaster
/usr/share/doc
/usr/share/doc/mixmaster
/usr/share/doc/mixmaster/README.gz
/usr/share/doc/mixmaster/README.Debian.gz
/usr/share/doc/mixmaster/changelog.Debian.gz
/usr/share/doc/mixmaster/changelog.gz
/usr/share/doc/mixmaster/copyright
/usr/share/doc/mixmaster/TODO
/usr/share/man
/usr/share/man/man1
/usr/share/man/man1/mixmaster-filter.1.gz
/usr/share/man/man1/mixmaster-update.1.gz
/usr/share/man/man1/mixmaster.1.gz
/usr/bin
/usr/bin/mixmaster
/usr/bin/mixmaster-filter
/usr/bin/mixmaster-update
diverted by uwt to: /usr/bin/mixmaster-update.anondist-orig
dau added a comment.Jul 4 2015, 12:41 AM
In T367#5826, @Patrick wrote:
In T367#5805, @dau wrote:

I am not sure if I should be posting here. But apparently I am allowed to.

No worries. It's open to public. Anything constructive to this ticket. Your welcome here. Your post looks very constructive.

I assume Whonix already comes with Mixmaster installed, but probably somewhere else.

Yes. Current Whonix stuff, related to mixmaster:

Thanks Patrick! I will read those articles.

In T367#5827, @HulaHoop wrote:

Thanks for following up Felipe. Yes it turns out the Mixmaster file paths needed adjustment like you said. There is probably an instal location discrepancy between the compiled Mixmaster and the one installed from Debian. I changed the cfg file path to point to where we have it but there is probably something else I'm missing to get it to work. Nymphemeral configuration now:

[mixmaster]
base_folder = /usr/bin/mixmaster
binary = /usr/bin/mixmaster
cfg = /home/user/.Mix/mix.cfg

sudo dpkg -L mixmaster output:

/.
/var
...

Got it. Are you still having the same mix.cfg error?

Got it. Are you still having the same mix.cfg error?

Yes. I've also tried many other likely paths but with no success unfortunately.

dau added a comment.Jul 4 2015, 7:02 AM
In T367#5855, @HulaHoop wrote:

Got it. Are you still having the same mix.cfg error?

Yes. I've also tried many other likely paths but with no success unfortunately.

I installed Whonix and I found out what the problem is. That is a bug on nymphemeral. I apologize for that :(

Here is what is happening: the mix.cfg file is only used (by nymphemeral) to display the mix chain. If an IOError is raised when accessing the file, the "Error while manipulating mix.cfg" message is printed (in the terminal, not the GUI) and the chain does not change from None. It will also keep that value if the chain is not found in the file (our case).

It happens that when I coded, I assumed that if a chain was found, Mixmaster was probably correctly installed, configured and ready to be used. Therefore, inside the GUI, it is checked if the chain exists to display it and enable the radio button to use Mixmaster, and if it is not found the "Error while manipulating mix.cfg" will be displayed too (now in the GUI), even if no IOError was raised, because the chain would still be None.

After installing Whonix, I saw that mix.cfg has only the SMTPRELAY option. That's why the chain is not being found and this whole thing is going on.

For now, adding a chain to the Mixmaster configs will "fix" the issue so you can keep testing, but I will fix it on nymphemeral.

The simplest way is to assign an "Unkown chain" to the chain variable when it cannot be found in the file. That value will be displayed instead of the error and will allow the user to use Mixmaster, but it still does not change the fact that I am assuming that Mixmaster is installed and working by simply checking mix.cfg. Do you have any idea of how to do that properly?

I'm really sorry for making you waste time on such a silly bug :(

Apparently I was able to successfully send a couple dummy messages with Mixmaster, so I assume regular messages will be sent as well. I would like to point out that nymphemeral was tested with Mixmaster >= 3.0.2, and Whonix comes with Mixmaster 3.0 only. That should not be a big deal, but there could happen unexpected errors. I will install nymphemeral and do some testing as well.

Ps: I would like that you read my last post on the GitHub issue you opened, because I want to know what exactly you guys expect from nymphemeral.

Thanks!

I installed Whonix and I found out what the problem is. That is a bug on nymphemeral. I apologize for that

Totally fine. You've been very helpful so far and open to suggestions, thanks.

The simplest way is to assign an "Unkown chain" to the chain variable when it cannot be found in the file. That value will be displayed instead of the error and will allow the user to use Mixmaster, but it still does not change the fact that I am assuming that Mixmaster is installed and working by simply checking mix.cfg.

So are you just checking for the existence of the file or are you also parsing its contents and going off of that? The first method (if possible to implement) would make it more robust because it makes less assumptions I think.

Orthognal questions: Can/Should Nymphemeral allow users to set their own chain length? Also how does Nymphemeral deal with the exit remailers disallowing "From:" headers? AFAICT this header is the only way a recipient knows what nym to reply to. There is only a handful of exits like dizum that accept custom From headers.

Do you have any idea of how to do that properly?

Could ConfigParser work for this?

Ps: I would like that you read my last post on the GitHub issue https://github.com/felipedau/nymphemeral/issues/3 you opened, because I want to know what exactly you guys expect from nymphemeral.

Hadn't had the chance to check GitHub for the past days, will reply soon.

dau added a comment.Jul 10 2015, 9:11 PM

So are you just checking for the existence of the file or are you also parsing its contents and going off of that? The first method (if possible to implement) would make it more robust because it makes less assumptions I think.

I am parsing the contents. I also agree with you, but the problem is that nymphemeral would still assume that Mixmaster is installed (and working) based only on the config file. I guess it would be a bit better if it checked for the binary instead.

I am going to take a look to see if there is a way to run Mixmaster's own tests. Otherwise nymphemeral could try to run a simple test, like sending a dummy message. I am not sure, but these tests would probably add some delay to nymphemeral's startup.

I will open an issue for that.

Orthognal questions: Can/Should Nymphemeral allow users to set their own chain length?

nymphemeral does not have that feature yet. The user will have to manually set it, because will depend on what is actually on mix.cfg.

Also how does Nymphemeral deal with the exit remailers disallowing "From:" headers? AFAICT this header is the only way a recipient knows what nym to reply to. There is only a handful of exits like dizum that accept custom From headers.

All the messages sent through nymphemeral (via Mixmaster or not) go to the nym server. It is the server that sends them to the targets afterwards. As the message also has an asymmetric encryption layer signed by the nym, the server would check the signature and know which nym sent it. It will then send it for him.

I actually do not know how the server would manage Mixmaster chaining to send the message to the final target, although I believe that would not happened because nyms expect to receive replies. It is important that the client uses Mixmaster to anonymize the user (actual owner of the nym), but if the nym server mixed the message as well until it gets to the final recipient and the "From:" header persisted, then just the path of the message would remain unknown, because the server was revealed.

Just would like to remind that as nymphemeral is a Zax-type client, that's how a Zax-type nym would send its messages. Also, it would receive messages by downloading from a news group. Other nym servers, e.g. GHIO-type, work differently.

Thanks!

I am not sure, but these tests would probably add some delay to nymphemeral's startup.

You know how users will have to renew remailer chain information - usually once a day? this dummy message sending test could be part of that procedure instead of something done on (every) startup by nymphemeral.

All the messages sent through nymphemeral (via Mixmaster or not) go to the nym server. It is the server that sends them to the targets afterwards. As the message also has an asymmetric encryption layer signed by the nym, the server would check the signature and know which nym sent it. It will then send it for him.

Is it the same for any Zax-type nymserver? From testing I understood that one sends the message through Mixmaster to the recipient but uses the nym address in the From: header to let the recipient know that there is a destination they can send a reply to. The nymserver would only interact with replies from the recipient, encrypting and directing them to a.a.m.

Anyway your solution of relaying it to the nymserver that then sends it on your behalf is more usable/stable.

Just would like to remind that as nymphemeral is a Zax-type client, that's how a Zax-type nym would send its messages. Also, it would receive messages by downloading from a news group. Other nym servers, e.g. GHIO-type, work differently.

Yeah I know. Zax-type nymservers are the only type I have used and there is a night-and-day difference in usability when looking at how GHIO nymservers work. GHIO-type nymservers are a nightmare, they should shut them down.


Please keep me posted about the developments for the Github tickets you opened today.

Off-topic:

Felipe do you mind helping me figure out something for our Mixmster wiki documentation?
I'm trying to document the long way of registering a nym with a Zax Nymserver (mixnym.net) that uses an hsub instead of a plaintext subject line. The latter works but sticks out like a sore thumb on a.a.m. All my trials with formatting a message with an hsub header failed as they never got replies from the nymserver. (Note that I'll need to change the part about Icedove as a newsgroup client to aam2mail instead). Please post an exact example of a nym registration message that also configures an hsub.

I'll keep these instructions around until they become obsolete when nymphemeral is integrated in Whonix.

dau added a comment.Jul 11 2015, 7:19 AM
In T367#5902, @HulaHoop wrote:

You know how users will have to renew remailer chain information - usually once a day? this dummy message sending test could be part of that procedure instead of something done on (every) startup by nymphemeral.

I don't know how often they would have to do that, but nymphemeral only displays it for convenience. It is not too important. I like your idea, I will keep that in mind.

Is it the same for any Zax-type nymserver? From testing I understood that one sends the message through Mixmaster to the recipient but uses the nym address in the From: header to let the recipient know that there is a destination they can send a reply to. The nymserver would only interact with replies from the recipient, encrypting and directing them to a.a.m.
Anyway your solution of relaying it to the nymserver that then sends it on your behalf is more usable/stable.

In theory the only difference from the regular Zax-type and the new one is the ephemeral encryption, and I always thought that's how Zax designed it.

Yeah I know. Zax-type nymservers are the only type I have used and there is a night-and-day difference in usability when looking at how GHIO nymservers work. GHIO-type nymservers are a nightmare, they should shut them down.

Indeed!

Please keep me posted about the developments for the Github tickets you opened today.

Absolutely.

In T367#5904, @HulaHoop wrote:

Off-topic:
Felipe do you mind helping me figure out something for our Mixmster wiki documentation?

Not at all!

I just skimmed through the link you posted and noticed there are some errors there, or maybe the server or Mixmaster are smarter than I thought.

AFAIK, for Zax-type nym servers:

Creation and configuration messages should be sent to config@server and regular messages to send@server.
If I were to send the following message:

From: nym@server
To: recipient@domain
Subject: Example

This is an example

I would encrypt to the nym server to send to send@server and add the outer headers:

From: nym@server
To: send@server
Subject: Example

-----BEGIN PGP MESSAGE-----
...
-----END PGP MESSAGE-----

Note that I encrypt the original headers and body of the message. The PGP block has everything composed earlier.

Finally I would send it to send@server (via Mixmaster or whatever I would like to use) and then the server would deliver the message to recipient@domain after decrypting the PGP message.

Also, from nymphemeral's point of view, the "From:" and "Subject:" headers do not even have to match or be valid.

I'm trying to document the long way of registering a nym with a Zax Nymserver (mixnym.net) that uses an hsub instead of a plaintext subject line. The latter works but sticks out like a sore thumb on a.a.m. All my trials with formatting a message with an hsub header failed as they never got replies from the nymserver. (Note that I'll need to change the part about Icedove as a newsgroup client to aam2mail instead). Please post an exact example of a nym registration message that also configures an hsub.

If you are using the hsub: header when creating the nym, it should work. I never used Icedove to retrieve these messages. How would you check for the hSubs?

I am going to run some tests before writing the full instructions. By the way, would you like to open another ticket for that?

I am going to talk to rxcomm, the developer of the new nym server, to confirm the differences from the regular and new nym servers.

For now, I hope this post can help you, but do not take it too seriously until I confirm if what I do is actually correct.

Thanks Felipe. I followed your directions and now it works!

I just skimmed through the link you posted and noticed there are some errors there, or maybe the server or Mixmaster are smarter than I thought.

Yes there are many. I'll fix up this guide now and I'll give you credit for helping.

Creation and configuration messages should be sent to config@server and regular messages to send@server.

That was it.
I hadn't seen this explained clearly anywhere except in your post. My instructions were based on wrong usenet comments.

I never used Icedove to retrieve these messages. How would you check for the hSubs?

Not possible, it just a temporary solution for use with plaintext subjects until I got hsubs working.

I am going to run some tests before writing the full instructions. By the way, would you like to open another ticket for that?

Sure.

I am going to talk to rxcomm, the developer of the new nym server, to confirm the differences from the regular and new nym servers.
For now, I hope this post can help you, but do not take it too seriously until I confirm if what I do is actually correct.

Thanks.

For completion, please also describe how to post to a newsgroup with a nym.

dau added a comment.Jul 12 2015, 2:33 AM
In T367#5906, @HulaHoop wrote:

Thanks Felipe. I followed your directions and now it works!

Great!

Yes there are many. I'll fix up this guide now and I'll give you credit for helping.

Don't worry about it! I started modifying that section and I can send you once its done.

That was it.
I hadn't seen this explained clearly anywhere except in your post. My instructions were based on wrong usenet comments.

Unfortunately we do not have much (and good) information out there related to this stuff :(

Not possible, it just a temporary solution for use with plaintext subjects until I got hsubs working.

Got it. I am going to make a sub-section on aampy, another tool developed by rxcomm. It easily downloads messages for your nyms checking their hsubs.

Thanks.
For completion, please also describe how to post to a newsgroup with a nym.

No problem! I'll let you know once I have something new :)

Thanks!

I pushed a major change to the wiki. Many parts are rewritten and new information added.

Got it. I am going to make a sub-section on aampy, another tool developed by rxcomm. It easily downloads messages for your nyms checking their hsubs.

Ok Great

dau added a comment.Jul 15 2015, 8:24 PM

It seems that pip has been updated and nymphemeral is not installing as it should. HulaHoop, when you were testing nymphemeral, did you install it with pip or built it from source?

I was using pip. Should I try building from source?

dau added a comment.Jul 16 2015, 6:18 AM
In T367#5937, @HulaHoop wrote:

I was using pip. Should I try building from source?

The issue came up when using pip 7. It does not allow files being installed outside of the scope any more. nymphemeral was copying the generic.db (a template needed to start a conversation with the server), connection scripts and docs to /usr/share/nymphemeral and pip 7 can't do that anymore. And they are right, I shouldn't be doing that.

You were probably using pip 6. Otherwise you would not even get to that mix.cfg error. I would like that you tried to update nymphemeral to see if you would get any errors. You can do it with sudo pip install nymphemeral --upgrade. By the way, what were you able to test so far?

Right now I can't update nymphemeral to run automatically when installed on Whonix, but I was able to make it work with a few manual changes. Let me know what issues you had that I am preparing the instructions for you.

Thanks!

You were probably using pip 6. Otherwise you would not even get to that mix.cfg error. I would like that you tried to update nymphemeral to see if you would get any errors. You can do it with sudo pip install nymphemeral --upgrade. By the way, what were you able to test so far?

I can successfully upgrade nymphemeral with pip however I still have the same error with mix.cfg

Right now I can't update nymphemeral to run automatically when installed on Whonix, but I was able to make it work with a few manual changes. Let me know what issues you had that I am preparing the instructions for you.

Ok great.

dau added a comment.Jul 16 2015, 8:21 PM

I can successfully upgrade nymphemeral with pip however I still have the same error with mix.cfg

Great!

Here is how I got it working:

  1. First of all, we provide socat scripts to the users to use Tor when sending/receiving messages. Since Whonix naturally does that, socnews.sh and socsmtp.sh are not needed. However, the user should still use stunnel to download messages with TLS. Install stunnel:
sudo apt-get install stunnel4

Download the stunnel .conf file we provide:

sudo curl https://raw.githubusercontent.com/felipedau/nymphemeral/master/connections/stunnel.conf -o /etc/stunnel/stunnel.conf

Edit /etc/stunnel/stunnel.conf. At the end of the file, you can ignore (prepend with ; or delete the lines) the [ssmtp-client] section and use the default that is already configured in mix.cfg, but should not ignore the [nntps-client] section. Those values would connect to the port that socat would be listening. As we are not using socat because every connection on Whonix is done via Tor, you can configure to connect directly to the news server:

[nntps-client]
client = yes
accept = 127.0.0.1:119
connect = news.mixmin.net:563

;[ssmtp-client]
;protocol = smtp
;client = yes
;accept = 127.0.0.1:2525
;connect = 127.0.0.1:2526

Enable stunnel by setting ENABLE to 1 in /etc/default/stunnel4:

# Change to one to enable stunnel automatic startup
ENABLED=1
FILES="/etc/stunnel/*.conf"
OPTIONS=""

Finally, start it:

sudo service stunnel4 start
  1. Until I fix the mix.cfg issue, please add some chain to that file:
SMTPRELAY 1.1.1.1
SMTPRELAY 2.2.2.2
CHAIN *

Launch nymphemeral to create the user files:

nymphemeral

You will still get the mix.cfg error. Now that the config file has been created, modify the [mixmaster] section to point to the correct paths:

[mixmaster]
base_folder = /home/user/.Mix
binary = /usr/bin/mixmaster
cfg = %(base_folder)s/mix.cfg

Still in that file, I would advise you to enable the debug messages from the [main] section:

[main]
...
debug_switch = True
...

Now you should be ready to launch nymphemeral and use Mixmaster :) All you have to do is getting the public key from nym.now.im/nymserver and importing with the Manage Servers button on the login window.

  1. I'd advise you to read the docs not only to understand nymphemeral, but also to provide me some feedback, if possible.

I hope it works!

Awesome. I have Nymphemeral up and running.

Notes:

  • I have some confusion about what to do about the Ephemeral Key field under the Create Nym tab. I probably missed something when reading the documentation. Can you please add an explanation about it on:

https://nymphemeral.readthedocs.org/en/stable/use/creation.html

  • Suggestion: What do you think about changing the name of the "Name" field into pseudonym? The idea is to prevent newbies from putting in their real name by mistake.
  • Suggestion: At the moment the Nymphemeral keyring is separate from th one in the user's home directory. What if Nymphemeral automatically symlinks to the user's keychain to make the process of using contact's keys more seamless so at no point the command line will be needed?
dau added a comment.Jul 17 2015, 1:34 AM
In T367#5952, @HulaHoop wrote:

Awesome. I have Nymphemeral up and running.

Good to hear that :)

  • I have some confusion about what to do about the Ephemeral Key field under the Create Nym tab. I probably missed something when reading the documentation. Can you please add an explanation about it on:

https://nymphemeral.readthedocs.org/en/stable/use/creation.html

You are right, there should be more information about that. The Axolotl protocol derives a master key from the handshake to start a conversation. Since we already have a secure channel (using the server's PGP key), the nym can go ahead and send that master key, so the server does not need to make a handshake. That's the ephemeral key you see and it can be any random key.

I'm planning on adding some check boxes that the user can check to automatically generate the ephemeral key and hsub passphrase so they do not even have to worry about them.

  • Suggestion: What do you think about changing the name of the "Name" field into pseudonym? The idea is to prevent newbies from putting in their real name by mistake.

I agree!

  • Suggestion: At the moment the Nymphemeral keyring is separate from th one in the user's home directory. What if Nymphemeral automatically symlinks to the user's keychain to make the process of using contact's keys more seamless so at no point the command line will be needed?

In previous versions, nymphemeral was actually grabbing the keys from the local keyring. I discussed that with rxcomm and we decided to totally split them. That way we can prevent the users from making mistakes and correlating their real identities and nyms. That will also prevent nymphemeral from messing with the user's keyring; mistakes happen :/

Unfortunately we do not have information on how people use their nyms. Maybe they might use their real keys in the end-to-end encryption layer, but maybe (through another channel) they should exchange their nyms and only encrypt/sign with the nyms' keys instead of the real ones (sounds much better).

I do think that it is convenient to access the user's keyring, but it shouldn't be done for those reasons. By making the user manually add these keys we can assume that they know what they are doing and maybe decrease the chances of screwing up.

I have a plan of upgrading the "Server Manager" used to add the server key to become some kind of a keyring manager and the user will not need to use the terminal for that any more. In fact (not intentionally) you are already allowed to add any key using the server manager because there is nothing checking if the key you are adding is actually from a nym server. The window still only show keys from nym servers, but any key can be added.

In T367#5953, @HulaHoop wrote:

I also agree with that! It should be mentioned that the headers are visible to the nym server.

Let me know what you think! Thanks for the feedback :)

I'm planning on adding some check boxes that the user can check to automatically generate the ephemeral key and hsub passphrase so they do not even have to worry about them.

Excellent. It would be even great as a default because the less choices a user has to make, the more frictionless their experience is.

In previous versions, nymphemeral was actually grabbing the keys from the local keyring. I discussed that with rxcomm and we decided to totally split them. That way we can prevent the users from making mistakes and correlating their real identities and nyms. That will also prevent nymphemeral from messing with the user's keyring; mistakes happen :/

Safe defaults are always the smart thing to do, so I agree that the current behavior should be as it is out-of the box, but for more flexibility can you make direct access to the user keyring an option that powerusers can enable? To make sure no mistakes are made, Nymphemeral could show a confirmation prompt warning the user not to use the option unless they know what they're doing.

Upgrading Server Manager to handle this still works, I'm just putting ideas out there :)

I will continue testing and keep you updated.

HulaHoop added a comment.EditedJul 17 2015, 7:47 AM

You are right, there should be more information about that. The Axolotl protocol derives a master key from the handshake to start a conversation. Since we already have a secure channel (using the server's PGP key), the nym can go ahead and send that master key, so the server does not need to make a handshake. That's the ephemeral key you see and it can be any random key.

No keys appear in the Ephemeral key field. Is this supposed to happen? I just typed in a random word and it seems to work.


Suggestions:

  • Nymphemeral main window having a checkbox option to remember typed addresses for convenience.
  • IMHO it feels more intuitive to click "Start Session" right under the address and passphrase fields, switching places with "Manage Servers"
  • "Manage Servers" gaining the ability to import asc keys files without needing to open, copy-paste their contents. Makes sense in the future because other nymservers provide keyfiles without posting their keys on the server webpage like nym.now.im
  • In the "Send Message" tab under the End-to End section, the keys in the keychain could appear in a drop-down menu or alternatively auto-searched as the user types in an email associated with a key they want to send to. Same for the Signer field.
dau added a comment.EditedJul 18 2015, 1:39 AM
In T367#5960, @HulaHoop wrote:

Safe defaults are always the smart thing to do, so I agree that the current behavior should be as it is out-of the box, but for more flexibility can you make direct access to the user keyring an option that powerusers can enable? To make sure no mistakes are made, Nymphemeral could show a confirmation prompt warning the user not to use the option unless they know what they're doing.
Upgrading Server Manager to handle this still works, I'm just putting ideas out there :)

That can be done, but I think that at the moment I'm going to give more priority to the development of the "keyring manager".

In T367#5961, @HulaHoop wrote:

No keys appear in the Ephemeral key field. Is this supposed to happen? I just typed in a random word and it seems to work.

Maybe I should find a better word for that, but that's it! As if it was a passphrase. Just a random string.

  • IMHO it feels more intuitive to click "Start Session" right under the address and passphrase fields, switching places with "Manage Servers"

When I designed it, I was looking as if everything was part of a process that leads to starting the session, like:

  1. Type address and passphrase
  2. Import the server's key
  3. (Not) Use the GPG agent
  4. Choose an output method
  5. Start session

But you are right. After the first login, you will rarely import keys and will probably have the same options for the agent and output method every time. I am going to think of a better placement of those items.

  • "Manage Servers" gaining the ability to import asc keys files without needing to open, copy-paste their contents. Makes sense in the future because other nymservers provide keyfiles without posting their keys on the server webpage like nym.now.im

That's convenient. Thanks :) I am going to add that feature once I start coding the keyring manager.

  • Nymphemeral main window having a checkbox option to remember typed addresses for convenience.
  • In the "Send Message" tab under the End-to End section, the keys in the keychain could appear in a drop-down menu or alternatively auto-searched as the user types in an email associated with a key they want to send to. Same for the Signer field.

I wish I had already done that, but I will probably have to use something more powerful than tkinter. I could not find a neat way of doing that.

The data does not even need to be "remembered" because they are already in the keyring. That can be easily retrieved. The problem is designing a nice interface that display that information with tkinter :(

I will continue testing and keep you updated.

Thanks HulaHoop!

dau added a comment.Jul 20 2015, 7:47 PM

Hi HulaHoop!

Would like to let you know that I am about to release 1.3.4, which consists of things we've been discussing. I'm still not able to implement everything you suggested, but I will when I can. What is important about 1.3.4 is that it updates nymphemeral to be used on Whonix. You can take a look at the latest commits.

If you can, take a look at the issues I opened. We still have not defined the priority of them and we cannot promise which and when will be fixed. Please, take a look and see if there is something missing.

Note that it's been a while since I merged things to the master branch. The reason for that is that nymphemeral has been updated to use pyaxo 0.4, but we are still updating the server. Once we have the new version running on nym.now.im, I'll merge the releases.

Thanks!

Great and thanks for considering my suggestions.

What is the status of this ticket?

dau added a comment.Feb 10 2016, 7:09 PM
In T367#8079, @Patrick wrote:

What is the status of this ticket?

Hi, I apologize for being away for such a long time. The changes I made to nymphemeral with help from @HulaHoop to add Whonix support are present since the 1.3.4 release. However, I have not packaged it for Debian yet. I remember I started learning how to do that but it seemed more complex than I expected and I postponed that, still indefinitely. I have been making some minor changes to nymphemeral, but I have been working on other things as well.

Would you point me to the right direction on how to package nymphemeral? I specifically remember reading that I would have to first write a test suite for nymphemeral (which I am currently learning), but I also found a lot of divergent information and I am not sure, for example, if that test requirement is true. Do you have a nice material that can help me learn how to package for Debian?

Thanks!

I never read that a test suite is required for a package to be accepted
into Debian. Unfortunately, I don't know what the best more straight
forward guide into Debian packaging [of a python project] is.

whonix-setup-wizard is a python package maintained by Whonix.

https://github.com/Whonix/whonix-setup-wizard

It has only one dependency, genmkfile that is unfortunately not yet
packaged for Debian but hopefully sooner than later.

https://github.com/Whonix/genmkfile

You can see there the /debian sub folder. You could copy and paste it
as a template and then modify for nymphemeral.

https://github.com/Whonix/whonix-setup-wizard/tree/master/debian

Debian package build instructions are included in the project's readme.

https://github.com/Whonix/whonix-setup-wizard/blob/master/README.md

It produces a 100 % lintian (including --pedantic) warning free
package. [Lintian is the package quality checker by Debian.] And
reasonable absence of lintian warnings this is a condition for packages
to be accepted in Debian.

There surely are other ways to package python based software for Debian.
Look into a few python based software packages and download their
sources. (apt-get source pkg-name)

There is also the Debian mentors mailing list, which helps with
packaging questions.

https://lists.debian.org/debian-mentors/

I suggest to try to reach out to the Debian Anonymity Tools Team for help.

https://tracker.debian.org/teams/anonymity-tools/

dau added a comment.Feb 10 2016, 8:48 PM
In T367#8102, @Patrick wrote:

I never read that a test suite is required for a package to be accepted
into Debian. Unfortunately, I don't know what the best more straight
forward guide into Debian packaging [of a python project] is.
whonix-setup-wizard is a python package maintained by Whonix.
https://github.com/Whonix/whonix-setup-wizard
It has only one dependency, genmkfile that is unfortunately not yet
packaged for Debian but hopefully sooner than later.
https://github.com/Whonix/genmkfile
You can see there the /debian sub folder. You could copy and paste it
as a template and then modify for nymphemeral.
https://github.com/Whonix/whonix-setup-wizard/tree/master/debian
Debian package build instructions are included in the project's readme.
https://github.com/Whonix/whonix-setup-wizard/blob/master/README.md
It produces a 100 % lintian (including --pedantic) warning free
package. [Lintian is the package quality checker by Debian.] And
reasonable absence of lintian warnings this is a condition for packages
to be accepted in Debian.
There surely are other ways to package python based software for Debian.
Look into a few python based software packages and download their
sources. (apt-get source pkg-name)
There is also the Debian mentors mailing list, which helps with
packaging questions.
https://lists.debian.org/debian-mentors/
I suggest to try to reach out to the Debian Anonymity Tools Team for help.
https://tracker.debian.org/teams/anonymity-tools/

Thanks @Patrick, I will study those links!

So far, the easiest way to install nymphemeral is:

apt-get install python-dev python-tk
pip install nymphemeral

I'll let you know how the packaging goes.

Thanks!

As soon as TUF for python is packaged for Debian I will document how to install nymphemeral with it.

Background: TUF provides a secure updater framework that guarantees package and update integrity. It is now integrated in many alternative installer/updaters that traditionally had poor to no security. Using it with pip will give the same security benefits as if it was available under Debian's apt.

dau added a comment.Aug 20 2016, 3:20 AM
In T367#9898, @HulaHoop wrote:

As soon as TUF for python is packaged for Debian I will document how to install nymphemeral with it.
Background: TUF provides a secure updater framework that guarantees package and update integrity. It is now integrated in many alternative installer/updaters that traditionally had poor to no security. Using it with pip will give the same security benefits as if it was available under Debian's apt.

@HulaHoop, thank you! That is very interesting.

Please let me know if there is anything I can help you with.

HulaHoop closed this task as Wontfix.Aug 16 2018, 5:42 PM

Non-Debian dependencies and non materialization of TUF PyPi makes a secure way to obtain this package impossible.