For Telecom Workers, Burst Of Bubble Takes Heavy Toll (was: employment market for applied cryptographers?)

[Steve Schear]

[Because of its relevance and since most list members are probably not WSJ 
subscribers, I've taken the liberty of posting the entire article. sds]

> From the Wall Street Journal --
>
>For Telecom Workers, Burst Of Bubble Takes Heavy Toll
>By REBECCA BLUMENSTEIN
>
>RICHARDSON, Texas -- Two years ago, J. Michael Dugan spread the word to
>his fellow optical engineers in North Texas that he was starting a company
>that could make them all rich. The telecommunications business was hot,
>and optical engineers were the hottest commodities of them all, commanding
>big signing bonuses and six-figure salaries.
>
>Mr. Dugan, a burly Texan with more than 20 years under his belt at the
>giant French equipment maker Alcatel SA, was persuasive. So many flocked
>to his annual summer party in July 2000 to learn more about Latus
>Lightworks that he ran out of food. The start-up took off quickly, hiring
>120 employees as the engineers raced to devise ways to squeeze more data
>and voice traffic through a hair-thin strand of fiber-optic glass.
>
>Then the bubble burst.
>
>A few weeks ago, when all those engineers gathered again in Mr. Dugan's
>backyard, it was to commiserate and swap job leads. Ken Maxham, a cheery
>59-year-old who comes from a long line of engineers, was worried about his
>unemployment benefits running out as his savings dwindle. He had cut back
>expenses as much as possible, but basic health insurance costs $750 a
>month and his wife was putting off going to the dentist for a toothache.
>
>David Wolf, who at 37 is one of the youngest optical engineers around, was
>counting the days until his second start-up was due to run out of money.
>The fresh-faced father of three young children was pruning expenses such
>as his daughter's gymnastics lessons and worrying about the future. Mr.
>Dugan, whose work as a temporary consultant was about to end, was
>contemplating returning to school at age 50.
>
>And the party was buzzing about a cruel twist of fate: Two of the former
>colleagues had just gone head-to-head for one of the few remaining telecom
>jobs out there. The one in the more precarious financial position didn't
>get it.
>
>"When I see someone I haven't seen in a while, my first question is, 'Do
>you have a job?' " said Bruce Raeside, a 46-year-old Michigan native who
>also worked as a Latus engineer. "It's almost like Detroit in the '70s."
>
>In many ways, it's worse. Like the massive declines in the nation's steel,
>oil and automobile industries in decades past, the disintegration of the
>telecom business is leaving deep wounds in the U.S. work force. But labor
>historians say telecom stands out for the unprecedented speed of the
>boom-and-bust cycle. After telecom was deregulated in 1996, it quickly
>expanded by some 331,000 jobs before peaking in late 2000. Since the
>downturn started, though, companies have announced layoffs that have wiped
>out all those new jobs and more -- a total of well over 500,000 workers,
>according to a tally by The Wall Street Journal. By contrast, it took two
>decades for the ranks of the United Auto Workers to fall to 732,000 from
>1.5 million, as the auto industry was forced to become much more efficient
>in the face of foreign competition.
>
>The number of telecom jobs grew faster and has fallen much harder than the
>overall job market, according to James Glen, an economist with
>Economy.com, a West Chester, Pa., research firm. He says the 12% drop in
>telecom jobs is still gaining steam, especially as the rout claims bigger
>and bigger companies such as Global Crossing Ltd. and WorldCom Inc. And
>the economic and human cost of the telecom bust far exceeds that of the
>highly publicized Internet crash, which by and large involved smaller
>companies.
>
>Telecom has turned into one of history's biggest bubbles because so much
>money poured into the industry during the stock-market boom, creating some
>$470 billion in debt and a vast glut of capacity. Once a sleepy industry
>known for its modest growth, telecom took off like a rocket in the late
>'90s as companies rushed to lace the world with ultra-fast fiber-optic
>networks to carry an expected onslaught of Internet traffic. But after a
>frenzy of spending and hiring, it suddenly became clear in mid-2001 that
>the Internet wasn't growing nearly as fast as the 1,000-fold annual
>increases originally predicted. The huge run-up has now been replaced by a
>merciless ride down. Rumors of foreclosures and marital problems have
>replaced word of the latest IPO. Some laid-off telecom workers are even
>turning up in local homeless shelters.
>
>So much money was spent buying telecom gear during the frenzy that there
>is now seven years' worth of excess inventory, says Lonnie Martin, chief
>executive of White Rock Networks, a Richardson start-up that is trying to
>hang on. He values the excess supply at some $160 billion. "That is an
>awful lot of exuberance to get rid of," he says.
>
>There are few places where the hangover is mo

alternate dos pgp client?

[Anonymous]

The latest release of Mixmaster claims to be an "OpenPGP enhancement
release".  I looked at the source more closely, and it seems to contain an
entire pgp implementation.  I had previously thought it made external calls
to either pgp or gnupg.

This got me thinking - has anyone tried hacking mixmaster to be a pgp
client?  I have compiled it under DOS before, so I know that is possible.
Does anyone know if mixmaster can use 'non-legacy' RSA keys?  Is there any
pgp functionality that it lacks?  I am looking for a pgp implementation that
will run on DOS, but will also be compatible with modern key types.

Chaum's unpatented ecash scheme

[Nomen Nescio]

David Chaum gave a talk at the Crypto 2002 conference recently in which
he briefly presented a number of interesting ideas, including an approach
to digital cash which he himself said would "avoid the ecash patents".

The diagram he showed was as follows:


Optimistic Authenticator

 z = x^s

Payer f(m)^a z^b Bank
  ->

[f(m)^a z^b]^s
  <-

   m, f(m)^s
  ->


It's hard to figure out what this means, but it bears resemblance to a
scheme discussed on the Coderpunks list in 1999, a variant on a blinding
method developed by David Wagner.  See
http://www.mail-archive.com/coderpunks@toad.com/msg02323.html for a
description, with a sketch of a proof of blindness at
http://www.mail-archive.com/coderpunks@toad.com/msg02387.html and
http://www.mail-archive.com/coderpunks@toad.com/msg02388.html.

In Chaum's diagram it is not clear which parts of the key are private and
which public, although z is presumably public.  Since the bank's action
is apparently to raise to the s power, s must be secret.  That suggests
that x is public.  However Chaum's system seems to require dividing by
(z^b)^s in order to unblind the value, and if s is secret, that doesn't
seem possible.

In Wagner's scheme everything was like this except that the bank's key
would be expressed as x = z^s, again with x and z public and s secret.
f(m) would be a one-way function, which gets doubly-blinded by being
raised to the a power and multiplied by z^b, where a and b are randomly
chosen blinding factors.  The bank raises this to its secret power s,
and the user unblinds to form f(m)^s.  To later deposit the coin he does
as in the third step, sending m and f(m)^s to the bank.

For the unblinding, the user can divide by (z^b)^s, which equals z^(b*s),
which equals (z^s)^b, which equals x^b.  Since x is public and the user
chose b, he can unblind the value.  Maybe the transcription above of the
Chaum scheme had a typo and it was actually similar to the Wagner method.

Chaum commented that the payer does not receive a signature in this
system, and that he doesn't need one because he is protected against
misbehavior by the bank.  This is apparently where the scheme gets
its name.

Re: Bankrupt Digicash Made $481K in 1999

[John Young]

Yes, Steve, the 1099 describes payments made to others, or is 
supposed to, but 1099s are shifty and don't always conform to reality. 

So if you believe the 1099, Digicash either made at least $481K
or got it somehow or just made up the number in a venture to
fleece a lender or flummox a Chaum Family doubter. 

Note the checked box for "corrected." What was originally reported is
unknown. But whoever got stiffed by Digicash's bankruptcy might
like to know more about where the $481, real or fictional, came from 
as well as how that compares to what was initially "incorrectly" 
reported to IRS, to the bankruptcy court and to debtors -- some
of the latter, as noted here long ago, are aggrieved employees.

Note also that the 1099 is not signed and dated. Whether it is
a draft or final is unknown. Could even be a piece of pure shit
sunshine in accord with never, ever lie to the IRS principal
all citizens follow.

Robert, WTF you asking? The doc came from Anonymous,
the one and only reliable source. Inhale, hold it.

Re: Bankrupt Digicash Made $481K in 1999

[R. A. Hettinga]

At 5:59 PM -0700 on 8/20/02, John Young wrote:


> Robert, WTF you asking?

A mere rhetorical question, of course.

> The doc came from Anonymous,
> the one and only reliable source.

It was ever thus.

> Inhale, hold it.

ffttt...Wow...  That's some real thunderfuck, J.

Beats the hell out of the stuff you pulled out of your sock last week. I
mean, that shit was *foul*, man...


Cheers,
RAH
Damn, I'm hungry. Anybody wanna go in on a pizza? In the meantime, I've got
some cheetos stashed around here somewhere...

-- 
-
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: Seth on TCPA at Defcon/Usenix

[Bill Stewart]

At 12:58 AM 08/11/2002 -0700, Lucky Green wrote:

>BTW, does anybody here know if there is still an email time stamping
>server in operation? The references that I found to such servers appear
>to be dead.

The canonical timestamping system was Haber & Stornetta's work at
Bellcore, commercialized at Surety.com.  The site is current,
has some Digital Notary Service and Secure Email things on it,
and something much more amazing - it looks like they received
$7M in financing in June :-)

