Page MenuHomePhabricator

Nymserver Documentation
Closed, ResolvedPublic

Description

This ticket is for nymserver documentation improvements.

Details

Impact
Normal

Related Objects

Event Timeline

HulaHoop created this task.Jul 11 2015, 8:41 PM
HulaHoop claimed this task.
HulaHoop raised the priority of this task from to Normal.
HulaHoop updated the task description. (Show Details)
HulaHoop added a project: user documentation.
HulaHoop set Impact to Normal.
HulaHoop added subscribers: HulaHoop, dau.
dau added a comment.EditedJul 12 2015, 8:40 PM
In T367#5918, @HulaHoop wrote:

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

Awesome! Looks good :)

I'd like to suggest that this section be split to have its own dedicated section, like wiki/nymservers. It is not a big deal, but although we recommend using Mixmaster to communicate with nym servers, they are totally independent. The only thing you need to manage your nym is sending messages to the nym server, via your SMTP server, Mixmaster or even your personal email (not recommended, but would still work).

I would like to know if we should emphasize the use of GUIs (like KGpg) by giving all the examples using them, but leaving the command line instructions in textboxes that can be expanded if the user prefers to use them (not sure if can be done with Wikitext).

Also, there is a statement that caught my attention:

Note that the protection provided by Mixmaster is not of importance here because everything is done behind Tor.

I am not sure in which aspect it was directed to, but I believe we should try to explain it better or at least link some references.

The user should know that the messages would kind of follow this path whonix -> tor circuit -> mix network -> nym server. After Tor's last hop, it depends on how Mixmaster encrypts the data that is sent to the mixes.

Also, we should try to discuss latency as well. I still have not found a conclusive study on Mixmaster vs Tor, but against a very powerful adversary, Mixmaster's high-latency can still provide some anonymity when it comes to time correlation attacks, where Tor's low-latency wouldn't. On nymphemeral's documentation we (rxcomm and I) instruct the users to use Mixmaster via Tor. We believe that the user can use all of their advantages by doing so.

Regarding chains: I believe that choosing a short mix chain will decrease the latency, but decrease the anonymity level as well.

Let me know what you think.

Thanks!

I'd like to suggest that this section be split to have its own dedicated section, like wiki/nymservers. It is not a big deal, but although we recommend using Mixmaster to communicate with nym servers, they are totally independent. The only thing you need to manage your nym is sending messages to the nym server, via your SMTP server, Mixmaster or even your personal email (not recommended, but would still work).

Created new page at https://www.whonix.org/wiki/Nymservers

Ok I'll add the part about sending choices in the introduction, to give the user the whole idea of how it works.

I would like to know if we should emphasize the use of GUIs (like KGpg) by giving all the examples using them, but leaving the command line instructions in textboxes that can be expanded if the user prefers to use them (not sure if can be done with Wikitext).

Sure. I didn't know if some of the operations like signing and encrypting simultaneously were supported by the GUI so I put some of this with some of that. Your format of the instructions would be the proper way so feel free to add both.

I am not sure in which aspect it was directed to, but I believe we should try to explain it better or at least link some references.

Yes there should have been a reference. It was a statement made by Roger, one of Tor's chief researchers who worked on remailer networks in the past:

http://www.mail-archive.com/liberationtech@lists.stanford.edu/msg00022.html

The user should know that the messages would kind of follow this path whonix -> tor circuit -> mix network -> nym server. After Tor's last hop, it depends on how Mixmaster encrypts the data that is sent to the mixes.

Yes. I'll add it too.

Regarding chains: I believe that choosing a short mix chain will decrease the latency, but decrease the anonymity level as well.

I am thinking we should still keep chains 3 or 4 hops long just to blend in with most traffic not because of the anonymity benefit. Should I just remove this sentence? I was just explaining the concept.

How would attachments work? Are they the same instructions as sending a message - Would a user need to always sign and encrypt attachments to the Nymserver?

(Mixmaster takes an -a filename parameter to send an attachment.)

dau added a comment.Jul 13 2015, 7:55 AM

Created new page at https://www.whonix.org/wiki/Nymservers
Ok I'll add the part about sending choices in the introduction, to give the user the whole idea of how it works.

Thanks!

Sure. I didn't know if some of the operations like signing and encrypting simultaneously were supported by the GUI so I put some of this with some of that. Your format of the instructions would be the proper way so feel free to add both.

I tried to use KGpg where I could, but there were some things that I could not find out how to do. I never used KGpg :/

Yes there should have been a reference. It was a statement made by Roger, one of Tor's chief researchers who worked on remailer networks in the past:
http://www.mail-archive.com/liberationtech@lists.stanford.edu/msg00022.html

