Re: Why encrypt intra-remailernet.

[Nathan Zook <nzook@bga.com>]

Hal <hfinney@shell.portal.com>
 
>I still don't quite follow this. 
 
Clearly.  ;)
 
Okay.  You are right that the first remailer derives no primary benefit,
and engages in no primary risks from verifying signatures.  Alice, however
does, and Chaum is, after all, providing a service to Alice (and Frank).
He does wish to provide all the benefits that he can to them.
 
What benefit does Alice gain?
1) Plausible deniability.  Remember, "reasonable doubt."  Remember Abscam?
   The gov't is in a good position to fake source info.  This squishes
   that.  (It squishes even better if Chaum _requires_ signatures.)
 
2) If Chaum sends Alice a copy of the message that failed the signature
   check, Alice knows that someone is trying to spoof her.  This
   information may be critical in determining how serious her opponents
   are.
 
What risks does Alice take?
If the final message to Bob is encrypted, and Chaum is not compromised,
none.  If Chaum _is_ compromised, Alice is chaining anyway, so it still
doesn't matter.
 
What might Chaum gain from checking or requiring signatures?
Various net abuses often involve faking names.  Requiring validated
signatures would pressure these abuses away from the remailers.  Reducing
the net abuses going through the remailers is a PR goal.
 
 
>PGP already includes a cryptographically protected length field in the
>message.  It will ignore any data past that, according to my experiments.
>All that is needed is a simple patch to add junk data to the end.
 
Soapbox mode:
It seems to me that hacking PGP requires considerably more cooperation
between remailers, and more work than just allowing recursive opening of
PGP packets, automatic padding (or concatenating) of data, and automatic
encryption of out-goin mail. Subways and MixMaster both appear to have far
more working required to implement, far more cooperation between remailers,
and far more room for failure than my idea.  (Emphasis: appear.  I've not
seen Lance's paper, yet.  He's getting it to me.)
 
I also believe that hacking PGP is a bad thing (tm), because it means that
every time an upgrade comes out, it will need to be re-hacked, and once you
start hacking, when do you stop?  Although, it would be nice to have a
STD_LEN variable for such things.
 
 
OTOH, you seem to be agreeing with me here.  Who hacks PGP?  Who is PGPing
their outgoing stuff?  Don't we have to have standard packet _inside_ the
net?  And you achieve this by using PGP?  ?????
 
 
>I still don't quite follow this.  Exactly what attack would be possible
>against Miron's remailer if it allowed encrypted reply blocks (as all
>others do) which would fail if the messages were wrapped as you suggest?
 
The most obvious one: Eve checks messages (in vs out) for matching tails.
If the tails match, the messages match.  The only way around this is for
the entire message to be wrapped.  Thus, the extropian requirement.  
 
 
When I say that the Mark I remailers are laughably easy to crack, I mean
laughably easy.
 
Is the message a clear set of ::Request-Remail-To:?  Pull & log.
Is the message clear, with encrypted headers?  Match, pull, and log.
Is the message encrypted separately from the headers?  Match, pull, log.
Is the whole message encrypted?  Take the ones that are left, match the
largest.  Match the next largest.  Match the next largest. Pull & log.
 
Get stuck?  Need a hint?  Resend a message.  Watch for the repeat on the
out.
 
Laugh.
 
 
The only reason that our systems are actually able to do any good is that
our threat model _is not_ an LEA--with government resources, and government
patience.
 
 
>Alice may not have a key whe wants the general public to use - she may
>just be using one for her private correspondents.  
 
If she wants to be able to recieve untraceable mail, she is going to have
to have a key that remailers can use when forwarding mail to her.  See
below.
 
>                                                  Actually it seems to
>me given the nature of remailing that it would be superior if it were
>easy for people to "spoof" my use of the remailer.  That would give me
>more credence to claim innocence.  The more useless return addresses are,
>the less we even need remailers.
 
I think you are arguing to ignorance here.  The assumption so far on the
list has been that if Alice is root, she is in the best possible postion to
protect herself.  I disagree.
 
Alice has been hauled into court.  The Feds claim that she is the one that
actually sent messages M1,...Mx to Bob through Chaum, even though these
messages have varied From: (and From) lines.  As root, she cannot claim
that this is not possible.  OTOH, if Chaum requires a match, the Feds would
have to claim that she compromised the secret keys of all of all the
cooresponding From: addresses.  Much tougher.
 
 
>It's not my job to fix the damn Internet.  So what if I get mail claiming
>to be from abc when it's actually from def?  I of all people care the
>least, specifically because I throw away this data.  Virtually everyone
>else on the net cares where their mail comes from, but I don't.  My whole
>purpose is to discard the information about where it comes from.  That is
>why I am so confused about your emphasis on checking signatures.
 
