2005 Mortgage Max Lead Plans

[The-Leads-Network.com...A Different Kind Of Leads Company]

    The Leads Network
   You Want To Grow - We Want To Help


































   In case you have not been to our site lately, we offer 3 different types of mortgage lead plans to fit multiple budgets, and this from a supplier that stands behind all leads and only charges after delivery.  Plus, our set-up fee has been lowered to only $15 instead of the usual $99.  
Daily XP Exclusive Premier Mortgage* These leads are received and sent to you DAILY for only $25 each for Purchase or Refi lead  - Statewide marketing area needed.  Guaranteed to receive no less than 10 per week.
Weekly Excel Deluxe Mortgage Leads - About 7 days old for only $10 each Statewide territory needed.  Shared no more than 4 times.
Monthly Direct Internet Leads - About 4 weeks old for only $4.00 each.  Fall Special: Order 100 per week and them for $3.75 each plus 10 more leads free! 
All of the above are Filterable. All $75K+, 7.5% +, <90%, Good/Excl Credit unless otherwise requested. 
*All of these leads are guaranteed fresh and exclusive. Minimum order of 5 leads in any one week. Week-to-Week flexibility.
The BEST possible time to gain critical market share is now!

Exclusive & Shared Leads 
"Do Not Call" Screened for your protection  
Lowest industry rates (See our great pricing options) 
Proven prospect marketers and scripts 
Lead subscriptions are truly limited with exclusive territories options 
Suspend Account Feature 
Access Leads Anywhere via our unique Lead Q online 
Download leads in Word, Excel, HTML, & Email formats 
Best customer service in Leads industry 
We GUARANTEE our leads!


 501.767.2705
 ORDER





























Quick Links Below:


Lead Order Form: www.The-Leads-Network.com/registernow.html
Sample Leads: www.The-Leads-Network.com/samples.html
 



















© 2004 The-Leads-Network

This email was sent by The-Leads-Network.com...A Different Kind Of Leads Company, 104 Gareth Court Suite#104, Hot Springs, Arkansas 71913, using Express Email Marketing.  You subscribed to this permission-based list on 10/20/2004.To change preferences or to unsubscribe, click here or type the following in your browser address bar: http://app.quicksizzle.com/unsubscribe.aspx?id=2756&sid=9790459&campaignId=16684Express Email Marketing supports permission-based email marketing; click here to report abuse or type the following in your browser address bar: http://app.quicksizzle.com/unsubscribe.aspx?id=2756&sid=9790459&campaignId=16684&spam=true

Re: Type III Anonymous Message from Antani anonymous remailer

[R.A. Hettinga]

At 9:06 PM +0100 1/18/05, [EMAIL PROTECTED] wrote:
>Where are the remailer mail2news gateways still operating?
>If there are any anymore...

This is great. I've been watching, via bittorrent, Lucy Lawless' "Warrior
Women" series. The last episode is about Lozen, the Apache medicine-woman
who was sister of Antonio, one of the last chiefs of the Chiricahaua band,
who raided up and down the Black Range in Southeast New Mexico (Hillsboro,
a town in the front range of which, was where my father retired and died,
which was why I was interested in the episode; I remember reading "Black
Range Tales", and other western memoirs of the time, when I was a kid).

She died in Alabama (by way of Florida and Oklahoma) of tuberculosis, 20
years after being captured in New Mexico.

There's an echo in here.

Cheers,
RAH

-- 
-
R. A. Hettinga 
The Internet Bearer Underwriting Corporation 
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

[i2p] weekly status notes [jan 18] (fwd from jrandom@i2p.net)

[Eugen Leitl]

- Forwarded message from jrandom <[EMAIL PROTECTED]> -

From: jrandom <[EMAIL PROTECTED]>
Date: Tue, 18 Jan 2005 12:30:27 -0800
To: [EMAIL PROTECTED]
Subject: [i2p] weekly status notes [jan 18]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi y'all, weekly update time

* Index
1) Net status
2) 0.5
3) i2pmail.v2
4) azneti2p_0.2
5) ???

* 1) Net status

Hmm, not much to report here - things still work as they did last
week, size of the net is still pretty similar, perhaps a little
larger.  Some neat new sites are popping up - see the forum [1]
and orion [2] for details.

[1]http://forum.i2p.net/viewforum.php?f=16
[2]http://orion.i2p/

* 2) 0.5