Oh, thanks!

I am thinking we should still keep chains 3 or 4 hops long just to blend in with most traffic not because of the anonymity benefit. Should I just remove this sentence? I was just explaining the concept.

I agree that around 4 hops should be enough to provide some anonymity, but not totally agree with the rest. I will first try to search for more information on that before actually saying what I'm thinking. I guess that sentence can stay there.

In T374#5923, @HulaHoop wrote:

How would attachments work? Are they the same instructions as sending a message - Would a user need to always sign and encrypt attachments to the Nymserver?
(Mixmaster takes an -a filename parameter to send an attachment.)

I never sent attachments before. I will answer that once I find out. (That's why I haven't answered that new issue you opened)

Well, here is what I have for the instructions sub-section on Nymservers. I changed it quite a bit, but it should have most of what you currently have there. Can you take a look to see if what I wrote is correct?

=== Instructions ===
The process broken down into steps:

# Import Nymserver's Key
# Prepare Nym Request
# Send Request to Nymserver
# Retrieve Messages from Newsgroup
# Decrypt Messages
# Send Mail with Registered Nym
# Reconfigure Nym

'''Conventions'''

For these instructions the example '''nym@server''' will be used. You
must change them to suit the nym choice you make and the domain name
of the Nymserver.

This example is for '''mixnym.net''' but the guide is still generic
and relevant to apply to any other Zax-type Nymserver. For a
selection of Nymservers see this
[https://www.whonix.org/w/index.php?title=Mixmaster&stable=0&shownotice=1&fromsection=Other_Useful_Topics#Zax_Server_List list].

It is important to know which of the address you are going to use
when sending messages to the Nymserver:

'''config@server''': creation or configuration requests, to create
and manage your nym

'''send@server''': send requests, to send messages from your nym to
other people

'''url@server''': url requests, to retrieve an HTML page

==== Import Nymserver's Key ====

A Nymserver's key is usually on their homepage, but sometimes it may
only be available from the PGP keyservers. In that situation, open
KGpg's keyserver dialog, search for it and then import from there.

1. Download the '''mixnym.net''' Nymserver key with curl to home folder.

    <pre>
    curl -o key.asc http://is-not-my.name/key.asc
    </pre>

2. Check fingerprints/owners without importing anything.

    <pre>
    gpg --with-fingerprint key.asc
    </pre>

Always check the fingerprint for yourself. The output at the moment
is:

    <pre>
    pub  4096R/0xFF4DB66014D0C447 2010-05-05 URL is-not-my.name (URL Retrieval address for Is-Not-My Nymserver) <url@is-not-my.name>
          Key fingerprint = 94F2 04C2 8BF0 0937 EFC8  5D1A FF4D B660 14D0 C447
    </pre>

3. If it looks good, import with GPG:

    <pre>
    gpg --import key.asc
    </pre>

==== Prepare Nym Request ====

===== Create a Key Pair =====

Create a new key pair for '''nym@server''':

    <pre>
    KGpg -> Keys -> Generate Key Pair...

    Name: John Doe (or any alias of choice)
    Email: nym@server
    RSA key of 4096 bits

    Enter passphrase for key. OK.
    </pre>

Equivalent in the command line:

    <pre>
    gpg --gen-key
    </pre>

===== Export Public Key =====

This will extract the newly generated key from your keyring and store
it in a text file. In the following example, I've named that file
<code>pubkey.txt</code>:

    <pre>
    KGpg -> Select key -> Export Public Key -> File -> pubkey.txt -> OK
    </pre>

Equivalent in the command line:

    <pre>
    gpg --armor --export nym@server > pubkey.txt
    </pre>

===== Configure Additional Options =====

You only need to perform this step if you want to configure
additional options on your nym, such as Subject Identification or
Symmetric Encryption. For each option, prepend a line to the
<code>pubkey.txt</code> file using the format:

    <pre>
    option: setting
    </pre>

Caps are unimportant in the option name, but are sensitive in the setting.

The Nymserver parameters specified here are optional.
<ref>https://groups.google.com/forum/#!topic/alt.privacy.anon-server/f3H4Xw5j2LI</ref>
You can set them now or change them in the future as its detailed on
Reconfigure Nym.

'''Fixed (Plaintext) Subject'''

Choose some unique keyword as a '''Subject''' to be able identify the
Nymserver reply on the Newsgroup with the <code>subject</code>
option. Using a fixed subject is convenient, but anyone will be able
to link all the messages for a nym since they all have the same
subject.

'''Hashed Subject'''

A better alternative than the <code>subject</code> option is to use
hashed subjects (hSubs) by providing an hSub passphrase with the
<code>hsub</code> option instead.

An hSub is made of two parts, where the first is a random number and
the second part is the hash of that same random number and a
passphrase. As the hashing is a one-way function, no one can identify
the owner of the message. However, as you know your nym's hSub
passphrase, you can hash it with the random number of every message,
and if the result collides with the second part of the hSub, that
message was sent to your nym. You can read more on
[http://is-not-my.name/hsub.html this post] by Zax.

You can also use these options to set an hSub:
<code>hash-key</code>, <code>hash-subject</code>,
<code>subject-password</code>. These all mean the same as
<code>hsub</code>.

'''Symmetric Encryption'''

You can add a symmetric encryption layer by specifying a key with the
<code>symmetric</code> option.

'''Deletion'''

If you wish to delete your nym, you can send the following option and
setting: <code>delete: yes</code>.

'''Example'''

For example, to add an hSub passphrase of <code>panda</code>, you
should edit the <code>pubkey.txt</code> like this:

    <pre>
    hsub: panda

    -----BEGIN PGP PUBLIC KEY BLOCK-----
    <snipped>
    -----END PGP PUBLIC KEY BLOCK-----
    </pre>

You can add more than one option line to your request. However, you
should remember that some options might create conflicts. For
example, <code>subject</code> and <code>hsub</code> work differently,
but are used for the same purpose. You should choose either one or
the other.

===== Encrypt the Request =====

Now you must wrap <code>pubkey.txt</code>, the message containing your
additional options and public key, to the Nymserver. The
<code>pubkey.txt</code> file is the input for the following example
and the encrypted file will be created as
<code>pubkey.txt.asc</code>:

    <pre>
    KGpg -> Open Editor -> Open -> Select pubkey.txt

    Encrypt -> Select the Nymserver's key

    Options -> Allow encryption with untrusted keys -> OK

    Save -> Name the ciphertext pubkey.txt.asc
    </pre>

Equivalent in the command line:

    <pre>
    gpg --armor --encrypt --recipient config@mixnym.net pubkey.txt
    </pre>

You can ignore the warning about encrypting to an "untrusted" key and
select <code>y</code> for yes.

==== Send Request to Nymserver ====

Before sending the request, update remailer keys first. Its enough to
do this once a day
<ref>https://www.youtube.com/watch?v=dzbrFPO4604 LinuxJournal</ref>:

    <pre>
    mixmaster

    u)pdate stats

    *

    pick remailer letter (optional)

    q)uit
    </pre>