We care because we are good people.  ;-)
 
Seriously, if a sight is being shadowed, then it is insecure.  It is to our
advantage to know this.  You are right that we "don't care" where a message
comes from only if we assume that the message _didn't_ come from an LEA.
(Or a big corporation.  Some of them probably have the power to do this,
too.)  If it did, then the remailer net is under attack, and we most
definitely _do_ care about that.
 
 
>Although I agree with Wei Dai's mathematics, to my mind it points up the
>importance of successful countermeasures rather than implying that the
>remailer network is inherently insecure.  For example, if you send one
>identical message every batch, Wei's math shows clearly that you can't be
>traced.  Let's not get rumors started about how the remailers don't
>work.
 
I'm lost here.  I thought that sending an identical message (producing
identical output) every tick would be the equivalent to an attack.
 
But what exactly constitutes "successful countermeasures"?  How do you
prevent an attacker from taking over a sight, thus compromising it, w/o
the knowlege of the operator?  How do you prevent long/short matching of
the remailer net _as a whole_?  How do you prevent tail matching?  How do
you prevent middle matching, for that matter?  How do you prevent the
repeated message attack?
 
 
>Do you see your suggestion as protecting against Wei's in/out correlation
>attack?  
 
Yes!  Well, not by itself.  My suggestions about "rational use of garbage"
do that.  If Bob recieves x messages each tick, 0 to x of which are real,
Eve is hosed--if all messages are standard sized & encrypted!.  Eve is even
more hosed if the x messages are concatenated & superencrypted.  If Alice
sends y messages each tick, Eve is hosed.  Even more so if the messages are
concatenated & superencrypted.
 
>        I don't see it.  If fixed-sized packets are used, with chained
>encryption, I think you have as good a system as you do with all of your
>inter-node encryption and signing.
>
 
The way you suggest to standardize packet sizes leaves the system
vulnerable to matching the top of the body of the messages in a repeated-
message attack.
 
>Suppose one good encrypted message enters the net with 10 unencrypted
>ones.  Won't the full path of each of the 10 be visible to an outsider?
>Even if the remailer helps out those 10 doltish users by encrypting them
>from there on out, the outsider already saw their whole paths!  They will
>know how many unencrypted messages are going out to each destination, and
>from that determine where the encrypted message is going.
 
Not with rational use of garbage.  With rational use of garbage, the system
could protect a single encrypted message--if the recipient or sender is "in
the box".  BTW, it may be impractical for senders to be "in the box", as
described, as they cannot know exactly when ticks occur.  I believe it can
be done, though.
 
>Of course it was Chaum himself in his 1981 paper (which I think is available
>from the CP FTP site) who described the duplicate-message attack.  I don't
>see that inter-remailing encryption helps much, because the attacker can
>still notice that whenever they inject message A, _something_ goes to
>Bob.  The real solution, as Chaum pointed out, is that the remailer must
>reject duplicate messages, even when separated by days.  Doing this without
>keeping a database of all messages ever sent is left as an exercise.
>
 
I disagree.  If identical input to Chaum does not produce identical output
to Bob, how does Eve coorelate them?  Repeating, she can match the top of
the body of messages, so random tails reveal the actual encrypted message,
for whatever that is worth.
 
And if Bob receivs x packets per tick, or a BIG packet every tick, how does
Eve trace it?
 
 
>Another aspect worth mentioning is that message splitting can make the
>kinds of statistical correlations that Wei Dai was looking at more of
>a danger. 
 
More than being the ONLY file in the net of your (approximate) size?
 
>          It's one thing if I send a message along with thousands of
>other people, and Bob gets a message along with everyone else.  But if I
>send 10 messages and Bob gets 10 from that batch, that fact alone can
>help to link us up.  So splitting my big message into 10 standard ones
>isn't that great if they're all sent at once.  Ideally you'd want to
>dribble them out at some standard rate, a rate at which you always send
>a message whether you have something to send or not.  But this may introduce
>unacceptable latency.
 
"Dribble them out at some standard rate".  Yes.  y packets per tick.  Set y
equal to your average number of real packets per tick, plus 3 standard
deviations.  Since you are chaining, the latency of you input will be less
than the latency of the remailernet.
 
Nathan
 
"PGP?"                        "ITAR!"                          "Oh, RKBA!"
 
 
                   |--------------------------------------------------+
  ----------------- 14712B4D 1994/12/26 Nathan H. Zook <nzook@bga.com> )
 |44B3D866 3D551E2E ---------------------------------------------------
 |F89222A6 338CDE24/ |
  -----------------