Thanks to the help of postman, dox, frosk, and cervantes (and
everyone who tunneled data through their routers ;), we've
collected a full day's worth of message size stats [3].  There are
two sets of stats there - height and width of the zoom.  This was
driven by the desire to explore the impact of different message
padding strategies on the network load, as explained [4] in one of
the drafts for the 0.5 tunnel routing.  (ooOOoo pretty pictures).

The scary part about what I found digging through those was that by
using some pretty simple hand-tuned padding breakpoints, padding to
those fixed sizes would still ended up with over 25% of the
bandwidth wasted.  Yeah, I know, we're not going to do that.
Perhaps y'all can come up with something better by digging through
that raw data.

[3] http://dev.i2p.net/~jrandom/messageSizes/
[4] http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/
 tunnel.html?rev=HEAD#tunnel.padding

Actually, that [4] link leads us into the state of the 0.5 plans for
the tunnel routing.  As Connelly posted [5], there has been a lot of
discussion lately on IRC about some of the drafts, with polecat,
bla, duck, nickster, detonate and others contributing suggestions
and probing questions (ok, and snarks ;).  After a little more than
a week, we came across a potential vulnerability with [4] dealing
with an adversary who was somehow able to take over the inbound
tunnel gateway who also controlled one of the other peers later in
that tunnel.  While in most cases this by itself wouldn't expose the
endpoint, and would be probabalistically hard to do as the network
grows, it still Sucks (tm).

So in comes [6].  This gets rid of that issue, allows us to have
tunnels of any length, and solves world hunger [7].  It does open
another issue where an attacker could build loops in the tunnel, but
based on a suggestion [8] Taral made last year regarding the session
tags used on ElGamal/AES, we can minimize the damage done by using
a series of synchronized pseudorandom number generators [9].

[5] http://dev.i2p.net/pipermail/i2p/2005-January/000557.html
[6] http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/
tunnel-alt.html?rev=HEAD
[7] guess which statement is false?
[8] http://www.i2p.net/todo#sessionTag
[9] http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/
tunnel-alt.html?rev=HEAD#tunnel.prng

Don't worry if the above sounds confusing - you're seeing the
innards of some gnarly design issues being wrung out in the open.
If the above *doesnt* sound confusing, please get in touch, as we're
always looking for more heads to hash through this stuff :)

Anyway, as I mentioned on the list [10], next up I'd like to get the
second strategy [6] implemented to hash through the remaining
details.  The plan for 0.5 is currently to get all of the backwards
incompatible changes together - the new tunnel crypto, etc - and
push that as 0.5.0, then as that settles on the net, move on to the
other parts of 0.5 [11], such as adjusting the pooling strategy as
described in the proposals, pushing that as 0.5.1.  I'm hoping we
can still hit 0.5.0 by the end of the month, but we'll see.

[10] http://dev.i2p.net/pipermail/i2p/2005-January/000558.html
[11] http://www.i2p.net/roadmap#0.5

* 3) i2pmail.v2

The other day postman put out a draft plan of action for the next
generation mail infrastructure [12], and it looks bloody cool.  Of
course, there are always yet more bells and whistles we can dream
up, but its got a pretty nice architecture in many ways.  Check out
what's been doc'ed up so far [13], and get in touch with the postman
with your thoughts!

[12] http://forum.i2p.net/viewtopic.php?t=259
[13] http://www.postman.i2p/mailv2.html

4) azneti2p_0.2

As I posted to the list [14], the original azneti2p plugin for
azureus had a serious anonymity bug.  The problem was that mixed
torrents where some users are anonymous and others are not, the
anonymous users would contact the non-anonymous users /directly/
rather than through I2P.  Paul Gardner and the rest of the azureus
devs were quite responsive and put out a patch right away.  The
issue I saw is no longer present in azureus v. 2203-b12 +
azneti2p_0.2.

We haven't gone through and audited the code to review any p

FW: Securing Wireless Apps in Vertical Markets Webinar from Unstrung

[Tyler Durden]

Sometimes these webinars can be informative, sometimes they're thinly 
disguised marketing efforts (that can still have some small value, though).

Dear Colleague,
As an industry professional, you may be interested to know about an 
upcoming online event being presented by Unstrung (www.unstrung.com), the 
worldwide source for analysis of the wireless economy. This free Web 
seminar - " Securing Wireless Apps in Financial, Government & Military 
Markets" - will evaluate recent progress in a critical market.