Send the encrypted file to the Nymserver with Mixmaster:

    <pre>
    mixmaster --mail -l *,*,* -c 2 config@mixnym.net pubkey.txt.asc
    </pre>

Where:

<code>-l</code> customizes the remailer chain length. The shorter the
chain the faster your mail will be sent and the more likely it will
make it through. Here we are using three random mixes:
<code>*,*,*</code>.

<code>-c</code> sends copies of the message. Here we are using
<code>2</code>.

If necessary, run Mixmaster from command line and check the remailer
chain list to see node availability and reliability stats and choose
accordingly.

That's it! The Nymserver decrypts the message, extracts your Nym's
email address from the supplied Public Key and processes it. Provided
that the Nym isn't reserved or already taken, you will receive a
confirmation message from the Nymserver, encrypted to your nym's key.

Note that the protection provided by Mixmaster is not of importance
here because everything is done behind Tor.
<ref>http://www.mail-archive.com/liberationtech@lists.stanford.edu/msg00022.html</ref>

'''Important'''

It's worth noting that this is the only message you will attach your
public key and the only one the server will ever accept from you
that's not signed by that key. From now on, you nym's digital
signature will prove your ownership of it. Examples on signing can be
found on Send Mail with Registered Nym and
Reconfigure Nym.

==== Retrieve Messages from Newgroup ====

Zax-type Nymservers deliver messages to the nyms via the
alt.anonymous.messages Usenet group (a.a.m). Anyone can access these
messages, but only the nyms can decrypt them, using their private
keys.

As explained previously, you can configure your messages to be
identified by subject. If you chose to use some kind of subject
identification from the previous section, you can go to
Use aam2mail to Fetch Replies.
If you did not configure that and wish to do so, you will have to
send a configuration message to configure a method of subject
identification. You will find an example on
Reconfigure Nym.

If you do not wish to use any kind of subject identification, the
default way to do this is by downloading and attempting to decrypt
every message posted on the Newsgroup. If it works, then the message
was sent to your nym.

