OmniMix • Tutorial • Nyms • Setting Up A Nym Account

All preparations have to be done within the 'Nym Configurator' window, which appears by clicking the 'Configurator' button at the 'ModNym' tab.

Before using it for the first time, you have to import the nym server and cypherpunk remailer keys (used for your nym's reply blocks) into OmniMix. As we already loaded all updates from the Internet, current versions should be present in their respective folders (defined in 'State Int' - 'Nym' - 'Server Keys Dir' resp. 'State Int' - 'Cypherpunk' - 'Keys').

Go to the 'Nym Routing' tab, right-click into the 'Keys - Server' list and select 'Import Key(s)' from the context menu.

Provided that the presets are still valid, all nym server keys that now have to be imported one by one, can be found at the 'nym\' subdirectory, named 'remailer-key@...'.

At the time of this writing there unfortunately isn't even one of the nym servers supporting the abovementioned convenient direct download of relevant data (server key and aliases in use) by OmniMix using the Finger protocol, which could be automated and, by using Tor, performed anonymously. So you have to retrieve the server keys ('remailer-key@...') and alias lists ('list@...') of interest manually by mail. By sending an (empty) mail to the 'remailer-key' resp. 'list' mailbox of the concerning nym server (e.g. 'remailer-key@nym.mixmin.net' and 'list@nym.mixmin.net') you cause that host to create a response mail to your hopefully valid 'From' address containing the requested data. Copy the PGP key you get (including the '-----BEGIN PGP PUBLIC KEY BLOCK-----' / '-----END PGP PUBLIC KEY BLOCK-----' lines) to the clipboard and add it to the 'Keys - Server' list by selecting the context menu entry 'Paste Key(s)'.

Now it's time to import the remailer keys into the 'Keys - Remailer' list. As keys expire and are replaced, this has to be done from time to time to keep your system functioning. But you may have to clear the remailer list (context menu 'Delete All Keys') before repopulating it with the current set of keys.

Thereafter right-click into the (empty) list, select 'Import Key(s)', in the file selector window visit the 'dat' folder and finally double-click on the latest Cypherpunk keys file (e.g. 'cyp_keys*.asc' like 'cyp_keys_090822.asc', where the timestamp of download was automatically added to the filename).

All found keys are shown in a separate dialog box, then added to the remailer list.

You're now prepared to set up your first nym.

Double-click at the key of the nym server you intend to use (or select it and press the 'Nym' button) in order to copy it to the 'Nym Server' line below ('[...] Bananasplit Pseudonym Server ... ' once was a good, reliable choice, which sadly at the time of this writing has become your only choice).

Then select the 'Accounts' tab, where you have to enter an 'Alias' (e.g. 'whopper'), which becomes the mailbox part of your mail address, and a 'Name' ('Jack the Whopper') for the new nym. After a click on the 'Add' button your new nym appears in the 'Nym Accounts' list, and all required random passphrases are set as well.

Next is to create a key pair for your nym.

The predefined key parameters (2048 bit RSA key, 256 bit AES cipher and 256 bit SHA hash) already provide maximum security, at least as far as cryptographers currently see it. So don't change key parameters unless you have a good reason to do so!

With the key 'Name' selector you define the descriptive 'display name' part of your nym key's ID similar to a mail address. Though this setting doesn't affect the functionallity of your nym account, the key ID inheres the status of a visiting card, if the public key gets transferred to your communications partner, which is why you nevertheless should have an eye at it. In our example with 'nym.mixmin.net' as the server, 'whopper' as the alias, and 'Jack the Whopper' as the name defined for your nym account you have the following options to assemble the ID of your nym's key:

•	None	You get ' <whopper@nym.mixmin.net>' with an ugly leading whitespace, which I wouldn't recommend.
•	Custom	This allows you to specify an independent term, e.g. 'Jack II.', in the field right to the selector, resulting in 'Jack II. <whopper@nym.mixmin.net>'.
•	Alias	With your nym alias the key ID turns into 'whopper <whopper@nym.mixmin.net>'.
•	Account	By selecting your account's full address you have 'whopper@nym.mixmin.net <whopper@nym.mixmin.net>' as the key ID.
•	Name	Using the account's name defined above in the 'Nym' parameters' 'Name' field the key ID becomes 'Jack the Whopper <whopper@nym.mixmin.net>', which I'd recommend.

Bear in mind, that it isn't allowed to change this parameter if a key for the concerning nym account already exists.

After configuring all the parameters store that intermediate result by clicking at 'Modify'. Then generate the keypair with the 'Create Key' button. That process can take up to several minutes dependent on the chosen algorithm and the size of the key.

The result can afterwards be examined at the 'Keys' tab.

PGP keys and PGP signed messages contain information about the moment of their creation resp. signature in Coordinated Universal Time (UTC) format with a resolution of one second, not including time zone data. As with that knowledge it might be easier for an adversary to compromise the owner of a nym account or sender of a nym message, OmniMix allows to alter those timestamps in different ways by either adjusting them to midnight or a random moment of one of the previous days.

Those methods can be selected at the 'Gpg' / 'Time' tab, separately for nym resp. WME related key creation and message signature timestamps. You only have to rule out the obviously impossible combination of a signature timestamp older than the creation time of the corresponding key. In this respect setting 'Key Creation' to 'Day-2' and 'Message Encryption' to 'Day-1' would be a safe choice.

Read more on this topic, especially about important implications of its implementation, in the chapter 'Some important issues' below.

The nym command switches have the following meaning:

•	AckSend	You get an automatic acknowledgment each time a message is successfully remailed for your alias.
•	SignSend	Any outgoing mail you send through the nym server is automatically signed by the server's PGP key.
•	CryptRecv	The messages you receive for your alias are encrypted with your nym's public key before being forwarded. Disabling public-key encryption will reduce your privacy.
•	FingerKey	It allows people to obtain your nym's public PGP key by fingering your mail address, so that they are able to send encrypted messages to you. This option is very important, as otherwise all incoming messages are in clear and can be read by anyone. With 'cryptrecv' activated, they would only be encrypted at the nym server. OmniMix takes care of messages multi-encrypted by the sender and the nym server and decodes them accordingly.
•	FixedSize	All messages you receive will be split or padded to exactly the same size (roughly 10K). This padding will take place outside the public key encryption, and so will only be useful if you also use shared-key encryption. If you do use symmetric shared-key encryption, however, and you really should, having all your messages be the same size will make it significantly harder for anyone to do traffic analysis on mail to your nym. There seem to be server-side problems with corrupted messages if this feature is activated. That's why you have to reckon with unrecoverable replies and OmniMix in principle currently doesn't support the final (asymmetric) decryption of such fragmented messages! Unfortunately it has to be recommended to deactivate this actually very important option until there's a cure.
•	Disable	This switch allows you a temporary deactivation of your account.

It's possible to override the parameter settings for 'acksend' and 'signsend' later on individually on a per-message basis by adding a 'Nym-Commands' header.

Then, though the default routing of your nym's replies with the 'alt.anonymous.messages' newsgroup as their (intermediary) destination combined with two mail2news gateways for posting there and no further Cypherpunk remailer involved is a good start, you may want to implement a different routing strategy. To do so you have to return to the 'Nym Routing' tab.

First determine the 'Destination' of the replies, that are sent to your nym account. This may be either an e-mail address or a list of them, or it's one or several newsgroups. Provided you go the newsgroup way, the declaration of one or more mail2news gateways (e.g. 'mail2news@dizum.com, mail2new@m2n.mixmin.net, mail2news@anon.lcs.mit.edu') is recommended, so that you're not dependent on the posting capability of the final remailer of your reply chains. If otherwise the destination is an email address, this parameter is simply ignored.

I'd have a queasy feeling knowing that my mail address is forever part of an anonymous message, no matter how secure the encryption algorithm it protects ought to be. As cryptoanalysis progresses that method may be broken all of a sudden. That's why delivery to a mail address has to be abandoned irrespective of the security of the remailer chain you use.

By sending your reply messages to a well-populated newsgroup destined for that purpose, which 'alt.anonymous.messages' is, they can hide among a lot of others. When downloading all the group's messages nobody can find out which are yours. And as news articles are forwarded within the Usenet, you're not committed to a single server to get them from, at best anonymously through the Tor network. A lot of reasons to choose the newsgroups routing.

If you decide to post replies of your nyms to different newsgroups, you have to bear in mind, that all of them have to be available at the news server(s) you use for retrieval.

Of course you have to involve remailers when sending the messages directly to your mail address, as otherwise your anonymity would definitely be gone. But there's been a lot of debate about the benefits of a (Cypherpunk = Type 1) remailer chain between the nym server and a newsgroup destination. On one hand a remailer chain may further secure your anonymity by making it harder to correlate messages leaving the nym server with those posted at the respective newsgroup destination, on the other hand you buy that increased safety level with a few disadvantages. As remailer chains may break with remailer failures, key changes etc., which can make transmission very unreliable, it's advisable to use several of them concurrently. Then, based on the reply copies coming in, you constantly have to check how many of your nym's reply chains fail, and in case you're running out of working reply chains you have to update the routing configuration. All that work is irrelevant when doing without a remailer chain. Then there's one single message reliably posted directly from the respective nym server location to the newsgroup, ready to be downloaded by the nym holder from any Usenet server holding that group.

If you don't intend to go the most reliable way of doing without further remailers in the reply chain you finally have to create a few of those chains for your nym. Starting with an empty 'Reply Chain' list copy remailers from the 'Keys-Remailer' list above one by one simply by double-clicking the entries of your choice. Rearange the remailers added to the 'Reply Chain' list by using the 'Up'/'Down' buttons, delete them from the list with a double-click on the respective entry. The already mentioned color coding of the remailer list entries (necessary capabilities at the 'Type' column, reliability at the 'Key ID column) helps you to choose a suitable chain. With a click on the '>' button another (empty) reply chain is shown, which then can be populated as well. The more reply chains you define, the higher the chance, that at least one of them works and the reply messages get delivered. Depending on the chain lengths it's recommended to set up at least 3 of them. In order to delete a reply chain simply remove all of its list entries. Don't forget to save all those settings by another click on the 'Modify' button at the 'Accounts' tab. This also assigns fresh slot numbers to all newly added or modified reply chains, which are used for the creation of individual passphrases and as identifiers to discern broken chains, which no longer deliver replies.