Keeping information out of the hands of interlopers is an important task 
for any net manager - but it's critical for those with the responsibility 
for keeping financial, governmental, and military applications secure. 
Security issues continue to be the main concern holding back widespread 
wireless adoption in these environments.

During this presentation we'll focus on:
- The critical role of security in these vertical markets - why does it 
matter?
- Potential effects of wireless network attacks in each market
- The diverse security demands of these three markets
- Case studies of deployments in each market and lessons learned

Join us on Thursday,  January 27, at 2:00 p.m. New York / 7:00 p.m. London 
time, for this live Webinar sponsored by Bluesocket and Proxim.

To sign up for the Webinar, please register through the following link:
http://metacast.agora.com/link.asp?m=23153&s=4936527&l=0
Hope to see you there!
Unstrung




If you wish to be taken off this list, simply reply to this message and
include the word "unsubscribe" in the subject field - or visit the link
provided below. You will be taken off automatically.
http://www.lightreading.com/unsubscribe.asp?subscriberid=4936527
Light Reading Inc.
23 Leonard St.
New York, NY 10013

Type III Anonymous Message from Antani anonymous remailer

[nobody]

This is a Type III anonymous message, sent to you by the Winston Smith
Project mixminion server at firenze.linux.it. If you do not want to
receive anonymous messages, please contact antani-
[EMAIL PROTECTED] For more information about anonymity, see
https://remailer.firenze.linux.it or
https://e-privacy.firenze.linux.it.

-BEGIN TYPE III ANONYMOUS MESSAGE-
Message-type: plaintext

Where are the remailer mail2news gateways still operating?  
If there are any anymore...
Stale pages serving up dead links to defunct services.
Google has let me down.
-END TYPE III ANONYMOUS MESSAGE-

Re: panix.com hijacked

[Justin]