===== Use aam2mail to Fetch Replies =====

1. Install git and clone aam2mail source. aam2mail requires no extra
dependencies.

    <pre>
    sudo apt-get install git
    git clone https://github.com/crooks/aam2mail
    cd aam2mail
    sudo python setup.py install
    </pre>


2. Configure aam2mail settings. Use the hsub you chose:

    <pre>
    mkdir aam2mail/etc
    echo 'panda' >> aam2mail/etc/subject_hsub
    echo 'news.aioe.org' >> aam2mail/etc/servers
    </pre>

3. Run aam2mail periodically to check for messages. There is an
expected delay of a few hours before getting replies.

    <pre>
    aam2mail --start
    </pre>

or

    <pre>
    aam2mail --restart
    </pre>

4. Replies will be downloaded by aam2mail to this path:
''/home/user/Maildir/new''. aam2mail does not decrypt messages for
you but retrieves them only.

Be sure to check for new messages regularly because messages on
Usenet accumulate beyond the fetch-limit and you may miss them.

==== Decrypt Messages ====

With the message saved to a file, open it with KGpg and decrypt it:

    <pre>
    KGpg -> File -> Open Editor -> Open

    Select the file with the message

    Decrypt -> Type your nym's key passphrase
    </pre>

You should see the plaintext of the message your nym received.

Congratulations for registering your first nym. Now you are ready to
use it for sending messages.

==== Send Mail with Registered Nym ====

To send messages to other people, it is very similar to the way you
did previously for the creation and configuration. KGpg could be used
for that:

    <pre>
    KGpg -> Open editor
    </pre>

Type the message:

    <pre>
    To: recipient@domain
    Subject: Example

    This is an example
    </pre>

At the bottom, encrypt it:

    <pre>
    Encrypt -> Select the Nymserver's key

    Options -> Allow encryption with untrusted keys -> OK

    Save -> Name the ciphertext as message.txt
    </pre>

Send it with Mixmaster, but this time to '''send@server''':

    <pre>
    mixmaster --mail -l *,*,* send@server message.txt
    </pre>

Notice that this time we did not send copies of the message. We
advised sending copies on the creation because after receiving the
first one, the server would ignore the others. In this case, if you
send copies, the server will send all of them to the recipient.

The recipient will receive a message from '''nym@server''' and they
can send a reply to that same address.

==== Reconfigure Nym ====

If you wish to add (or change) an option, all you can send another
message to '''config@server''', say <code>option.txt</code>, with the
option(s) you would like to add:

    <pre>
    hsub: passphrase
    </pre>

The message does not need to have a body, just headers. Remember that
after creation, all your messages should be signed before sending to
either '''config@server''' or '''send@server''':

    <pre>
    gpg --armor --encrypt --sign --recipient config@mixnym.net option.txt
    </pre>

Now you just need to send. As you are configuring your nym, you
should send it to '''config@server''':

    <pre>
    mixmaster --mail -l *,*,* config@mixnym.net option.txt.asc
    </pre>

=== Important Notes ===

==== Message Ordering ====

Due to Mixmaster's latency, it is possible that messages arrive out
of order. Your next messages might arrive earlier than the creation
message. If you do not get responses, you will have to send them
again, once the nym is created.

==== Public Mailbox ====

When someone send a message to your nym, the server will receive
it, encrypt to the nym and post on a.a.m so you can retrieve it. The
Newsgroup acts as a public mailbox. Everybody can see and download
the messages but only the intended recipient (your nym) can decrypt
it.

==== Multiple Nyms ====

If you use more than one nym, you need to remember to choose which
nym is going to sign the message, or always the same nym is going to
send the messages, and consequently only his messages will be
accepted. Remember that the only message accepted without a signature
is the creation message.

To specify the nym that is going to sign the message, use the
<code>--local-user</code> flag:

    <pre>
    gpg --armor --encrypt --sign --recipient send@server --local-user nym@server message.txt
    </pre>

==== End-to-End Encryption ====

The encryption layers discussed here will only protect data between
your nym and the server. It is advised that you use some kind of
end-to-end encryption (another layer) between you and the recipient
by encrypting the body of the message first, and then encrypting to
the server's key.

Keep in mind that the headers cannot be encrypted. An end-to-end
encrypted message would look like this:

    <pre>
    To: recipient@domain
    Subject: Subject

    -----BEGIN PGP MESSAGE-----
    <snipped>
    -----END PGP MESSAGE-----
    </pre>

After that you would then encrypt to the Nymserver, and it would look
like this in the end:

    <pre>
    To: send@server

    -----BEGIN PGP MESSAGE-----
    <snipped>
    -----END PGP MESSAGE-----
    </pre>