There's a nice collection of pointers to timestamping systems at
http://saturn.tcs.hut.fi/~helger/crypto/link/timestamping/
though I don't know how current the references are -
the page was last updated 14.8.2002.

The free PGP-based system http://www.itconsult.co.uk/stamper.htm
has a news item from 04-Jun-02, which comments that,
although they haven't posted any news items in five years,
they've been in continuous operation

Re: Bankrupt Digicash Made $481K in 1999

[Greg Broiles]

At 12:12 PM 8/20/2002 -0700, Steve Schear wrote:
>At 12:33 PM 8/20/2002 -0700, you wrote:
>>Digicash 1999 IRS forms:
>>
>>   http://cryptome.org/digicash-481k.htm
>
>Perhaps its my ignorance, but doesn't this form merely mean DC paid the 
>Chaum Family Trust $481K, not  that the company made $481K?

(since the PKI market's been in the toilet, I've been learning about taxation)

Even that assumes too much - there wasn't necessarily a transfer of money. 
If, for example (and this is purely hypothetical), Chaum had agreed to work 
for DC in exchange for 1,000,000 shares of stock, and $481K was the fair 
market value of those shares, then it would be proper to issue a 1099-MISC 
with that amount in Box 3 and Chaum would be taxed on that $481K as income, 
even though he received it as stock instead of cash.

