Search the FAQ Archives

3 - A - B - C - D - E - F - G - H - I - J - K - L - M
N - O - P - Q - R - S - T - U - V - W - X - Y - Z - Internet FAQ Archives

APAS Anonymous Remailer Use [FAQ 7/8]: Nyms

( Part1 - Part2 - Part3 - Part4 - Part5 - Part6 - Part7 - Part8 - MultiPage )
[ Usenet FAQs | Web FAQs | Documents | RFC Index | Zip codes ]
Posted-By: auto-faq 3.3 (Perl 5.004)
Archive-name: privacy/anon-server/faq/use/part7
Changes: 1.11 2001/04/20 15:47:36
Posting-Frequency: monthly
A list of the recent changes to the FAQ list will appear
next week.
A how-to-find-the-FAQ article appears every Wednesday.

See reader questions & answers on this topic! - Help others by sharing your knowledge
Subject: APAS Anonymous Remailer Use [FAQ 7/8]: Nyms

This is the seventh of eight parts of a list of frequently-asked
questions and their answers regarding anonymous remailer use.  This
part introduces nyms.

This FAQ is provided "as is" without any express or implied
warranties.  While every effort has been taken to ensure the accuracy
of the information contained in these message digests, the maintainer
assumes no responsibility for errors or omissions, or for damages
resulting from the use of the information contained herein.  This FAQ
is provided for information only; reference to a Web page does not
constitute endorsement of that page's content.

The following topics are in this FAQ:

   1: [FAQ 7.1] How is a nym different from anon. posting?
   2: [FAQ 7.2] How do I get a particular nym server's key?
   3: [FAQ 7.3] Why do alt.anonymous.messages subjects look random?
   4: [FAQ 7.4] Why are nyms such a bitch to set up? 
   5: [FAQ 7.5] How can I ensure nym creation goes smoothly?