Pending:

Do not use Symmetric: passphrase. If you do, some (if not all) of the free hsub programs and routines will not be able to automatically find your messages. aam2mail supports the option but it complicates the operation. Its also not commonly used and therefore not a good choice for blending in.

I do not remember using the symmetric option, but I do not think that would cause these problems. Can you provide more info on that?

I do not know how Mixmaster's -c flag work, but I think it just sends a bunch of copies and all of them might be delivered. For that reason, I guess that we should instruct the user to use copies only for the creation, because the recipient might not like to receive duplicates. What do you think?

There were some parts of your new version that you enumerated the steps like 1) ... 2) ..., but they are kind of 'hard coded'. Isn't there a way to use something to keep track of an ordered list similar to how the section numbers are handled? I just think that using a hard coded index would add a little more work when updating the text.

I did not find a nice way of referencing sub-sections of the text. How exactly do you do that? I never used Wikitext before :/

Thanks!

I never sent attachments before. I will answer that once I find out. (That's why I haven't answered that new issue you opened)

Alright thanks.

Well, here is what I have for the instructions sub-section on Nymservers. I changed it quite a bit, but it should have most of what you currently have there. Can you take a look to see if what I wrote is correct?

Excellent. It was a better polished version of what I wrote. I replaced everything with your text. Feel free to directly edit the page and I'll accept the changes.

I agree that around 4 hops should be enough to provide some anonymity, but not totally agree with the rest. I will first try to search for more information on that before actually saying what I'm thinking. I guess that sentence can stay there.

There isn't a mention of it in the new text but feel free to mention it if you think it should be.

I do not remember using the symmetric option, but I do not think that would cause these problems. Can you provide more info on that?

Not my words but a copy of a newsgroup post - probably outdated. I never tried it and I don't think this still applies anyway because aam2mail should handle it.

I do not know how Mixmaster's -c flag work, but I think it just sends a bunch of copies and all of them might be delivered. For that reason, I guess that we should instruct the user to use copies only for the creation, because the recipient might not like to receive duplicates. What do you think?

Yes I agree.

There were some parts of your new version that you enumerated the steps like 1) ... 2) ..., but they are kind of 'hard coded'. Isn't there a way to use something to keep track of an ordered list similar to how the section numbers are handled? I just think that using a hard coded index would add a little more work when updating the text.
I did not find a nice way of referencing sub-sections of the text. How exactly do you do that? I never used Wikitext before :/

I haven't tried it before but could this work?

https://en.wikipedia.org/wiki/Help:Section#Section_linking_and_redirects
https://en.wikipedia.org/wiki/Help:Wiki_markup#Lists

dau added a comment.EditedJul 14 2015, 2:54 AM

Excellent. It was a better polished version of what I wrote. I replaced everything with your text. Feel free to directly edit the page and I'll accept the changes.

Cool! Thanks :)

There isn't a mention of it in the new text but feel free to mention it if you think it should be.

Isn't it this part?

Send the encrypted file to the Nymserver with Mixmaster:

    mixmaster --mail -l *,*,* -c 2 config@mixnym.net pubkey.txt.asc

Where:

-l customizes the remailer chain length. The shorter the chain the faster your mail will be sent and the more likely it will make it through. Here we are using three random mixes: *,*,*.

Not my words but a copy of a newsgroup post - probably outdated. I never tried it and I don't think this still applies anyway because aam2mail should handle it.

I'll let you know if I find something new about it.

I haven't tried it before but could this work?
https://en.wikipedia.org/wiki/Help:Section#Section_linking_and_redirects
https://en.wikipedia.org/wiki/Help:Wiki_markup#Lists

I'll take a look at those.

I was reading the section again and there is something missing there.

On the sub-section 3.6 Send Mail with Registered Nym, I forgot to instruct the user to sign the message. Unfortunately I did not find a way to sign and encrypt "simultaneously" with KGpg equivalent to gpg -aesr server file. I believe that doing separately with KGpg, by composing, signing and only after that encrypting would work, but haven't tested it yet. But I guess that in the case of this guide, using a GUI as KGpg isn't helping much. It might be even more confusing because we are not giving any screenshots, and the gpg's commands we are using do not seem to be too complicated for the users. I do not see a problem on using it, just think that we might be making the process even more complex. What do you think?

Also, there are some things missing:

  • Section on how to use url@server
  • Section on how to post no Newsgroups (maybe mailing lists too?)

Thanks!

Isn't it this part?

Yes but I missed because it was differently phrased. I don't think it matters to compare anonymity types, more can never hurt :)

