mixmaster-devel — List for developers of Mixmaster

[Mixmaster-devel] GC for finding Mix memory leaks

[Andy D. <an...@du...>]

This patch enables using a garbage collector to detect memory leaks. The
GC library is at:

http://www.hpl.hp.com/personal/Hans_Boehm/gc/

Compile this and install it. You need to install it's include files
somewhere, because apparently it doesn't do this itself. I used
/usr/include/gc. By default, it's libraries go in /usr/local/lib.

Next, apply the attached patch and install the attached leak_detection.h
in the Src directory.

Finally, edit the Makefile (presumably you have already compiled mix and
left the Makefile around). You'll need to make these changes:

INC: add gc includes, i.e. -I/usr/include/gc
DEF: add -DFIND_LEAKS
LDFLAGS: add -lgc

(don't know why the libraries aren't going in LIBS)

Then run Install to rebuild. The check for leaks happens in two places:
Towards the end of main(), and at the end of the main loop in
mix_daemon().

The whole thing compiles and runs, but I haven't done much testing yet.

BTW, the patch to (hopefully) fix remixing problems is also in here.

-- 
Andy Dustman         PGP: 0x930B8AB6
    @       .net     http://dustman.net/andy
You can have my keys when you pry them from my dead, cold neurons.

[Mixmaster-devel] Latest backtrace from 2.9b32

[Nullify A. <ad...@mi...>]

-rw-------  1 remailer  remailer  533704704 Dec 10 10:36 mix.core

This GDB was configured as "i386-unknown-freebsd"...
Core was generated by `mix'.
Program terminated with signal 6, Abort trap.
Reading symbols from /usr/lib/libz.so.2...done.
Reading symbols from /usr/lib/libcrypto.so.2...done.
Reading symbols from /usr/lib/libncurses.so.5...done.
Reading symbols from /usr/lib/libc.so.4...done.
Reading symbols from /usr/libexec/ld-elf.so.1...done.
#0  0x281e962c in kill () from /usr/lib/libc.so.4
(gdb) bt
#0  0x281e962c in kill () from /usr/lib/libc.so.4
#1  0x28226b8d in abort () from /usr/lib/libc.so.4
#2  0x806d9d9 in fail () at buffers.c:26
#3  0x806dbee in buf_append (buffer=3D0x808a660, msg=3D0xbfbf9ddb "=FF\f\=
236=BF=BF=F7@\006
\b`=A6\b\b=FF", len=3D1) at buffers.c:116
#4  0x806dde2 in buf_appendc (to=3D0x808a660, b=3D255 '=FF') at buffers.c=
:166
#5  0x80640f7 in quoted_string (in=3D0x808a5e0, string=3D0x808a660, x=3D0=
x0) at=20
rfc822.c:146
#6  0x8063f6a in word (in=3D0x808a5e0, word=3D0x808a660, x=3D0x0) at rfc8=
22.c:101
#7  0x8064818 in phrase (in=3D0x808a5e0, phr=3D0x808a640, x=3D0x0) at rfc=
822.c:346
#8  0x80648e7 in mailbox (in=3D0x808a5e0, mailbox=3D0x808a620, name=3D0x8=
08a640,=20
x=3D0x0) at rfc822.c:368
#9  0x8064982 in address (in=3D0x808a5e0, address=3D0x808a620, name=3D0x8=
08a640,=20
x=3D0x0) at rfc822.c:382
#10 0x8064ccf in rfc822_addr (destination=3D0x808a5e0, list=3D0x808a600) =
at=20
rfc822.c:460
#11 0x8050e17 in chain_select (hop=3D0xbfbf9f8c,=20
chainstr=3D0x808b880 "\"nycrem+phreaker.net -selkahe\" <ls...@hy...>=
",=20
    maxrem=3D41, remailer=3D0xbfbfa08c, type=3D0, feedback=3D0x808a4a0) a=
t chain.c:60
#12 0x8054f12 in mix2_encrypt (type=3D1, message=3D0x808a420,=20
    chainstr=3D0x808b880 "\"nycrem+phreaker.net -selkahe\" <lsd@hyperreal=
.pl>",=20
numcopies=3D1, feedback=3D0x808a2a0) at chain2.c:309
#13 0x80519ba in mix_encrypt (type=3D1, message=3D0x808a420,=20
chainstr=3D0x808b880 "\"nycrem+phreaker.net -selkahe\" <ls...@hy...>=
",=20
    numcopies=3D1, chainlist=3D0x808a2a0) at chain.c:180
#14 0x804f4ac in t1msg (in=3D0x808a060, hdr=3D2) at rem1.c:448
#15 0x804de08 in t1_decrypt (in=3D0x808a060) at rem1.c:38
#16 0x804ccd0 in mix_decrypt (message=3D0x808a060) at rem.c:152
#17 0x80772a0 in main (argc=3D2, argv=3D0xbfbffdf0) at main.c:380
#18 0x804a80d in _start ()

  -- Nullify Admin

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Those who would give up essential Liberty, to purchase a=20
little temporary Safety, deserve neither Liberty nor Safety.
      -- Benjamin Franklin

