Sorry if my questions already had answer on this newsgroup, but I was
unable to find it.

Are the Omnimix sources avalaible somewhere, as the dos Mixmaster
version ones?

I remember read somewhere that 2.0 dos version has major problem with
RND & pool management; why Omnimix can't use 2.9 ?

Thanks a lot.   Marco

[ Post a follow-up to this message ]

Hi Marco!

"marcoc" <marcoc1@dada.it> - 15 Apr 2006 01:42:56 -0700:

>Sorry if my questions already had answer on this newsgroup, but I was
>unable to find it.
>
>Are the Omnimix sources avalaible somewhere, as the dos Mixmaster
>version ones?

I'm sorry, but that currently doesn't apply to OM. As I wrote in my
initial announcement, I haven't made them available, 'reserving the
right to uncover the source code later on'. At this early stage of
development only 2 weeks after publication I haven't decided yet which
way the project will go later on. I hope this is comprehensible as
neither it's obvious whether there are any fundamental problems for
such an approach, nor can the need for and acceptance of a solution
like this one be estimated. Moreover some important topics have to be
discussed. One of them is, that I don't intend to offer spammers a
toolkit for flooding the mixmaster network.

I appreciate your reservation, but you have to realize that OM doesn't
cover any encryption item by itself. It's nothing more than an
interface to allow a more convenient usage of mixmaster and the
according net of remailers, where both, the in- and output, are
transparent for examination. It shouldn't be a problem to test it's
honest behaviour by throwing it into a sandbox installation of a
mixmaster net and using network tools. Attempts to phone home or any
manipulation of the transferred messages, which would be my main
concerns about such a tool, should quickly be discovered.

In the end you have to decide for yourself whether to play around with
OM or not, and I recommend all potential users not to use OM for real
world data of importance yet. There are reliable tools out there to do
the job.

For instance the current release of OM doesn't work well with multi
part MIME messages - besides changing the parts separator
unnecessarily. The next version 0.9.2.3 addresses that and won't
modify the message body any more. It then also standardizes the order
of the headers to guard against profiling. So OM is far from being
well tested. Here my thanks to Tim, the only beta tester I'm aware of
up to now.

>I remember read somewhere that 2.0 dos version has major problem with
>RND & pool management;

As I already mentioned, I'm not an insider in mixmaster security. So
only these annotations:

Pool management isn't a topic as OM itself takes care of an immediate
output to the mail host. It currently doesn't support multiple copies
of messages, you get one mail sent for every incoming message (if with
'RND' you allude to the 'multiple chain' problem).

>why Omnimix can't use 2.9 ?

I already explained that in detail. Please read the postings
<k53p22h3rprdca226h0plo8cd6arahd9fb@4ax.com> and
<Xns979AA6FE721FAmeprivacynet@127.0.0.1> ff..

Regards

Christian

[ Post a follow-up to this message ]

In article <1145090576.370928.108090@g10g2000cwb.googlegroups.com>
"marcoc" <marcoc1@dada.it> wrote:
>
> I remember read somewhere that 2.0 dos version has major problem with
> RND & pool management; why Omnimix can't use 2.9 ?

2.0, 2.9, and the 3.0b versions all have major problems with the RNG
under windows. They just ask you to press random keys the first time
it's ever run. That data then seeds the pseudo random number generator.
When it exits, it saves the pseudo seed to the disk, where the next
time it's run it will use that file to seed the pseudo random number
generator, and so on.

Knowing what keys that user pressed when first run (through a key logger)
or stealing the mixrand.bin file would be pretty devastating.

[ Post a follow-up to this message ]

Anonymous <nobody@invalid.org> - Sun, 16 Apr 2006 11:15:32 +0100
(BST):
>In article <1145090576.370928.108090@g10g2000cwb.googlegroups.com>
>"marcoc" <marcoc1@dada.it> wrote: 
>
>2.0, 2.9, and the 3.0b versions all have major problems with the RNG
>under windows. They just ask you to press random keys the first time
>it's ever run. That data then seeds the pseudo random number generator.
>When it exits, it saves the pseudo seed to the disk, where the next
>time it's run it will use that file to seed the pseudo random number
>generator, and so on.
>
>Knowing what keys that user pressed when first run (through a key logger)
>or stealing the mixrand.bin file would be pretty devastating.

Does that mean under Windows MM uses a congruential generator, which
can easily be compromised knowing the seed, when there should have
been engaged a real random-sequence generator, which (ideally) doesn't
give you any chance to reproduce the generated bit sequence? If so,
what's different with the *ix solution and might it be possible to
mimic this procedure externally?

Would it perhaps help to inject a new seed from an established random
number / noise source on each restart of OM, so that snooped values
would expire after a short period of time, meaning after a OM session
(the multithreading architecture doesn't allow a modification of the
rand file while the system is operating)? Would it be worth to build
an external RNG infrastructure. Or are there other remedies
conceivable?

OM currently generates a mixrand.bin file on it's own, if none is
present in the MM directory. So the user doesn't have to run MM from
the cli in the first place. Concerning the calculation of those values
I didn't consider the quality of the numbers as important, as I
thought, this procedure wouldn't have to be done multiple times, and
after some rounds of MMs internal rebuilding of the file the initial
values wouldn't matter any more. So I probably was wrong with my
assumption :-((

Regards

Christian

[ Post a follow-up to this message ]