(If the circumstances were different, the income might be expected to show 
up in Box 7, "nonemployee compensation"; but here it's in Box 3, which 
should transfer directly either to Line 21 on the 1040 for miscellaneous 
income, or onto a Schedule C, assuming it's an individual taxpayer, which 
isn't the case here.)

This sort of 1099 is also what you'd expect to see going to the recipient 
of cash as damages following or related to a lawsuit.

If Digicash loaned money to Chaum and later forgave the debt (not unusual, 
where a founder or other important employee wants to exercise stock options 
early but doesn't have cash for the exercise), Chaum would be obligated to 
report the forgiven debt as income but a 1099 would not be required; that 
doesn't stop people from sending them anyway.


--
Greg Broiles -- [EMAIL PROTECTED] -- PGP 0x26E4488c or 0x94245961

IETF WG on SMTP feeler...

[Anonymous]

There has been an awful lot of discussion on this here in CP land, 
so maybe some responses too?

A good place to put forward suggestions to make hard calculations
a requirement of delivery or maybe some digicash to pay for it?

  ***


Date: Tue, 20 Aug 2002 16:12:51 -0700 (PDT)
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: IETF SMTP Working Group Proposal at smtpng.org


This is copy of the message sent to IETF mail list. As subject said,
I'd like to organize IETF working group to define new additions to SMTP.


As everyone I'm sure have seen on the last "why is spam a problem" and
other similar threads on ietf as well as numerous similar threads on
other lists and boards, there is a serious need to do something to limit
amount of unsolicited email. While the roots maybe social issue I do not
see why we can not work on it from technical point of view. In addition
to that during last years, I'v seen real need for new features to be
added into SMTP, such as ones for callback, delayed transmission, delivery
notification,secure communications, etc, etc and there are in fact
several drafts available on some issues. As far as anti-spam  mechanisms I
do not belive we should force some particular method on everyone but
rather built several verification features into protocol and allow server
operators to themselve choose if they want to use it. Where the features
were use the email would be considered more secure and users can use that
to sort out mail (as many do already with special filters).

I believe its time we start working within IETF on new version of SMTP
that would have more features and be more secure. I'v tried to point this
out several times before on nanog and ietf hoping that someone would take
the initiave but as this did not happen, I'm willing to do it now. At this
point I'm proposing creation of IETF working group that would look into
ways to extend SMTP. I'v created website and mailing list to discuss
charter of the proposed working group at http://www.smtpng.org

Those who agree with me, please subscribe to the mailing list and lets
work on this futher in a kind-of BOF. I'm also looking for two co-chairs
for the working group with at least one preferablly having been chair of
ietf group before. I'm planning on sending final draft for working group
charter in about two weeks time and right now I'm going to be contacting
several people who have expressed interest in working on SMTP protocol as
well as contacting IETF area director on proceeding with this.

--
William Leibzon
[EMAIL PROTECTED]

Re: alternate dos pgp client?

[Adam Back]

I put together a list of openpgp related software at:

http://www.cypherspace.org/openpgp/

this includes library only code, and add on software.

Not sure about your questions about key versions, but I forwarded it
to Ulf Moeller and Len Sassaman (current maintainer of mix3).

>From what I've seen mix3 (pgptest app) is the closest to providing a
command line.  There was also Tom Zerucha's reference openPGP code,
which is command line but it's alpha level code I think and no longer
maintained.

Adam

On Tue, Aug 20, 2002 at 09:28:47PM -0500, Anonymous wrote:
> The latest release of Mixmaster claims to be an "OpenPGP enhancement
> release".  I looked at the source more closely, and it seems to contain an
> entire pgp implementation.  I had previously thought it made external calls
> to either pgp or gnupg.
> 
> This got me thinking - has anyone tried hacking mixmaster to be a pgp
> client?  I have compiled it under DOS before, so I know that is possible.
> Does anyone know if mixmaster can use 'non-legacy' RSA keys?  Is there any
> pgp functionality that it lacks?  I am looking for a pgp implementation that
> will run on DOS, but will also be compatible with modern key types.

Re: Chaum's unpatented ecash scheme

[Ben Laurie]

Nomen Nescio wrote:
> David Chaum gave a talk at the Crypto 2002 conference recently in which
> he briefly presented a number of interesting ideas, including an approach
> to digital cash which he himself said would "avoid the ecash patents".
> 
> The diagram he showed was as follows:
> 
> 
> Optimistic Authenticator
> 
>  z = x^s
> 
> Payer f(m)^a z^b Bank
>   ->
> 
> [f(m)^a z^b]^s
>   <-
> 
>m, f(m)^s
>   ->
> 
> 
> It's hard to figure out what this means, but it bears resemblance to a
> scheme discussed on the Coderpunks list in 1999, a variant on a blinding
> method developed by David Wagner.  See
> http://www.mail-archive.com/coderpunks@toad.com/msg02323.html for a
> description, with a sketch of a proof of blindness at
> http://www.mail-archive.com/coderpunks@toad.com/msg02387.html and
> http://www.mail-archive.com/coderpunks@toad.com/msg02388.html.
> 
> In Chaum's diagram it is not clear which parts of the key are private and
> which public, although z is presumably public.  Since the bank's action
> is apparently to raise to the s power, s must be secret.  That suggests
> that x is public.  However Chaum's system seems to require dividing by
> (z^b)^s in order to unblind the value, and if s is secret, that doesn't
> seem possible.
> 
> In Wagner's scheme everything was like this except that the bank's key
> would be expressed as x = z^s, again with x and z public and s secret.
> f(m) would be a one-way function, which gets doubly-blinded by being
> raised to the a power and multiplied by z^b, where a and b are randomly
> chosen blinding factors.  The bank raises this to its secret power s,
> and the user unblinds to form f(m)^s.  To later deposit the coin he does
> as in the third step, sending m and f(m)^s to the bank.
> 
> For the unblinding, the user can divide by (z^b)^s, which equals z^(b*s),
> which equals (z^s)^b, which equals x^b.  Since x is public and the user
> chose b, he can unblind the value.  Maybe the transcription above of the
> Chaum scheme had a typo and it was actually similar to the Wagner method.

Sounds like it.

> 
> Chaum commented that the payer does not receive a signature in this
> system, and that he doesn't need one because he is protected against
> misbehavior by the bank.  This is apparently where the scheme gets
> its name.

Note that the scheme as described (and corrected) is vulnerable to 
marking by the bank, and so is not anonymous. This is discussed and 
fixed in my paper on Lucre 
(http://anoncvs.aldigital.co.uk/lucre/theory2.pdf).

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/

Available for contract work.

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

Re: Cryptographic privacy protection in TCPA

[Adam Back]

On Sun, Aug 18, 2002 at 04:58:56PM +0100, Adam Back wrote:
> [...] "Also relevant is An Efficient System for Non-transferable
> Anonymous Credentials with Optional Anonymity Revocation", Jan
> Camenisch and Anna Lysyanskaya, Eurocrypt 01
> 
>   http://eprint.iacr.org/2001/019/
> 
> These credentials allow the user to do unlinkable multi-show without
> involving a CA.  They are somewhat less efficient than Chaum or Brands
> credentials though.  But for this application does this removes the
> need to trusting a CA, or even have a CA: the endorsement key and
> credential can be inserted by the manufacturer, can be used
> indefinitely many times, and are not linkable.

There was some off-list discussion about possibility for sharing these
credentials once a given credential is extracted from it's TPM by a
user who broke the tamper resistance of his TPM.

I also said:

> [...] Credentials which are shared are easier to revoke -- knowledge
> of the private keys typically will render most schemes linkable and
> revocable.  This leaves only online lending which is anyway harder
> to prevent.

Because Camenisch credentials are unlinkable multi-show it makes it
harder to recognize sharing, so the user could undetectably share
credentials with a small group that he trusts.  

(By comparison with linkable pseudonymous credentials and a privacy CA
the issuer and/or verifier would see unusually high activity from a
given pseudonym or TPM endorsement key if the corresponding credential
were shared too widely.)

However if the Camenisch (unlinkable multi-show) credential were
shared too widely the issuer may also learn the secret key and hence
be able to link and so revoke the overly-shared credentials.  This
combats sharing though to a limited extent.

Another idea to improve upon this inherent risk of sharing too widely
may be to use a protocol which it is not safe to do parallel shows
with.  (Some ZKPs are not secure when you engage in multiple show
protocols in parallel.  Usually this is considered a bad thing, and
steps are taken to allow safe parallel show.)  

For this application a show protocol which it is not safe to engage in
parallel shows may frustrate sharing: someone who shared the
credential too widely would have difficulty coordinating amongst the
sharees not to show the same credential in parallel.  I notice
Camenisch et al mention steps to avoid parallel showing problem, so
perhaps that feature could be reintroduced.

In contrast, the TPM can easily ensure that the credential is not used
in parallel shows.

Adam
--
http://www.cypherspace.org/adam/

Discouraging credential sharing with Mojo

[Anonymous]

Some credential issuing schemes, such as those from Brands as well as from
Camenisch & Lysyanskaya, try to avoid credential sharing by embedding
into the credential some secret which is important and valuable to the
credential holder.  Then if the credential is shared, the recipient
learns the important secret, to the detriment of the person sharing
the credential.  So he won't do it.

The problem is that there don't seem to be any secrets that will work
well in discouraging sharing.  The most obvious is a credit card number,
but this has a number of problems: some people don't have credit cards;
people could cancel their credit cards after receiving the credentia;
and underground hackers have access to thousands of stolen credit card
numbers that they don't mind sharing.

Clearly we need a new approach.  Here is a suggestion for a simple
solution which will give everyone an important secret that they will
avoid sharing.

At birth each person will be issued a secret key.  This will be called
his Mojo.  He will also get the associated public key which will assist
in protocols which involve commiting to his Mojo.  The public key can
be revealed but the Mojo should be kept secret at all costs.

Then in a credential issuing protocol, the user embeds his Mojo into
his credential in a provable way.  It is important that the protocol
not reveal the Mojo to the issuer, but rather that some kind of zero
knowledge proof be used so that the issuer is confident that sharing
the credential will reveal the Mojo.

Now all that is needed is a simple change to the law so that knowing
someone's Mojo makes him your slave.

That is, if you know someone's Mojo you own him.  You get access to all
his money and all his assets.  You can force him to work for you and
take all he earns.  You can mistreat and even kill him.  If he tries to
escape, the Runaway Mojo Slave act will commit the government to tracking
him down and returning him to you.

With this small change to the law, everyone will be gifted with an
important secret which they can use to bind and commit themselves in
a variety of protocols.  By embedding their Mojo into their secret
credentials, they can assure the credential issuer that the credential
won't be shared.  Mojo can also serve as an "is a person" credential
and allow for secure electronic voting and other protocols where each
person should only participate once.

Please join me in supporting this important reform.

Just say, "I want my Mojo!"

Re: alternate dos pgp client?

[Len Sassaman]

On Tue, 20 Aug 2002, Anonymous wrote:

> This got me thinking - has anyone tried hacking mixmaster to be a pgp
> client?  I have compiled it under DOS before, so I know that is possible.
> Does anyone know if mixmaster can use 'non-legacy' RSA keys?  Is there any
> pgp functionality that it lacks?  I am looking for a pgp implementation that
> will run on DOS, but will also be compatible with modern key types.

It is possible to build a simple PGP client with the source you have --
the file pgptest.c offers that, but it's really only for debugging
purposes. Run "make mpgp" in the Src directory to try it.

A better interface to the standalone PGP functions shouldn't be hard to
write. We can look into that if there is demand for it. Note that
Mixmaster has no concept of the web of trust, and doesn't do keychain
management. It assumes that if you are placing a key on your keyring,
you've determined it is valid.

That said, Mixmaster does offer all the basic OpenPGP messaging
capabilities, except for verification of clear-signed messages. (This
wasn't needed for any of the features Mixmaster provides, so it wasn't
added.) We'll be adding this capability soon, however. (The author of
the QuickSilver Windows remailer client app has requested it. QuickSilver
provides PGP capabilities through the Mixmaster .dll, sans clearsig
verification.)

Mixmaster does support RSA v4 keys, though it doesn't have Twofish support
since it links against OpenSSL for its crypto, and OpenSSL doesn't have
Twofish support. If you have OpenSSL 0.9.7, Mixmaster will support AES.

(Also, Mixmaster now supports use of the Modification Code Detection
packet in OpenPGP messages, which is used to prevent the attack Schneier,
et al. recently wrote about.)

As far as DOS goes -- I honestly haven't tried compiling for DOS. It
"should" work. Please let me know if you run into any problems.

(And, as always, we're in need of developers and testers. If you're
interested in working on this project, please join the development mailing
list. See mixmaster.sf.net for more info.)


--Len.

Re: IETF WG on SMTP feeler...

[Morlock Elloi]

> There has been an awful lot of discussion on this here in CP land, 
> so maybe some responses too?
> 
> A good place to put forward suggestions to make hard calculations
> a requirement of delivery or maybe some digicash to pay for it?

SMTP will never change, assuming it is a pipe dream. There is no record of
basic internet protocol ever being changed away from compatibility (and guess
what, spammers won't upgrade.) Looks like desperate dotcommies.

If you want to be seen by the world, the world will send you shit. No way
around it.


=
end
(of original message)

Y-a*h*o-o (yes, they scan for this) spam follows:
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com

Re: Signing as one member of a set of keys

[Len Sassaman]

On Sat, 17 Aug 2002, Anonymous wrote:

> *** COULD SOMEONE PLEASE FOLLOW THE STEPS ABOVE AND PUT THE ringsig.c,
> ringsign, ringver, AND sigring.pgp FILES ON A WEB PAGE SO THAT PEOPLE
> CAN DOWNLOAD THEM WITHOUT HAVING TO GO THROUGH ALL THESE STEPS? ***

The files are available at:

http://www.abditum.com/~rabbi/ringsig/

Also, if you'd like to send me a more detailed blurb for the webpage, I'd
be happy to put it up. Otherwise, this will have to do.

> 9.  Please report whether you were able to succeed, and if not, which step
> failed for you.

I just ran into a bunch of errors when trying to compile with OpenSSL
0.9.7beta3. I'm debugging now...


--Len.