It is seldom that liberty of any kind is lost all at once.
      -- David Hume

[Mixmaster-devel] Remix

[Adam L. <ag...@li...>]

Just a heads up; I'm still working on the code that I posted here a while
back. I don't know if anyone took a look at it (it was pretty shoddy at the
time (and still is ;)), but it's comming along.

I should be able to do have a respectable pre-release by after Xmas.

AGL

--=20
90% of generation[x] will always think that generation[x+2] are too liberal.

[Mixmaster-devel] Re: [Remops] Re: problems with chaining to cpunk only

[<Dis...@sa...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

cmeclax po'u le cmevi'u ke'umri wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: RIPEMD160
> >
> > Dis...@sa... wrote:
> > > Andy Dustman wrote:
> > > > If it's truly transparent remixing (i.e. NOT Remix-To:), it should
> > > > remail the message normally as an ordinary type-I message. I believe
> > > > that this is not a problem in older mixmaster versions; Mix-2.9beta23
> > > > does not seem to have this problem.
> > >
> > > are you sure ?
> > > code in rem1.c line 442-458 (where I believe the bug is)
> > > is the same for both versions.
> > >
> > > I think I have found the problems... but I need
> > > a little more testing before I send the patch
> >
> > it was faster than I expected.. here is the patch:
> >
> > --- orig_b32/rem1.c     Wed Oct 31 10:19:54 2001
> > +++ rem1.c      Mon Dec 10 12:21:25 2001
> > @@ -451,7 +451,7 @@
> >         errlog(NOTICE, "Can't remix -- %b\n", line);
> >        else {
> >         if (remixto->length)
> > -         err = t1_encrypt(type, out, remixto->data, 0, 0, line);
> > +         err = t1_encrypt(type, out, remixto->data, 0, 0, line) ? 0 : 1;
> >         if (err != 0)
> >           err = mix_pool(out, type, latent * 60);
> >        }
> >
> >
> > please apply this patch everyone who have REMIX enabled. this is serious
> > bug.
> 

I'm really sorry.. this patch was not good.
because it seems sat mixmaster tries to encrypt all messages not
only ones that are to other remailers (another bug?), and of course fails.
this patch should work:

- --- orig_b32/rem1.c     Wed Oct 31 10:19:54 2001
+++ rem1.c      Mon Dec 10 12:21:25 2001
@@ -451,7 +451,7 @@
        errlog(NOTICE, "Can't remix -- %b\n", line);
       else {
        if (remixto->length)
- -         err = t1_encrypt(type, out, remixto->data, 0, 0, line);
+         t1_encrypt(type, out, remixto->data, 0, 0, line);
        if (err != 0)
          err = mix_pool(out, type, latent * 60);
       }


> I started getting "PGP decryption failed" errors on remixed and other Cpunk
> messages. I turned on mbox.error and isolated one of the messages. I tried to
> decrypt it with the patched version and with the unpatched version.
> 
> neofelis% ~/Mix/mix -R <badping.asc                                   ~/pinger
> Error: PGP decryption failed.
> Error: Can't decrypt PGP message.
> Info: Invalid type 1 message from rl...@in...
> You have new mail.
> neofelis% ~/Mix/mix.orig -R <badping.asc                              ~/pinger

it should be some other problem...

> Any idea why? I'm going back to the unpatched version.

__
Disastry  http://disastry.dhs.org/
-----BEGIN PGP SIGNATURE-----
Version: Netscape PGP half-Plugin 0.15 by Disastry / PGPsdk v1.7.1

iQA/AwUBPBSz3TBaTVEuJQxkEQNoQgCgsxCd6rq19iMoQ8dXJPLWfV4aXJQAn0sz
Ey0V6DXDenc+o9I/obj6Jx4/
=OKzJ
-----END PGP SIGNATURE-----

[Mixmaster-devel] Re: [Remops] Re: problems with chaining to cpunk only

[cmeclax po'u le cmevi'u ke'u. <cm...@gm...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

de'i Monday 10 December 2001 05:30 la Dis...@sa... cusku 
di'e
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: RIPEMD160
>
> Dis...@sa... wrote:
> > Andy Dustman wrote:
> > > If it's truly transparent remixing (i.e. NOT Remix-To:), it should
> > > remail the message normally as an ordinary type-I message. I believe
> > > that this is not a problem in older mixmaster versions; Mix-2.9beta23
> > > does not seem to have this problem.
> >
> > are you sure ?
> > code in rem1.c line 442-458 (where I believe the bug is)
> > is the same for both versions.
> >
> > I think I have found the problems... but I need
> > a little more testing before I send the patch
>
> it was faster than I expected.. here is the patch:
>
> - --- orig_b32/rem1.c     Wed Oct 31 10:19:54 2001
> +++ rem1.c      Mon Dec 10 12:21:25 2001
> @@ -451,7 +451,7 @@
>         errlog(NOTICE, "Can't remix -- %b\n", line);
>        else {
>         if (remixto->length)
> - -         err = t1_encrypt(type, out, remixto->data, 0, 0, line);
> +         err = t1_encrypt(type, out, remixto->data, 0, 0, line) ? 0 : 1;
>         if (err != 0)
>           err = mix_pool(out, type, latent * 60);
>        }
>
>
> please apply this patch everyone who have REMIX enabled. this is serious
> bug.

I started getting "PGP decryption failed" errors on remixed and other Cpunk 
messages. I turned on mbox.error and isolated one of the messages. I tried to 
decrypt it with the patched version and with the unpatched version.

neofelis% ~/Mix/mix -R <badping.asc                                   ~/pinger
Error: PGP decryption failed.
Error: Can't decrypt PGP message.
Info: Invalid type 1 message from rl...@in...
You have new mail.
neofelis% ~/Mix/mix.orig -R <badping.asc                              ~/pinger

Any idea why? I'm going back to the unpatched version.

cmeclax
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8FLnsBETrxUjAxlERAr1eAJ9AFANxzYOeIMa5sNtcZNEe1T7g/gCfe4sb
DVV7MTHX3YBXXWk1bTSi7kY=
=w3xp
-----END PGP SIGNATURE-----

Re: [Mixmaster-devel] Inter-remailer protocol

[Michael T. S. <mi...@sh...>]

Lucky Green wrote:

> Michael T. Shinn wrote:
> 
>>Aside from hashcash, there was a paper presented at USENIX 
>>regarding the 
>>use of client puzzles for TLS throttling.  So, there are some working 
>>examples we can borrow from to add this into mix.
>>
> 
> Before spending too much time adding code to Mixmaster that rate-limits
> connections/requests/throughput by requiring the client to perform
> computations, you probably should know that RSA Security has a patent on
> this technology. Yes, I know that there is countless prior art and that
> the patent should have never been issued. Sorry, I don't have the patent
> number handy. IIRC, Ari Juels from RSA Labs is on the patent.


Thanks for the info, I'll try to find the relevant patent info - but having 
over a dozen patents myself, I wouldn't put much stock in the current 
patent process.  ALOT of stuff is being issued that will never hold up in 
court, equally, we would need to be using the same method to be in 
violation of the patent - so we can always engineer around it.

Regardless of the outcome of the potential patent issue, I don't think we 
should stop development of a client puzzle system to rate limit traffic 
thru the network.  We can always change algorithm we use or rejigger the 
method if it violate someones patent.  Flooding is a really big problem 
with the network right now that is only dealt with peacemeal via the 
current inbound flood detection system.  We need something better than the 
limited counter measures remailers have now.

Whats worse is that intra-remailer flood detection is really not practical 
right without a client puzzle system in place.  The current system relys on 
trust.  Trust that other remailers are doing inbound flood detection.  If 
only one inbound remailer fails to do this, it opens the entire network up 
to floods.  In short, the network is seriously vulnerable to floods.

For the network to scale and self heal, we have to solve that problem. 
Perhaps there is a better method, for the client puzzle methods seems as 
good as any right now.  Perhaps someone else has some other ideas?


-- 
Michael T. Shinn	PGPKey: 0x91C0781F       GnuPG Key: BC626A27

RE: [Mixmaster-devel] Inter-remailer protocol

[Lucky G. <sha...@cy...>]

Len wrote:
> As I've been discussing the inter-remailer protoco with 
> people, two other things have come up that hadn't been 
> mentioned previously.
> 
> One, we need to make sure it supports IPv6. (I'm sure there's 
> no argument
> there.)
> 
> Two, I want to allow for a token/payment exchange in the 
> protocol if it could be easily provided. (Obviously nothing 
> exists currently to utilize that, but I'd like to allow for 
> it in the future.)
> 
> Thoughts?

Only one thing and that is to caution against over-engineering the
protocol. (I don't consider the above to fall into this category). For
example, the protocol should not concern itself with authenticating or
encrypting the inter-remailer messages. That's a solved problem. As far
as the protocol is concerned, assume a secure, authenticated link exists
between the remailers. Which is not to say that there is no work that
needs to be done in the code to establish said link, but these
requirements are orthogonal to the requirements inter-remailer protocol.

--Lucky

RE: [Mixmaster-devel] Inter-remailer protocol

[Lucky G. <sha...@cy...>]

Michael T. Shinn wrote:
> Aside from hashcash, there was a paper presented at USENIX 
> regarding the 
> use of client puzzles for TLS throttling.  So, there are some working 
> examples we can borrow from to add this into mix.

Before spending too much time adding code to Mixmaster that rate-limits
connections/requests/throughput by requiring the client to perform
computations, you probably should know that RSA Security has a patent on
this technology. Yes, I know that there is countless prior art and that
the patent should have never been issued. Sorry, I don't have the patent
number handy. IIRC, Ari Juels from RSA Labs is on the patent.

--Lucky

[Mixmaster-devel] Mixmaster passphrase benefits?

[Lucky G. <sha...@cy...>]

Having looked at the current Mixmaster passphrase implementation, I have
been unable to identify any security benefits that this implementation
offers over an implementation without a passphrase.

Can anybody on this list construct an attack that cannot be performed
against the current implementation with a passphrase that can be
performed against an implementation without a passphrase? Attacks
requiring incorrectly set file permissions do not count.

TIA,
--Lucky

[Mixmaster-devel] Re: [Remops] Re: problems with chaining to cpunk only

[<Dis...@sa...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Andy Dustman wrote:
> If it's truly transparent remixing (i.e. NOT Remix-To:), it should
> remail the message normally as an ordinary type-I message. I believe
> that this is not a problem in older mixmaster versions; Mix-2.9beta23
> does not seem to have this problem.

are you sure ?
code in rem1.c line 442-458 (where I believe the bug is)
is the same for both versions.

I think I have found the problems... but I need
a little more testing before I send the patch


> On Wed, 2001-12-05 at 22:37, Joel M. Baldwin wrote:
> > What do you propose happen in this case?
> > That the message be crypted in cpunk?

currently it is beeing encrypted in cpunk and then trown away instead of sending :-/
I'm sure it's a bug.

maybe it's even not necessary to encrypt in cpunk, if the message is already encrypted?


> > Senshi-Admin wrote:
> > > I've mentioned this many many times before, but nobody
> > > seems interrested in this serious bug in Mixmaster.
> > >
> > > This is what happens:
> > > - - Mixmaster receives the chain ping that contains
> > >   "Anon-To:" or "Request-Remailing-To:" (equivalent)
> > > - - Mixmaster finds that the destination is a remailer
> > >   it knows
> > > - - As transparent remixing is enabled, Mixmaster looks
> > >   up the mix key of the remailer in it's mix keyring
> > > - - It doesn't find a corresponding mix key (surprise
> > >   for cpunk only remailers!)
> > > - - Mixmaster throws away the message

__
Disastry  http://disastry.dhs.org/
-----BEGIN PGP SIGNATURE-----
Version: Netscape PGP half-Plugin 0.15 by Disastry / PGPsdk v1.7.1

iQA/AwUBPBRBCjBaTVEuJQxkEQPh5wCePSRYlF83zDFh8MTvOlWY+X6/vi0AoICI
q5g+JEo3qWtNPqbv3AtU2Mc5
=EiiX
-----END PGP SIGNATURE-----

Re: [Mixmaster-devel] Inter-remailer protocol

[Michael T. S. <mi...@sh...>]

Len Sassaman wrote:

> As I've been discussing the inter-remailer protoco with people, two
> other things have come up that hadn't been mentioned previously.
> 
> One, we need to make sure it supports IPv6. (I'm sure there's no argument
> there.)
> 
> Two, I want to allow for a token/payment exchange in the protocol if it
> could be easily provided. (Obviously nothing exists currently to utilize
> that, but I'd like to allow for it in the future.)


Aside from hashcash, there was a paper presented at USENIX regarding the 
use of client puzzles for TLS throttling.  So, there are some working 
examples we can borrow from to add this into mix.

I've started writing some stubs and backending work for mixmaster towards 
this end, but its far from complete.  Regardless, here are my very rough 
notes from my TODO file so far on how it might work:



TODO and notes:

Client Puzzle support
         - Protocol
         - Mechanism to supply challenge keyspace to end users
                 In the stats for the day?  week?
         - Redundancy mechanism?  What to do if your
         token gets old because the network is
         too slow?  Should keying material be
         available longer than recommended total
         latency of network?  What if the network
         gets flooded?  Needs a sliding window on tokens
	and not just an arbitary cut off.

         Does the client puzzle need to be intra-
         remailer in a trusted remailer network?
         (ie, we can trust that all input nodes
         have client puzzles which we can test
         with our pinger, if they don't, they are
         not labled "client puzzle".  Any remailer
         that is not listed as "client puzzle"
         that is remailing to a remailer that is a
         "client puzzle" remailer must provide a
         "client puzzle" in the form of a new
         header inside the next envelope of the
         mix message, just like ANY OTHER user
         of the remailer - which shouldn't cause
         any problems, because these headers are
         added by users.  For remailers that are
         listed "client puzzle" and pass that
         test by issuing a "client puzzle" challenge
         or by dropping our NON-"client puzzle"
         pings.  This is to prove that they do
         NOT work with NON-"client puzzle" hosts.
         These remailers are then trusted, and
         messages from them do not need to solve
	"client puzzles".

        New file: cp_remailers

                 Explanation: Remailers that require
                 Client Puzzles to process messages.
                 Should be generated with a pinger
                 that tests this suppostion to see
                 if it is true, by supplying the
                 opposite and affirmative cases.

		Optionally these remailers can be
		trusted and packets from them do
		not need to solve client puzzles.

         Cap String notes:

         cp - Client Puzzle only if the message
         is coming from a host (even a remailer)
         that does not generate Client Puzzle
         tokens.  So, if you chain thru a remailer
         that does not have a cp in its caps string
         then you MUST generate a token for the
         remailer in the hop you are chaining thru.
         Good mix clients should do this for you
         automatically.  Two or more cp remailers
         in a row, in a chain, and you only need
         to generate token for the first remailer.

         cpall - Client Puzzle from any host must
         be recieved.  For a cpall remailer, every
         system that connects to it must generate a
         "Client Puzzle" token.

	Possible other cases:

	
	cppriority:  Clients that generate client
	puzzles get priority on the server.  All other
	mail is sent out only after cp mail is processed.

One unsolved issue is nyms, how do they store enough tokens to handle reply 
messages?  Maybe some form of "postage due" message sent to the nym account 
holder telling them they need to deposit N tokens to pick up their mail 
might work.  If tokens are recieved in Y days, then the optionally gets
dumped into the bit bucket or something.

There is also the case of a client possibly needing to pay more to end 
point remailers than to middles, since the actual cost is higher for end 
points in terms of opportunity cost lost on abuse complaints.

-- 
Michael T. Shinn	PGPKey: 0x91C0781F       GnuPG Key: BC626A27

Re: [Mixmaster-devel] Inter-remailer protocol

[Len S. <ra...@qu...>]

As I've been discussing the inter-remailer protoco with people, two
other things have come up that hadn't been mentioned previously.

One, we need to make sure it supports IPv6. (I'm sure there's no argument
there.)

Two, I want to allow for a token/payment exchange in the protocol if it
could be easily provided. (Obviously nothing exists currently to utilize
that, but I'd like to allow for it in the future.)

Thoughts?

Re: [Mixmaster-devel] FreeBSD "port" of Mixmaster

[Len S. <ra...@qu...>]

On Fri, 7 Dec 2001, Lucky Green wrote:

> 9) I believe this would all be a lot easier if Mixmaster were to use
> standard GNU config...

These are the problems Scott ran into when he looked at making a port, I
believe. Does anyone want to take a stab at creating a config setup for
Mixmaster? It would solve a number of problems, actually.


--Len.

[Mixmaster-devel] FreeBSD "port" of Mixmaster

[Lucky G. <sha...@cy...>]

Thinking about a creating a Mixmaster FreeBSD port I took a look at the
Install script. 

[In talking about a FreeBSD I mean in the FreeBSD Ports Collection
sense; Mixmaster of course already runs on FreeBSD. See
http://www.freebsd.org/ports/index.html if you would like to know more
about what the Ports Collection is and why it matters).

The Install script poses somewhat of a problem to automating the port,
though I understand why the author went the route he took.

The biggest problem with the install script is that it does a good many
things in the same script:

1) determine if all the required dependencies are installed. Zlib,
ncurses, OpenSSL, IDEA. (Straight-forward with a FreeBSD port, since you
simply specify the dependencies in the port makefile and the master port
makefile will take care of all the dependencies for you, installing any
required ports that may not already be installed prior to continuing to
install your port. I am not sure what will happen if you require IDEA
and the base distribution of FreeBSD was built without support for IDEA,
but you /can/ require IDEA being available for a port).

2) check to see that if you are installing mix as root and if so tell
you to please not do that. This is awfully similar to a mailman
installation for which a port exists. FreeBSD will transparently handle
installing a port as a different user, creating any home directories
that are required. "mixmaster" should be registered as a known user with
a reserved UID. I have asked the FreeBSD ports folks to assign a UID to
mixmaster. 

3) query the user which of the various Mixmaster options to support. The
standard way of handling this on FreeBSD is to select reasonable
defaults, permitting the user to override the defaults with command line
flags such as "make -WITH_UNENCRYPTED="YES".

4) query the user for the abuse email address. (I wonder if one could
just assume "abuse", which may make sense if you assume mixmaster is
installed by root, no idea what to do if you want to permit installation
of the port by an unprivileged user. But I don't think unprivileged
users can install ports anyway, so this may be a non-issue. Still the
question if defaulting to "abuse" is acceptable remains. Could be
overridden at the command line as above.

5) Query the user for the password. This has to be done interactively
and can't be passed via the command line. I know that FreeBSD ports
permit interactive queries during install, but I don't know the "proper"
way of doing so. I trust somebody on the porters list might be willing
to fill in that gap.

6) Create the makefile. Standard port stuff.