On 2005-01-16T09:46:28-0500, R.A. Hettinga wrote:
> On Sun, 16 Jan 2005 [EMAIL PROTECTED] wrote:
> > On Sun, 16 Jan 2005 01:32:46 EST, Henry Yen said:
> > >
> > > . panix.net usable as panix.com (marcotte) Sat Jan 15 10:44:57 2005
> >
> > So let's see.. the users will see this when they log into shell.panix.net
> > (since shell.panix.com is borked). Somehow that doesn't seem to help much.
> 
> and the hijackers could be, potentially, running a box pretending to be
> shell.panix.com, gathering userids and passwds :(

Object lesson in why using replayable passwords is not a good idea.
Allah invented nonce-based password hashes and public key crypto for a
reason.

-- 
"War is the father and king of all, and some he shows as gods, others as
men; some he makes slaves, others free." -Heraclitus Kahn.83/D-K.53

http://www.inet-one.com/cypherpunks/dir.2000.03.20-2000.03.26/msg00041.html

[Kane at InternetSeer]

Title: AtWatch : Advance Web Site Monitoring






	


  
	  This email is being sent to cypherpunks@minder.net as part of your InternetSeer Web site monitoring service. 
	  Your email address has not been given to any Third Parties. InternetSeer controls all e-mail delivery to assure your 
	  privacy. If you receive multiple emails you may have more than one InternetSeer account. 
	  Consolidate your accounts today by joining InternetSeer's Priority Club.
	  






  

  


  
  

  
  


  
  

  
  

  
  

  
  

  
  


  

  
  

  

  


  


  


  


  
  


  
  

  


  

  
  

  

  
  
 

  
  [EMAIL PROTECTED] 
  Phone number: (610) 361-7751 





  

Every 5 Minutes or
  20 Minutes or
  60 Minutes
  
  

Minimize your downtime by as much as 90%!
  
  

And warn you of any changes
  to your website!
  

  

  
   


  
  

  
   


  
  


  

  
   Click Here to Learn more   

  
  
  
  

  





This email is being sent to cypherpunks@minder.net as part of your InternetSeer Web site monitoring service. 
Your email address has not been given to any Third Parties. InternetSeer controls all e-mail delivery to assure your privacy.
If you no longer wish to have InternetSeer monitor your Web site and provide you with email 
alerts when there is a problem accessing your Web site, performance reports on a weekly basis as well 
as special email promotions,   Select this link to be permanently removed from any future mailings and to terminate your account on InternetSeer. 
InternetSeer 381 Brinton Lake Road, Thornton Pennsylvania 19373.
##7g7j5Y49sxX6v76OwKWTWxWD7671ExUKz=e3##

Austrac beefs up for e-crime fight

[R.A. Hettinga]

Australian IT

Austrac beefs up for e-crime fight
Simon Hayes
JANUARY 18, 2005

INTERNET payment systems such as PayPal and e-gold face extra regulation as
part of a legislative package designed to stop terrorists and criminals
laundering cash through offshore bank accounts.

Proprietary payments systems - which escape Australian transactions
reporting requirements because the actual transactions take place overseas
- are a prime target of laws being drafted by the Federal
Attorney-General's Department.

 The laws follow a parliamentary inquiry into cybercrime last year, which
was told that the internet had made it easier for criminal and terrorist
money launderers to avoid surveillance.

 In a submission to the Joint Committee on the Australian Crime Commission,
Austrac warned some cyber-transactions were beyond its reach.

 "It's essential that Australia's regulatory and law enforcement, revenue
and national security programs are adequately supported by appropriate
legislation, and to ensure that Australia's anti-money-laundering and
counter-terrorist financing systems are not compromised," the organisation
said.

 Austrac keeps an eagle eye on traditional funds transfers, scanning some
nine million telegraphic transactions in and out of Australia each year,
but those using internet-based systems escape the net.

 While Australian banks are required to report transactions to Austrac, the
agency has warned of "uncertainty" about whether internet payments were
reportable, as the bank transaction often took place overseas.

 Austrac acting director Liz Atkins said she hoped the new legislation - to
be released in draft form soon - would plug those gaps.

 "It's a grey area as to whether internet payments systems are caught as
cash dealers," she said. "Currently the answer is no, they don't have to
report.

 "The question is whether the new legislation should cover them."

 Ms Atkins said Austrac was concerned criminals could operate internet
payment systems in conjunction with offshore bank accounts and credit
cards, purchasing goods and services in Australia, but settling the bills
overseas, beyond the reach of Austrac.

 A spokesman for Attorney-General Philip Ruddock said the draft bill would
be released early this year.

 "Officers from the Attorney-General's Department and Treasury have been
exploring the extent to which these services operate in the Australian
financial system and what further regulation, if any, may be required to
comply with the Financial Action Taskforce recommendations" he said.

 PayPal managing director Andrew Pipolo said the organisation - owned by
internet auction giant eBay - was committed to working with law enforcement
agencies.

 "PayPal is obliged under the Financial Transactions Reporting Act to
report suspicious transactions," he said.

 "Both eBay and PayPal work closely with law enforcement agencies to assist
them in investigating and capturing online criminals.

 "We have zero tolerance to any wrongdoing on PayPal.

 "There are more than 1000 employees at eBay and PayPal dedicated to making
eBay one of the safest places in the world to trade."



-- 
-
R. A. Hettinga 
The Internet Bearer Underwriting Corporation 
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

Webpay system open to voucher fraud

[R.A. Hettinga]

The Register


 Biting the hand that feeds IT

The Register » Security » Network Security »

 Original URL: http://www.theregister.co.uk/2005/01/17/webpay_voucher_fraud/

Webpay system open to voucher fraud
By Jan Libbenga (libbenga at yahoo.com)
Published Monday 17th January 2005 16:46 GMT

Webpay International AG, the market leading payment system for digital
content and services in Europe, doesn't offer a flawless micro payment
service, at least in the Netherlands, according to Dutch consumer watchdog
tv show Kassa and computer weekly Computer Idee. It is relatively easy to
manipulate user data required for the Dutch MSN music download site (TV
item in Dutch over here
(http://cgi.omroep.nl/cgi-bin/streams?/tv/vara/kassa/bb.laatste.asf?start=00:16:24&end=00:26:13)
).

The payments for that site are handled by Webpay under its original name
Firstgate. Firstgate users can buy online vouchers and decide which songs
they want to purchase later. Kassa and Computer Idee discovered that these
vouchers can be easily purchased by filling in someone else's name and bank
details. Users can even add money to their prepaid account, again using
details from other users. None of this information is verified by
Firstgate. Even though upgrading the account requires a pin code, it isn't
necessary to enter the code straight away. The song or album to be
purchased can be downloaded immediately.

Firstgate, which offers the same service for cable operator Chello, doesn't
deny that this kind of fraud is possible, but stresses that that fraudsters
can be traced and will be prosecuted. However, the company wasn't too
thrilled with the publicity and originally threatened to sue broadcaster
VARA.

Webpay International licenses its micropayment click&buy service also to
British Telecom, and to Swisscom, which launched Swisscom click&buy in Q4
2004.

-- 
-
R. A. Hettinga 
The Internet Bearer Underwriting Corporation 
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

Re: [i2p] Tunnel cryptography for I2P 0.5 (corrected typo)

[jrandom]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Thanks Connelly for the writeup and the discussion,

> The following is a discussion of tunnel cryptography plans for
> I2P 0.5.  There are two options; one will be chosen.

A few key changes were missed in this draft, and I've incorporated
all of the suggestions from yesterday into [1].  The explanation of
the overall rationale for the two different strategies is largely
correct.  This is still a work in progress, and will be improved as
we get both more feedback and clarify some issues.

[1]http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel-alt.html?rev=HEAD

An implementation of the crypto for first strategy [2] has been
created [3], but as there are some weaknesses in inbound tunnels
when dealing with colluding attackers who also control the gateway,
the second strategy seems more appealing.  Next up I'd like to get
that implemented into code so that any further issues can be fleshed
out, as well as to make concrete what it is that is being specified.

[2]http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel.html?rev=HEAD
[3]http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/java/src/net/i2p/router/tunnel/

Of course, none of those html docs are a finished spec for I2P
overall as they assume familiarity with the other non-tunnel-related
parts of I2P and do not include the relevent references to where we
snagged our ideas ;)  This is just a state-of-the-design view into
the 0.5 tunnel revamp.

Anyway, thanks again for the updates Connelly, and if anyone is
looking for the details currently planned for, please see [1].
Suggestions/comments/criticisms always welcome, or if you want to
get involved, please get in touch!  We're in #i2p on irc.freenode.net
and on irc.duck.i2p pretty much all the time.

=jr
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFB7PDaGnFL2th344YRAnP2AKDuaTX7TNnYa0AuCpc2B90XSluy6QCg7LDv
uPddHM1YB6v3RqwBbCXPUGg=
=+AIK
-END PGP SIGNATURE-

Delivery Notification: Delivery has failed

[Internet Mail Delivery]

This report relates to a message you sent with the following header fields:

  Message-id: <[EMAIL PROTECTED]>
  Date: Tue, 18 Jan 2005 09:46:37 +0200
  From: cypherpunks@minder.net
  To: [EMAIL PROTECTED]
  Subject: hi

Your message cannot be delivered to the following recipients:

  Recipient address: [EMAIL PROTECTED]
  Reason: Remote SMTP server has rejected address
  Diagnostic code: smtp;554 <[EMAIL PROTECTED]>: Relay access denied
  Remote system: dns;mail2.cc.huji.ac.il (TCP|84.95.2.7|19815|132.64.1.18|25) 
(mail2.cc.huji.ac.il ESMTP Postfix)

Reporting-MTA: dns;i_mtaout3.012.net.il (tcp-daemon)

Original-recipient: rfc822;jose@teachers.org.il
Final-recipient: rfc822;jose@teachers.org.il
Action: failed
Status: 5.0.0 (Remote SMTP server has rejected address)
Remote-MTA: dns;mail2.cc.huji.ac.il (TCP|84.95.2.7|19815|132.64.1.18|25)
 (mail2.cc.huji.ac.il ESMTP Postfix)
Diagnostic-code: smtp;554 : Relay access denied
Return-path: 
Received: from tcp-daemon.i_mtaout3.012.net.il by i_mtaout3.012.net.il
 (HyperSendmail v2004.12) id <[EMAIL PROTECTED]>; Tue,
 18 Jan 2005 09:48:30 +0200 (IST)
Received: from minder.net ([212.116.164.11])
 by i_mtaout3.012.net.il (HyperSendmail v2004.12)
 with ESMTP id <[EMAIL PROTECTED]> for
 [EMAIL PROTECTED]; Tue, 18 Jan 2005 09:48:30 +0200 (IST)
Date: Tue, 18 Jan 2005 09:46:37 +0200
From: cypherpunks@minder.net
Subject: hi
To: [EMAIL PROTECTED]
Message-id: <[EMAIL PROTECTED]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=WINDOWS-1255
Content-transfer-encoding: QUOTED-PRINTABLE
X-Priority: 3
X-MSMail-priority: Normal

[i2p] Tunnel cryptography for I2P 0.5 (corrected typo) (fwd from barnesc@engr.orst.edu)

[Eugen Leitl]

- Forwarded message from [EMAIL PROTECTED] -

From: [EMAIL PROTECTED]
Date: Mon, 17 Jan 2005 22:15:33 -0800
To: [EMAIL PROTECTED]
Subject: [i2p] Tunnel cryptography for I2P 0.5 (corrected typo)
User-Agent: Internet Messaging Program (IMP) 3.2.6


Citizens of I2P,

The following is a discussion of tunnel cryptography plans for
I2P 0.5.  There are two options; one will be chosen.

[1] and [2] offer more complete discussion of these plans.  Note that
the cryptographic methods discussed in [2] are incomplete.  They are
complete in this message.

 - Connelly

--
Tunnel cryptography for I2P 0.5
--

Currently when I2P 0.4.x passes an (end-to-end encrypted) message M
down a tunnel, it is easy for two attackers in different locations of
the tunnel to observe the same message M.  This makes I2P highly
vulnerable to the predecessor attack.

Can this situation be improved?

The best implementations we currently know of fit in two categories,
and use symmetric cryptography.  The categories are:

1. The inbound tunnel gateway knows all symmetric private keys used by
   other hops in the tunnel.  The outbound tunnel endpoint knows only
   its own symmetric private key.  Messages are checksummed to prevent
   modification.

   Pros: Tagging attacks are defeated.
   Cons: Attacking an N-length inbound tunnel won't be much harder
 than attacking a 2-length inbound tunnel.  If the gateway is
 malicious, then the gateway can collude with a malicious hop
 at any other position in the tunnel; thus the two can
 identify that they are in the same tunnel.
 => Predecessor attack.

   This was one plan by jrandom.  A proposed implementation is given
   [1].  This implementation could be subject to tagging attacks in
   certain cases.  I have a revised scheme in mind that may be safe
   from these attacks.

2. The inbound tunnel gateway has only its own symmetric private key.
   Likewise for the outbound tunnel endpoint.  No messages are
   checksummed in the tunnel.  All messages have the same size in
   the tunnel to prevent tagging.  Synchronized PRNGs may be used as
   described at [2] to help prevent tunnel loops (where an attacker
   DoSes several peers by placing them a "looped" tunnel).

   Pros: Attacking an N-length inbound tunnel is not easy (one must do
 timing or message counting analysis).
   Cons: Tagging (this can be done, but not detected), tunnel loops
 can be created, extra packets can be generated within the
 tunnel.

   This plan was originally drafted in [2] based on a discussion by
   jrandom and ???.  However, this document has pending modifications
   because it is not a complete cryptosystem.  A full implementation
   plan is appended to the end of this document, based on a discussion
   by jrandom and Connelly.


One of these options will (presumably) be used in I2P 0.5.  If you
discover a flaw or improvement for either implementation, let us
know.  If you have other useful input, drop by IRC or post a message
to this maillist.

We have not found a complete cryptographic analysis for either option.
We are using standard cryptographic primitives and methods when
possible.

Option 2 is known as a "non-checksummed tunnel."

--
Proposed Implementation (non-checksummed tunnels)
--

Leaving out the PRNGs.

As part of a tunnel, we receive and send messages which contain
{preIV, payload}.  Here preIV is a single block from which the
initialization vector (IV) is derived, and payload is a sequence of
blocks containing the message which is being delivered down the
tunnel.  Here 'block' is any string which the symmetric block cipher
can operate on.  The preIV and the payload are successively wrapped
in layers of encryption as a message travels down an inbound tunnel,
and messages are successively unwrapped for outbound tunnels.

Encryption at hop i:
1. Drop packet (with warning) if we've seen preIV before
   for a previous message in this tunnel [3].
2. IV := hash(preIV + hop i's secret key 1)
3. preIV  := ecb_encrypt(preIV, hop i's secret key2)
4. payload:= cbc_encrypt(payload, hop i's secret key3, IV)
5. Return {preIV, payload}.

Decryption at hop i:
1. preIV  := ecb_decrypt(preIV, hop i's secret key2)
2. IV := hash(preIV + hop i's secret key1)
3. payload:= cbc_decrypt(payload, hop i's secret key3, IV)
4. Return {preIV, payload}.

Inbound tunnel:
 * Message M arrives at the inbound gateway, aka hop 1.
 * Hops 1, 2, ..., N successively encrypt.
 * We are the tunnel endpoint, and we have everyone's secret keys,
   so we can use decrypt(N), decrypt(N-1), ...decrypt(1) to unwrap
   the encryption made by others.  We recover mes