On the sub-section 3.6 Send Mail with Registered Nym, I forgot to instruct the user to sign the message. Unfortunately I did not find a way to sign and encrypt "simultaneously" with KGpg equivalent to gpg -aesr server file. I believe that doing separately with KGpg, by composing, signing and only after that encrypting would work, but haven't tested it yet. But I guess that in the case of this guide, using a GUI as KGpg isn't helping much. It might be even more confusing because we are not giving any screenshots, and the gpg's commands we are using do not seem to be too complicated for the users. I do not see a problem on using it, just think that we might be making the process even more complex. What do you think?

Agreed. I prefer the commandline myself and find it most straight forward to do these steps anyhow. As long as everything is documented (as you have done) it should be easy for anyone to apply it by pasting them in the terminal.

Also, there are some things missing:

Section on how to use url@server
Section on how to post no Newsgroups (maybe mailing lists too?)

Would be great additions. Yes posting to mailing lists is a very useful usecase too.

Thanks Felipe!

dau added a comment.Jul 14 2015, 9:53 PM
In T374#5925, @HulaHoop wrote:

I was able to user Anchors to reference the sub-sections, but apparently we can't create ordered lists with content between the items. They must be in the format:

# Item 1
# Item 2

Doing something like:

# Item 1

Instructions, quotes, etc

# Item 2

Will be interpreted as 2 separate lists.

In T374#5927, @HulaHoop wrote:

Yes but I missed because it was differently phrased. I don't think it matters to compare anonymity types, more can never hurt :)

I actually do not remember what was written there before, but you can add more stuff to it.

Agreed. I prefer the commandline myself and find it most straight forward to do these steps anyhow. As long as everything is documented (as you have done) it should be easy for anyone to apply it by pasting them in the terminal.

I just made some changes. Removed he KGpg instrctions and left gpg's only.

Also improved some steps.

Oh, and I believe that the Message Path section should be removed from the instructions and become a subsection of the main section.

Thanks!

I just made some changes. Removed he KGpg instrctions and left gpg's only.
Also improved some steps.
Oh, and I believe that the Message Path section should be removed from the instructions and become a subsection of the main section.

Looks good.

I moved the Message Path into its own section above Instructions to give an overview. Do you think this is the right place?

dau added a comment.Jul 15 2015, 2:56 PM

I moved the Message Path into its own section above Instructions to give an overview. Do you think this is the right place?

I believe so :)

Maybe the only thing we have left to finish the instructions is to number the steps. Unfortunately it looks like we will have to use constants :/

I think that in the future we can add more theory related to Nymservers, instead of just a tutorial.

Thanks HulaHoop!

Thanks a lot Felipe, you've done a great job.

In the future I'll show you any additions I make first, to get your opinion.

Steve explained to me a some things about aam2mail. I think it belongs under the Important section because its related to multiple nyms. What do you think?

For now I'll focus on testing Nymphemeral.

In aam2mail, there are 3 config files where you list Subjects you want
to extract from aam. Those files are:
subject_plain
subject_esub
subject_hsub
You can use one or more config files simultaniously and each can have an
unlimited number of subjects to search for. In reality, most people
probably only have a single Nym so they'd only put create one file and
that would contain a single line.
If my hsub secret is "bananasplit show", I would create subject_hsub and
put a single line in it with that secret.
The master config file is .aam2mailrc and it resides in the user's
homedir. The locations of the subject config files, along with other
settings can be defined in there. By default, they are:-
$HOME/aam2mail/etc/subject_plain
$HOME/aam2mail/etc/subject_esub
$HOME/aam2mail/etc/subject_hsub

dau added a comment.Jul 16 2015, 8:40 PM
In T374#5936, @HulaHoop wrote:

Thanks a lot Felipe, you've done a great job.

So have you :)

In the future I'll show you any additions I make first, to get your opinion.

Alright! Just remember that I know these things because I've been working on nymphemeral for a while, but I am far from being an expert. More people reviewing that section are welcome.

In T374#5939, @HulaHoop wrote:

Steve explained to me a some things about aam2mail.

Cool! It would be awesome if he could review the whole Nymservers section.

I think it belongs under the Important section because its related to multiple nyms. What do you think?

I think it would be more consistent to add it to aam2mail's sub-section, however, I think that it would make the guide longer and more complex. I agree on adding them to the important notes. But if possible, add a line under aam2mail mentioning there is more info at the end.

For now I'll focus on testing Nymphemeral.

Awesome! I appreciate your help :)

Thanks!

I asked Steve Crook about nymserver attachment support a while back and yet to receive a reply.