7) Install Mixmaster in procmail. I suppose one could retain this part
of the script.

8) Remind the user to add their remailer admin key to adminkey.txt. This
is a tough one. The port would probably simply do the same thing: remind
the user.

9) I believe this would all be a lot easier if Mixmaster were to use
standard GNU config...

--Lucky, tentatively willing to take a stab at a port, but probably not
right away.

[Mixmaster-devel] Debugging Mixmaster?

[cmeclax po'u le cmevi'u ke'u. <cm...@gm...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Any suggestions on debugging Mixmaster if I wanted to make some changes and 
see how they work, or want to see how remix is handled? I'd like to become 
fully remix, but I've heard there are bugs in it.

cmeclax
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8EOEYBETrxUjAxlERAvZ5AJ9Gj/R48e0d1zMlK/aGG47/PHZIigCglIOK
7U9LCQO9JTGZ0Uy4rGPvcmA=
=nrEQ
-----END PGP SIGNATURE-----

Re: [Mixmaster-devel] Re: Remailer info sites?

[cmeclax po'u le cmevi'u ke'u. <cm...@gm...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

de'i Friday 07 December 2001 09:20 la Riot Remailer Admin cusku di'e
> On Thu, 6 Dec 2001, Lucky Green wrote:
> > I am in the process of rewriting the Mixmaster help files, which will
> > hopefully make them a bit more accessible to the newcomer, and would
> > greatly appreciate the following information:
>
> take a look of cmeclax help files that are in 4 languages

It's mostly just a translation of the one that came with Mix. But my 
usage.txt (below) is completely different and hopefully more informative than 
the one that came with Mix.

More translations are needed. There are remailer users in Russia, Japan, and 
other places who speak languages I know nothing of, and they make the most 
atrocious messes trying to send a message through a remailer. But there's a 
problem. Each of the help files begins with a sentence in each of the other 
languages. Chinese uses at least two different character codes, and if a 
Russian user saw that it would look like a mishmash of Russian letters. Of 
course we could write it in Unicode, but would then have to put the encoding 
header in.

We should have at least English, Chinese, Spanish, Russian, Hindi, and 
Arabic. These are the six most used languages in the world. But whether they 
are the six most used by computer users languages is another question.

Also, some people send MIME multipart messages that are intended as remail. 
Mix sees that they begin with two hyphens, not two colons, and passes them 
through to my inbox to deal with manually.

cmeclax
- -------
Subject: le notci be zo'e bei do bei la cmeclax

do mrilu zo'e la cmeclax. po'u le cmevi'u ke'umri .ije do simlu lenu
pilno lo naldrani ckiku gi'a mrilu lo nalmifra .i ganai go'i gi ge ko
mrilu lo notci be zoi gy. remailer-key .gy be'o la'o my.
cm...@ix... .my gi mi mrilu le ckiku be mi bei la miksmastr.
.e la me pygypy be'o do .i .e'u do mrilu lo notci be lu ke'umri sidju li'u
.a zoi gy. remailer-stats .gy be'o mi

You have reached the cmeclax anonymous remailer and seem to be using
the wrong key or sending an unencrypted message. If this is so, send a
message with subject "remailer-key" to <cm...@ix...> and
I will send you my Mixmaster and PGP keys. You can also send me a message
with subject "remailer-help" or "remailer-stats".

Vous avez envoyé au réexpéditeur anonyme cmeclax un message qui paraît
être crypté avec une clé incorrecte ou non crypté. Si c'est le cas,
envoyez-moi un message au sujet "remailer-key" à <cm...@ix...>
et je vous enverrai mes clés Mixmaster et PGP. Vous pouvez aussi m'envoyer
un message au sujet "aide-réexpéditeur" ou "remailer-stats".

È stato spedito un messaggio che sembra esser criptato con una chiave
incorretta o non criptato al remailer anonimo cmeclax. In questo caso,
manda un messaggio con oggetto "remailer-key" a <cm...@ix...>
e riceverai le mie chiavi Mixmaster e PGP. Puoi anche spedirmi un
messaggio con oggetto "aiuto-remailer" o "remailer-stats".

co'o mi'e cmeclax
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8ENbGBETrxUjAxlERAracAJ0ZZF36vQULCVxM/hLqkCzEeD+fngCfVeR3
QHVnIv25jWfvBKJJamLz4Tk=
=Lv9i
-----END PGP SIGNATURE-----

[Mixmaster-devel] Re: Remailer info sites?

[Riot R. A. <rem...@ri...>]

On Thu, 6 Dec 2001, Lucky Green wrote:

> I am in the process of rewriting the Mixmaster help files, which will
> hopefully make them a bit more accessible to the newcomer, and would
> greatly appreciate the following information:

take a look of cmeclax help files that are in 4 languages


> 1) any and all *active* URL's describing remailers and their
> operation.

see the http://riot.eu.org/anon/remap.html that contains all remailer
homepages.. also you can point to anon.efga.org that is very stable in
many years.


> 2) any stable distributions URL's of remailer software and help
> files.