Subject: [FAQ 7.1] How is a nym different from anon. posting? A nym account is like a forwarding email address except that it offers the additional feature of anonymity. Not even the nym server operator knows who you are! You set up an account with one of the three nym servers (see #3.2 and #7.2) by sending a config message. In it you provide a newly created PGP public key for your chosen nym (say,, some configuration options (like +signsend, -fingerkey, +nobcc, etc...) and finally a reply block so the nym server can send any replies back to you through a chain of remailers of your own choosing, or if you prefer, to a newsgroup like alt.anonymous.messages or alt.anonymous. Nyms are different than just sending through anonymous remailers. When posting through a simple remailer or chain of remailers there is no way for anyone to reply to your message via e-mail unless you include a repliable address such as a Hotmail account in the body of the message, or signature. Additionally, most remailers do not allow any type of From: header to be posted, so your message will appear to come from 'Anonymous', 'Anonymous Sender' or similar. When posting through a nym account, the reply-able nym address remains intact in the message headers. Reply-able AND anonymous! Setting up a nym can be done manually (with PGP and a text editor) or through software like JBN or Private Idaho. Either way you should read up on the process before trying your hand at it. Here are some very good tutorials about nym creation: Nym creation and use for mere mortals <> Using JBN: <> Also: <> <>
Date: 21 Mar 2001 06:21:16 GMT From: (Computer Cryptology) Subject: [FAQ 7.2] How do I get a particular nym server's key? Message-ID: <999h8s$b99$> Summary: Nym servers have separate addresses for keys. [This text is the original FAQ entry updated with a summary of the thread with "Subject: Re: ... keys for <> ...?", particularly the post with Message-ID above.] The method used for remailers--sending an email message to the remailer address with "Subject: remailer-key"--won't work with the config and send addresses of nym servers. These addresses (e.g., <> or <>) will reject any plaintext message or any encrypted message that does not begin with "Config:" (cf <>). Each of the nym servers has a separate email address that responds to remailer-key requests. Send a blank email message to an address like this: <remailer-key@your.favorite.nymserver> The addresses used to check the keys on the CC site are as follows on the date of this FAQ: nym <> redneck <> xgnym2 <> (Check <> for changes.) Consider when choosing a nym server: <NYM.ALIAS.NET> hasn't changed it's nym key since 1996! Draw your own conclusions about whether this key might have been compromised since that time. <REDNECK.GACRACKER.ORG> uses it's own <> to send outgoing nym mail and that remailer is middle. N.A.N and <NYM.XGANON.COM> send through their respective local remailers, and both these are NOT middle.
Date: Tue, 10 Apr 2001 18:58:46 GMT From: (Saddle) Subject: [FAQ 7.3] Why do alt.anonymous.messages subjects look random? Message-ID: <> Summary: Some subjects are encrypted MD5 hashes of the real subject. [The text below is a summary of posts by "Ahab", Saddle <> and Doc.Cypher from the thread "RANDOM STRINGS" containing the "Message-ID:" above.] On Mon, 9 Apr 2001, "Public <Anonymous_Account>" <> wrote: > Most of the messages in <alt.anonymous.messages> are PGP encrypted > but what are the random strings of numbers and letters which appear > in the subject line? Some people configure their nym accounts to have incoming email messages delivered to newsgroup <alt.anonymous.messages> (AAM) instead of to an email address. To find their messages among the many in AAM without disclosing their identity, the "Subject:" line contains information encrypted to a key only they know. This process is automated if you use Jack B Nymble (JBN). A freeware DLL (PSESUB32.DLL) called the Esub plugin adds encrypted subject scanning support to JBN versions 2.1.d and later, and Esub support to Reliable versions 1.0.1 and later: <> RProcess included the Esub plugin with JBN2.1.4. An more detailed explanation is in the Reliable User's Manual: <> According to the Reliable User's Manual, the "random" strings of numbers and letters which appear in the "Subject:" line are encrypted MD5 hashes of the final "Subject:" line. That is, the remailer client calculates an MD5 hash from the "Subject:" line(which might be, e.g., "ATTN: Dave") in the final or hash headers (below the "##"). This MD5 hash that results from this calculation is likely to be unique to that particular "Subject:" line. The remailer client then encrypts the MD5 hash using conventional (symmetric) encryption, specifically IDEA. The encryption and decryption key is the passphrase given for the "Encrypt-Subject:" directive.
Subject: [FAQ 7.4] Why are nyms such a bitch to set up? Actually they aren't a bitch to set up. The difficulties usually begin when automatic client software is being used with dead remailers, stale remailer keys, remailer chains that are broken, or other factors that could be determined in advance by the user if he took the time to verify that these things were not going to be problems before trying to start setting up a nym. That is to say: + If you use stale remailer keys, the remailers will not be able to process your message. + If you use dead remailers, either when sending to nym, or in your reply block chain, then your nym will not be setup at all, or even worse, it will appear in the list as created but not work and not return any clues as to why not. + If you test your reply block before trying to use it with a nym, and it does not work for you, there is no way it will work for the nymserver either. But since you didn't bother to create it by hand and test it yourself you have no way of knowing whether it works or not. Now you can see you have a list of possible problems that may be working alone or in combination against you. But since you didn't verify each one to be non-problematic in and of itself, you have no way to know why your nym isn't established or not working. This is the "bitch" and it is of your own creating. Of course, automatic nym creation software knows nothing about the current state of the remailer network, which remailers have changed keys recently, which remailers have problems chaining to other remailers, etc. So by using it without independently verifying what it is doing for you, you place yourself at its mercy. Don't blame the software since it rarely if ever makes technical errors when creating nyms.
Subject: [FAQ 7.5] How can I ensure nym creation goes smoothly? Here is a list of things you should do before attempting to assemble a nym creation message, whether by hand or using creation client software: + Verify that each remailer you intend to use is working. Check the stats pages to see how they are doing. + Look at the broken chains reports. Don't use remailer chains that are known to be broken. + Make sure you have the current remailer keys. + Send yourself at least one message through each remailer you intend to use. If you don't get them back find out why and fix the problem. + Once you are sure each remailer you intend to use is working individually, decide on which ones you will use in your chain to send your nym creation message into the nym server. Construct a chained remailer message using these remailers with your own address as the recipient and send it off. If it comes back, that chain is verified to be working for you. If not, find out why or select another chain and test again. + Repeat the above for the remailers you will be using for your reply block chain. If they are the same as the ones you use above, you are done testing. NOW you can create your nym using automatic client software and at least you'll know that if the nym doesn't work the problem lies between the nym server and the first remailer in your reply block chain, or some enhanced nym feature you selected to use is tripping the process up somehow. Avoid using these at first until you get a working nym, even if it is only a throwaway test nym. Then move on to the more complex configurations. ------------------------------ End of faq.7 Digest *******************

User Contributions:

Comment about this article, ask questions, or add new information about this topic:

Part1 - Part2 - Part3 - Part4 - Part5 - Part6 - Part7 - Part8 - MultiPage

[ Usenet FAQs | Web FAQs | Documents | RFC Index ]

Send corrections/additions to the FAQ Maintainer: (Computer Cryptology)

Last Update March 27 2014 @ 02:12 PM