Researched attachment support for remailers and apparently most (all?) Mixmaster nodes set the option to filter binary attachments, so I'm guessing the message with the attachment never makes it to the nymserver.

I did some more testing to confirm:

  • Nymservers do support attachments. Any files attached in a conventional message are converted into base64 encoded text appended to the end of the message body:

An example message send to a nym address looks like so:

Return-Path: <sender@openmailbox.org>
X-Original-To: gpgkey@mixnym.net
Delivered-To: nymserv@mixmin.net
Received: by snorky.mixmin.net (Postfix, from userid 110)
id 79C8CEA9FE; Thu, 6 Aug 2015 03:54:10 +0100 (BST)
Authentication-Results: snorky.mixmin.net; dkim=pass
reason="1024-bit key; unprotected key"
header.d=openmailbox.org header.i=@openmailbox.org
header.b=jxVZmrGS; dkim-adsp=pass; dkim-atps=neutral
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on snorky.mixmin.net
X-Spam-Level: *
X-Spam-Status: No, score=1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,MISSING_SUBJECT,RP_MATCHES_RCVD,SPF_PASS,
TVD_SPACE_RATIO,ZIP_ATTACHED autolearn=no autolearn_force=no version=3.4.0
Received: from smtp11.openmailbox.org (smtp11.openmailbox.org [62.4.1.45])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested)
by snorky.mixmin.net (Postfix) with ESMTPS id A7ADAEA9FC
for <gpgkey@mixnym.net>; Thu, 6 Aug 2015 03:54:09 +0100 (BST)
Received: from localhost (localhost [127.0.0.1])
by mail2.openmailbox.org (Postfix) with ESMTP id E08AD2007BF
for <gpgkey@mixnym.net>; Thu, 6 Aug 2015 04:54:08 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=openmailbox.org;

	 h=content-type:content-type:mime-version:user-agent:from:from

:date:date:message-id:received; s=openmailbox; t=1438829647; bh=
AlR5Q3gNwD44W+b71sF2B5wlpZMbiDFQ8Uz5pSL1rQA=; b=jxVZmrGSEzLW6EbA
z39ArFcBmcWtxto0NIM6r8NjQ1VoS5DUxyZw9nQIyX2CJNz0OTjaG76eXtq4mSqa
WwGDzS93/jtbYrrnoOSW4w4xVR2uMOdNq+aQ4OOxdLHgkB5UFfY4GfOvWkEdqm3h
M0+59GbCqype28Bsuis0cAu3zEw=
X-Virus-Scanned: amavisd-new at openmailbox.org
Received: from mail2.openmailbox.org ([62.4.1.33])
by localhost (mail.openmailbox.org [127.0.0.1]) (amavisd-new, port 10026)
with ESMTP id 7y7gj3rgfqTP for <gpgkey@mixnym.net>;
Thu, 6 Aug 2015 04:54:07 +0200 (CEST)
Message-ID: <55C2CC41.6090901@openmailbox.org>
Date: Thu, 06 Aug 2015 02:53:53 +0000
From: sender <sender@openmailbox.org>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Icedove/31.7.0
MIME-Version: 1.0
To: gpgkey@mixnym.net
Content-Type: multipart/mixed;
boundary="------------060803030505030804000703"
This is a multi-part message in MIME format.
--------------060803030505030804000703
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
message body
--------------060803030505030804000703
Content-Type: application/zip;
name="Text File.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="Text File.zip"
UEsDBBQACAAIAAsVBkcAAAAAAAAAAAsAAAAJACAAVGV4dCBGaWxlVVQNAAcXycJVF8nCVRfJ
wlV1eAsAAQToAwAABOgDAABT4CpJrShRSMvMSQUAUEsHCGeFU+wNAAAACwAAAFBLAQIUAxQA
CAAIAAsVBkdnhVPsDQAAAAsAAAAJAA0AAAAAAAAAAACkgQAAAABUZXh0IEZpbGVVVAUABxfJ
wlV1eAAAUEsFBgAAAAABAAEARAAAAGQAAAAAAA==
--------------060803030505030804000703--

  • The attachment is then reconstructed by copying the base64 encoded text into a separate text file and running this command

base64 --decode "1439126421.M839822P8316Q1.host" > File.zip

  • Mixmaster nodes don't support attaching binary attachments outside the message body. The only way to send attachments is inline encoded in base64 with this command:

base64 "filename.extension"

The sender must specify to the recipient what kind of file it is so they can correctly reconstruct it with base64 on the other side.