sourceforge has the last release of mixmaster, but i think dizum.com too.


> 3) Any active URL's that contain nymserver instructions. The old
> http://www.publius.net/n.a.n.html is long gone. Also, if you operate
> a nym server, please get in touch with me.

riot.eu.org/anon/nym.html or lexx.shinn.net/nym/ (this is a nymserver)

c-ya!

riot		http://riot.eu.org/anon
admin		PGPKey: 7016731A57D4A69B 1A8EE5E90EF2608E (since 1995)

[Mixmaster-devel] Remailer info sites?

[Lucky G. <sha...@cy...>]

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I am in the process of rewriting the Mixmaster help files, which will
hopefully make them a bit more accessible to the newcomer, and would
greatly appreciate the following information:

1) any and all *active* URL's describing remailers and their
operation.

2) any stable distributions URL's of remailer software and help
files.

3) Any active URL's that contain nymserver instructions. The old
http://www.publius.net/n.a.n.html is long gone. Also, if you operate
a nym server, please get in touch with me.

TIA,
- --Lucky

-----BEGIN PGP SIGNATURE-----
Version: PGP 7.1
Comment: Problems decrypting this email? Upgrade from PGP 1.x/2.x!

iQA/AwUBPBBg9/XUPTw3WtkkEQJlFACfeYFk99SxMlF1N5NPmr9w43gX4+AAoI+f
jZ4wtgqGbD2JS1saTsCwk7vn
=ci3M
-----END PGP SIGNATURE-----

