OmniMix • Tutorial • Some Important Issues

Common Issues

•	IMPORTANT: For a data exchange with Mixmaster the original message is stored to disc and may be recoverable with special tools! If future Mixmaster versions don't allow complete in-memory communication, a (nearly) secure erase function will have to be built into OmniMix. A better choice would be to set up an encrypted partition with a tool like TrueCrypt / VeraCrypt. Likewise, this has to be considered before activating one of the log file options.
•	Except for the nym section all passphrases OmniMix has to know are encrypted before being stored into the .ini file. But bear in mind, that this is not bullet proof, as anyone might be able to extract them when OmniMix is running or capable of finding the DES key somewhere stored in the application or now even take it from the published source code!
•	In principle it isn't possible to send anonymous messages to 'Bcc:' addresses. OmniMix currently simply ignores such header entries.
•	Please notice, that when defining remailer chains differently from ancient Mixmaster 2.0 with the now used 3.x version single remailers have to be separated by commas, not spaces, and 'any' has to be represented by an asterisk and no longer a '0' (number zero). But OmniMix accepts both styles and, if necessary, converts the chain argument accordingly.
•	Sometimes a message box opened by the 'Nym Configurator' hides behind the originating window, which appears as if OmniMix has crashed. This happens due to a problem of the development tool with newer Windows versions. For accessing the blocking message box try to activate the window of another application and then reenter OmniMix.

The GnuPG Dilemma

OmniMix bases heavily on public key cryptography provided by the marvelous GNU Privacy Guard software developed by Werner Koch. It's version 1.4 shines out concerning portability, reliability and speed. But one tiny deficiency led to an odyssey in the development of OmniMix.

Caring for anonymity one only has to consider, that PGP keys and encrypted nym / WME messages carry UTC timestamps related to the moment of creation resp. signing. So if you encrypt (and by that sign) a nym message and instantly send it, which is what OmniMix does, an adversary at the concerning nym server gets knowledge of the exact shipping time, which makes it a lot easier for him to compromise the author.

To address this security breach OmniMix offers options at the 'Gpg' > 'Time' tab to vary those timestamps randomly.

Defining date and time never was a problem with key creation, whereas for signatures that feature, though mandatory for anonymity tasks, unfortunately wasn't supported by GnuPG 1.4.

That's why OmniMix up to version 2.2.0 had to alter the computer's system time for periods when GnuPG was getting involved with such sensitive action. This strategy was anything but a perfect solution, as an incorrect system time entails a lot of potential side effects not even limited to OmniMix itself, which is why it was deactivated by default. However, by not allowing to specify the timestamps of signatures GnuPG back then left no other choice to eliminate this data leakage.

But altering system time requires administrator privileges, which is why one may have encountered an error message while using GnuPG to sign data.

To provide OmniMix with administrator privileges one either had to start it from its desktop icon with a right click on 'Run as administrator'

or that assignment had to be made permanent at the icon's 'Advanced Properties' dialog window (right-click on the OmniMix icon > 'Properties' > 'Advanced') by checking the 'Run as administrator' box.

Then GnuPG 2.1 was released, allowing to define signature timestamps in a direct way.

And with version 2.3.0 OmniMix moved to that at first glance promising, more modern GnuPG branch, apart from the gain of further crypto algorithms mainly driven by its capability of controlling signature timestamps, which since then was never backported to version 1.4. By getting rid of system time manipulations including their side effects, from then on GnuPG timestamp obfuscation was activated by default.

Unfortunately GnuPG 2.1 fell short of expectations in many respects concerning design, security and performance. Here's a list of the major, mostly insurmountable problems that had to be faced:

•	Broken keyring separation caused by a common secret key repository With version 2.1 GnuPG introduced a new key storage concept with all private keys now being stored in separate files within a single folder instead of a private keyring associated to its public counterpart. That results in an extremely problematic side effect. Where in former GnuPG versions you've been allowed to hold the same private / public keypair in different lists (here Nym / Remailer / WME) from now on the secret key would be removed from all lists in case you delete that key from one of them, leaving alone the public key.
•	Decoding restriction to a specified secret key fails Though specifying a secret key for decryption, if that task using a given passphrase fails, GnuPG retries using all the other secret keys in the repository. No chance to restrict the decryption process to a specific key - passphrase combination.
•	Mandatory passphrase caching Obviously for convenience reasons all passphrases transmitted to GnuPG are cached and potentially used with further calls. GnuPG even misses a method to clear that passphrase cache. As a consequence there's no passphrase isolation between consecutive users. Asked for their opinion on this security flaw, the GnuPG team recommended to run a separate program instance (including a separate private / public key depository) for every user, which means an extremely intricate disk storage strategy and a resource hog concerning CPU load.
•	Accordingly poor performance Compared with the 1.4 branch response time has multiplied due to the program's complexity and weird decryption strategy explained above.
•	Buggy 'gpg-agent' interlayer freezing every now and then After using GnuPG 2.1 for 24 hours the Task Manager's Processes list holds about a dozen orphaned 'gpg-agent.exe' entries.
•	Passphrase requirements for secret key export On one hand GnuPG runs beyond control, using whichever passphrases happen to be in its cache when decrypting data. And then it demands the user to enter a passphrase in order to export a secret key no matter the environment in which the system is deployed.

Many reasons why this 2.1 experiment had to end with OmniMix finally returning to GnuPG 1.4.

As there's a good side to everything, I meanwhile managed to add a --sig-date option to my custom build of GnuPG 1.4. So as a result, from OmniMix version 2.4.0 on, cryptographic timestamps can now be modified without any restrictions resp. system intervention thereby preserving speed, reliability and security of GnuPG 1.4. Let's hope a few developers stick to that indispensable branch, continue to fix bugs and add newer cryptographic techniques.