After your work is done, close the 'Nym Configurator' window and return to the 'ModNym' tab of the main window, where the sending of configuration messages takes place.

As reply block test messages and nym configuration mail are sent to OmniMix's normal SMTP port, it's necessary to have a nym related account on the 'User' list with the according access data specified at the 'Send' tab of 'SetNym'. With the account 'Nym' already predefined for this purpose you should be able to send a configuration request right away without being rejected.

However, it may be advisable to test the unattached reply blocks at first to check whether the communication chain works without being influenced by additional nym server problems. The steps are the same as sending a configuration request. Only select the nym account from the list, the number of the reply block you want to test, from the task pulldown menu 'Test the selected reply block' and click onto the 'Send Msg' button. In order to send a real config message, you have to tell OmniMix, which kind of message it is. So select from the pulldown list, whether you intend to send a command to create, modify (e.g. update the remailer chain of one or more reply blocks) or irretrievably delete the selected nym account before you press the 'Send Msg' button.

Now you have to wait until you get the reply, which comes either directly to your mail account or has to be collected from the specified newsgroup.

The chapter 'Receiving nym messages' below tells you everything about how to get notifications coming from your nym server.

Once you got an answer from your nym's host, the newly created nym account has to be activated by sending an empty message to the address declared in the reply, of course also anonymously. Simply create a reply message within your email application and send it through OmniMix. As every mail destined for a nym server gets its special treatment such a confirmation message is reduced to nothing but the recipient's address and then forwarded anonymously. Now your task is completed and with the arrival of this mail you have an active nym account, which may be confirmed by another reply from the nym server.

Different from Type 2 remailers, where the operator defines the message pool size and thereby the degree of anonymity this hop provides, with Type 1 messages you yourself have to specify the amount of time, for which the message stays at each remailer before being forwarded. But the resulting anonymity only depends indirectly on that latency, as it's also influenced by how much the router is frequented. To reduce that uncertainty and stay on the safe side, set the overall latency of your reply chains to the largest value you're willing to tolerate. This period of time then is automatically distributed to the single stages of each reply chain by setting the 'Latent-Time' value accordingly. For that purpose OmniMix calculates on a random basis commonly used, inconspicuous discrete values, so that e.g. 120 minutes may be assigned to 3 stages like '0:40'-'1:00'-'0:20' or '0:50'-'0:30'-'0:40'. With this strategy there's no chance to estimate the total delivery time based on a single value.