[Mixmaster-devel] Mix occasionally remixes when it shouldn't

[cmeclax po'u le cmevi'u ke'u. <cm...@gm...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sometimes mail addressed to me, and not intended for the remailer, is 
nevertheless randhopped and finally comes back to me. I just got a bounce of 
the following message:

Remailer key for cmeclax
From: le cmevi'u ke'umri <cm...@ix...>
To: zi'o <zi...@ix...>


$remailer{"cmeclax"} = "<cm...@ix...> cpunk mix middle pgp 
pgponly remix2 latent hash cut test ek ekx esub inflt50 rhop20 reord post";

li'o

That is, a key request came from zi'o, which is the address I would send mail 
out as if I weren't middleman, to cmeclax. The only way that could happen is 
if the key request, which is generated every midnight, were forwarded through 
a chain of remailers ending with me and then delivered by me to myself, 
instead of being replied to immediately. It wasn't last night's key request 
either. Any idea how this happens, or how to fix it?

cmeclax
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8CXKdBETrxUjAxlERAp8fAJ9v/02Z38uVEpCFzkZ9nM179ZNtnwCgnC8j
lOWNqr0DvbMgQAZ37+55ayk=
=TOva
-----END PGP SIGNATURE-----

[Mixmaster-devel] RE: [Remops] memory leak

[Lucky G. <sha...@cy...>]

One of my users is running Mixmaster on a FreeBSD 4.4 STABLE machine
that I am administering. I have not seen any problems caused by the
Mixmaster program. No memory leaks, no core dumps. Though I did notice
that many of the next-hop remailers appear to be of poor stability and
frequently are not accepting SMTP for days. (Which is not really a
problem at my site, since the outgoing mail spool has ample drive space
allocated).

--Lucky, cypherpunks.to BOFH

> -----Original Message-----
> From: rem...@le... 
> [mailto:rem...@le...] On Behalf Of Greg Broiles
> Sent: Tuesday, November 20, 2001 5:55 PM
> To: re...@le...
> Cc: mix...@li...
> Subject: Re: [Remops] memory leak
> 
> 
> At 05:09 PM 11/20/2001 -0800, Len Sassaman wrote:
> 
> >Has anyone else ever seen anything like this?
> >
> >On Wed, 21 Nov 2001, Ryan Lackey wrote:
> >
> > > [2001-11-21 00:06:53] Info: Added message to pool. [2001-11-21 
> > > 00:07:03] Info: Added message to pool. [2001-11-21 
> 00:07:30] Error: 
> > > Out of memory!
> > >
> > > I haven't seen anything unusual in the pool, and hadn't made any 
> > > changes to the configuration of the machine for weeks before this 
> > > started.  I have since upgraded to FreeBSD 4.4-STABLE trying to 
> > > eliminate the bug.
> 
> I haven't seen anything like that; I am also running FreeBSD 
> 4.4-STABLE, 
> with Mix 2.9b31.
> 
> I have seen the occasional coredump; the most recent appeared 
> 2 days ago, 
> and was 520192 bytes, which didn't seem particularly remarkable.
> 
> 
> --
> Greg Broiles -- gbr...@pa... -- PGP 0x26E4488c or 
> 0x94245961 5000 dead in NYC? National tragedy. 1000 detained 
> incommunicado without trial, expanded surveillance? National 
> disgrace.
> 
> _______________________________________________
> Remops mailing list
> Re...@le... http://lexx.shinn.net/mailman/listinfo/remops
> 
> 

Re: [Mixmaster-devel] Re: [Remops] memory leak

[Len S. <ra...@qu...>]

This should be fixed in CVS. Ulf submitted a patch for it earlier today.

On Wed, 21 Nov 2001, Riot Remailer Admin wrote:

> On Wed, 21 Nov 2001, Riot Remailer Admin wrote:
>
> > i've seen many times in this month:
> > mix: buffers.c:358: buf_get: Assertion `n > 0' failed.
>
> sorry but i haven't attached the backtrace:
>
> #2  0x805c7a5 in pgp_getpacket (in=0x8087de8, p=0x8088230) at pgpget.c:219
> #3  0x805c082 in pgp_getmsg (in=0x8087de8, key=0x8088190, sig=0x0,
>     pubring=0x0, secring=0x0) at pgpget.c:34
> #4  0x80570e1 in pgp_decrypt (in=0x8087de8, pass=0x8087e00, sig=0x0,
>     pubring=0x0, secring=0x0) at pgp.c:28
> #5  0x804e57b in t1msg (in=0x8085d10, hdr=2) at rem1.c:254
> #6  0x804d9b6 in t1_decrypt (in=0x8085d10) at rem1.c:38
> #7  0x804ca5d in mix_decrypt (message=0x8085d10) at rem.c:152
> #8  0x8075b24 in main (argc=2, argv=0xbffffb9c) at main.c:380
> #9  0x804a86e in ___crt_dummy__ ()
>
>
> the error appears when the expression at line 212 is true and partial=1,
> pgp_packetpartial() was called and set partial=0 and len=0; when the while
> is terminated the line 219 was executed and buf_get() provocate the
> assertion len=0
>
>
> c-ya!
>
> riot		http://riot.eu.org/anon
> admin		PGPKey: 7016731A57D4A69B 1A8EE5E90EF2608E (since 1995)
>
>
> _______________________________________________
> Mixmaster-devel mailing list
> Mix...@li...
> https://lists.sourceforge.net/lists/listinfo/mixmaster-devel
>

--

Len Sassaman

Security Architect            |  "Now it's all change --
Technology Consultant         |   It's got to change more."
                              |
http://sion.quickie.net       |              --Joe Jackson

[Mixmaster-devel] Re: [Remops] memory leak

[Riot R. A. <rem...@ri...>]

On Wed, 21 Nov 2001, Riot Remailer Admin wrote:

> i've seen many times in this month:
> mix: buffers.c:358: buf_get: Assertion `n > 0' failed.

sorry but i haven't attached the backtrace:

#2  0x805c7a5 in pgp_getpacket (in=0x8087de8, p=0x8088230) at pgpget.c:219
#3  0x805c082 in pgp_getmsg (in=0x8087de8, key=0x8088190, sig=0x0,
    pubring=0x0, secring=0x0) at pgpget.c:34