dau added a comment.Aug 11 2015, 4:37 AM
In T374#6341, @HulaHoop wrote:
  • Nymservers do support attachments. Any files attached in a conventional message are converted into base64 encoded text appended to the end of the message body:
  • Mixmaster nodes don't support attaching binary attachments outside the message body. The only way to send attachments is inline encoded in base64

Thanks for looking into that. That's great!

The message you posted is the one that has been processed by the server, but how does the message you composed look like? Something like the following?

To: send@server

-----BEGIN PGP MESSAGE-----
To: recipient@domain

message

attachment
-----END PGP MESSAGE-----

It's better if Mixmaster isn't even aware of the attachments if they are sent inline and then the whole message encrypted to the server. All it would see would be just a long PGP message, as the example above.

Similarly, if the nym and the recipient use end to end encryption to communicate, then the server would see just another PGP message:

To: send@server

-----BEGIN PGP MESSAGE-----
To: recipient@domain

-----BEGIN PGP MESSAGE-----
message

attachment
-----END PGP MESSAGE-----

-----END PGP MESSAGE-----

If neither Mixmaster, nor the nymserver reject long messages, then that's probably the best approach so that we do not leak the attachments' metadata. An adversary would just know that the message probably has attachment(s) because of its size, but that would be all, right?

In T374#6342, @HulaHoop wrote:

Thanks! I'll take a look at those.

The message you posted is the one that has been processed by the server, but how does the message you composed look like? Something like the following?

Yes.

An adversary would just know that the message probably has attachment(s) because of its size, but that would be all, right?

Yes exactly :)


Remailers have a message size limitation specified as "klen" in their caps strings in the rlist.txt. The highest limit I saw on there is a klen of 1024 so I think this means a message of 1 mb in size. Any messages exceeding the limit are silently discarded.

http://alt.privacy.anon-server.narkive.com/Nq6lzluz/size-limit-for-qsl-message

https://groups.google.com/forum/?_escaped_fragment_=topic/alt.privacy.anon-server/6qPze6ehjAM#!topic/alt.privacy.anon-server/6qPze6ehjAM

http://pinger.mixmin.net/rlist.txt

Realistically the message size should be limited to 1000 to account for message padding to keep under the 1024 limit. Nymphemeral could parse rlist.txt to choose hops that support this maximum size or choose a node selection based on attachment size which will be harder. Say, if a message's size doesn't exceed 200 kb then Nymphemeral selects any remailer from rlist that supports 200+ (these nodes becomes eligible in its path selection and so on).

The small attachment limit makes them not optimal but they're still good to have.

I looked up more information and there are ways around the message limits. On usenet groups like alt.binaries people got around message size limits and the lack of binary file support by using dedicated programs that manage spliting and reconstruction of files into multi-part base64 messages.

http://linux.die.net/man/1/uuenview
http://linux.die.net/man/1/uudeview

The -lines parameter is useful here:

-lines
Substituting lines with a number, sets the maximum number of encoded lines per part. The encoded data is automatically split into as many parts as required. Line counts less than 200 are ignored. The uuencoding and xxencoding methods encode 45k, and Base64 encodes 57k of data in 1000 lines. If this option is not specified, the default is unlimited lines per part, resulting in exactly one part.

Nymphemeral could just consider the lowest limit on message size in rlist when splitting/assembling attachments and not have to do any more difficult work selecting node paths because of different permitted size limits.

dau added a comment.Aug 12 2015, 5:55 PM

Thanks HulaHoop! That's very interesting.

I've been busy, but I will read more about how to implement attachments on nymphemeral as soon as I can. One problem that I can think of right now is handling these parts from messages that do not arrive at the same time. nymphemeral will probably attempt to decode every message and keep them until it works. We do allow the users to save messages, but keeping stuff on disk is not very recommended. I do not see another option though.

I'll let you know once I find a solution.

Thanks!

What is the status of this user documentation ticket?

The documentation is done and polished but there's parts about ideas for Nymphemeral that I should have opened another ticket for. Do you want to split the topic or change its title?

HulaHoop closed this task as Resolved.Dec 20 2015, 6:38 PM
Patrick reopened this task as Open.Dec 20 2015, 11:31 PM

It's not yet added to https://www.whonix.org/wiki/Documentation. Please also check from which other places, linking it would be useful.

Done. Is there an easier way to add entries without having to change all tag numbers of entries that come after it?

Just use a normal link.

link description

Please don't change these numbers - because now there is a duplicate number 103 - which will cause issues. These numbers are up to the translations coordinator (Ego).

I removed the number tags and left it in as a normal link.

HulaHoop closed this task as Resolved.Jan 3 2016, 11:49 PM