#4  0x80570e1 in pgp_decrypt (in=0x8087de8, pass=0x8087e00, sig=0x0,
    pubring=0x0, secring=0x0) at pgp.c:28
#5  0x804e57b in t1msg (in=0x8085d10, hdr=2) at rem1.c:254
#6  0x804d9b6 in t1_decrypt (in=0x8085d10) at rem1.c:38
#7  0x804ca5d in mix_decrypt (message=0x8085d10) at rem.c:152
#8  0x8075b24 in main (argc=2, argv=0xbffffb9c) at main.c:380
#9  0x804a86e in ___crt_dummy__ ()


the error appears when the expression at line 212 is true and partial=1,
pgp_packetpartial() was called and set partial=0 and len=0; when the while
is terminated the line 219 was executed and buf_get() provocate the
assertion len=0


c-ya!

riot		http://riot.eu.org/anon
admin		PGPKey: 7016731A57D4A69B 1A8EE5E90EF2608E (since 1995)

[Mixmaster-devel] sender authentication?

[Anonymous <no...@no...>]

[Mixmaster-devel] Re: [Remops] memory leak

[Riot R. A. <rem...@ri...>]

On Wed, 21 Nov 2001, Ryan Lackey wrote:

> Also, has anyone seen errors such as:
>
> 6E937EA705     4226 Sun Nov 18 21:31:06  som...@so...
> (Command died with signal 6: "/home/mix/Mix/mix -RM". Command output:
> assertion "n > 0" failed: file "buffers.c", line 358 )
>                                          mi...@re...

YES!

i've seen many times in this month:

mix: buffers.c:358: buf_get: Assertion `n > 0' failed.

thanks to qmail queue management the messages has continued to flow
normally and the messages that caused this assertion was bounced.

i haven't yet the time to debug this assertion, but i've saved some
message that provocate this error and i'll report lather.

c-ya!

riot		http://riot.eu.org/anon
admin		PGPKey: 7016731A57D4A69B 1A8EE5E90EF2608E (since 1995)

Re: [Mixmaster-devel] Re: [Remops] memory leak (fwd)

[cmeclax po'u le cmevi'u ke'u. <cm...@gm...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

de'i Tuesday 20 November 2001 23:50 la Len Sassaman cusku di'e
li'o
> Attached are the two messages which seemed to be the origin of the problem.
> Unfortunately they're in postfix's weird format

Look for postcat - on mine it's in /usr/sbin/.

- ----------------------------------------
Content-Type: TEXT/PLAIN; charset="us-ascii"; name="Attachment: 1"
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-Description: 6DFD7EA8AC
- ----------------------------------------
Nycrem's conffile sent to lsd's pinger.

- ----------------------------------------
Content-Type: TEXT/PLAIN; charset="us-ascii"; name="Attachment: 2"
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-Description: 6E937EA705
- ----------------------------------------
Binesh soandso.

- ----------------------------------------
Content-Type: TEXT/PLAIN; charset="us-ascii"; name="Attachment: 3"
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-Description: E2C1AEA8D2
- ----------------------------------------
Nycrem's conffile again.

cmeclax
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7+0xLBETrxUjAxlERAuPaAJ4rv1hac0Zowp1HRkuz09oqrhaZsACff4fX
X53n3i3hvYDv+J/y+qRDLIM=
=bmOs
-----END PGP SIGNATURE-----