Re: cypherpunks@minder.net closing on 11/1

[cyphrpunk]

On 10/13/05, Brian Minder <[EMAIL PROTECTED]> wrote:
> The minder.net CDR node will be shutting down on November 1, 2005.  This
> includes the cypherpunks-moderated list.  Please adjust your subscriptions
> accordingly.

Gmail would facilitate automating a new cypherpunks-moderated list.
Gmail's spam filtering is great and even a regular cypherpunks
subscription has almost no spam.

Sign up a gmail account and subscribe it only to cypherpunks. Use the
POP interface to fetch message from gmail, and redistribute those to
the new cypherpunks-moderated list. Subscribers gain the anti spam
features of cp-moderated without any manual filtering or moderating
necessary.

CP

Blood, Bullets, Bombs and Bandwidth

[R.A. Hettinga]

--- begin forwarded text


 Date: Sat, 22 Oct 2005 01:50:38 -0400
 To: Philodox Clips List <[EMAIL PROTECTED]>
 From: "R.A. Hettinga" <[EMAIL PROTECTED]>
 Subject: Blood, Bullets, Bombs and Bandwidth

 The long version of the Wired Story on Ryan Lackey, including lots more
 about Tyler Wagner, who I've been reading about almost since he got there
 after the liberation :-) in 2003...

 Just bumped into the bit below, having abandoned Tyler and Jayme's LJs
 after they split, and finding the link after they went back recently.

 Meanwhile, the author bought the wrong vowel, apparently. ;-).

 Cheers,
 RAH
 --

 

 Blood, Bullets, Bombs, and Bandwidth:
 a tale of two California cipherpunks who went to Baghdad to seek their
 fortune, and bring the Internet to Iraq.

 Ryan Lackey wears body armor to business meetings. He flies armed
 helicopters to client sites. He has a cash flow problem: he is paid in
 hundred-dollar bills, sometimes shrink-wrapped bricks of them, and flowing
 this money into a bank is difficult. He even calls some of his company's
 transactions "drug deals" - but what Lackey sells is Internet access. From
 his trailer on Logistics Staging Area Anaconda, a colossal US Army base
 fifty miles north of Baghdad, Lackey runs Blue Iraq, surely the most
 surreal ISP on the planet. He is 26 years old.

 Getting to Anaconda is no joke. Incoming airplanes make a 'tactical
 descent' landing, better known to military cognoscenti as the 'death
 spiral'; a nose-down plummet, followed by a viciously tight 360-degree
 turn, then another stomach-wrenching dive. The plane is dragged back to
 level only just in time to land, and brakes so hard that anything not
 strapped down goes flying forward. Welcome to "Mortaritaville" - the
 airbase's mordant nickname, thanks to the insurgent mortars that hit the
 base daily.

 From above, the base looks like a child's sandbox full of thousands of
 military toys. Dozens of helicopters litter the runways: Apaches,
 Blackhawks, Chinooks. F-16 fighters and C-17 cargo planes perch in huge
 igloo-like hangars built by Saddam. The roads are full of Humvees and
 armored personnel carriers. Rows of gunboats rest inexplicably on arid
 desert. A specific Act of Congress is required to build a permanent
 building on any US military base, so Anaconda is full of tents the size of
 football fields, temporary only in name, that look like giant caterpillars.
 Its 25,000 inhabitants, soldiers and civilian contractors like Ryan, are
 housed in tent cities and huge fields of trailers.

 Ryan came to Iraq in July 2004 to work for ServiceSat International, hired
 sight unseen by their CTO Tyler Wagner. Three months later, Ryan quit and
 founded Blue Iraq. He left few friends behind. "I think if Ryan had
 stayed," Tyler says drily, "the staff would have sold him to the
 insurgents."

 - - -

 Iraq is new to the Internet. Thanks to sanctions and Saddam, ordinary
 citizens had no access until 1999. Prewar, there were a mere 1.1 million
 telephone lines in this nation of 26 million people, and fewer than 75 Net
 cafés, connecting via a censored satellite connection. Then the American
 invasion knocked nearly half of Baghdad's landlines out of service, and the
 local exchanges that survived could not connect to one another.

 After the invasion, an army of contractors flooded into Baghdad. Billions
 of reconstruction dollars were being handed out in cash, and everybody -
 local Internet cafés, Halliburton, Ahmed Chalabi, the US military itself -
 wanted Internet access. With the landline service destroyed by war, and
 sabotage a continuing problem, satellite access was the only realistic
 option. Among the companies vying to provide this access in early 2003,
 scant months after the invasion, was ServiceSat International. SSI, a
 startup founded by Kurdish expats, needed an American CTO: partly to import
 America's culture of technical excellence, partly to help deal with Western
 clients and authorities. They called Tyler Wagner. He was 25 years old.

 - - -

 San Francisco, aka Baghdad-by-the-Bay, July 2003. Tyler Wagner is a typical
 counterculture California techie: a Cal Poly CS graduate, part of the
 California punk scene, working for Greenpeace as a network engineer. Then
 an old friend in London recommends him to SSI. They call him. They need a
 capable Westerner willing to move to Iraq. Is he interested?

 When he hangs up the phone, Tyler is shaking with excitement. The risks of
 relocating to a war zone are obvious. But it is a lucrative senior
 management position, offered to a man only two years out of university.
 "Life doesn't often offer you a hand up like that," he reminisces two years
 later, "and when it does, you can't afford to turn it down." One big
 complication: Tyler's girlfriend, Jayme. They have been dating only six
 months. He doesn't want to lose her. He calls and tells her the news - and
 they both ask at the same time if 

Re: [fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems

[R.A. Hettinga]

At 11:17 AM -0700 10/21/05, someone who can't afford a vowel, Alex, ;-)
expressed his anal glands thusly in my general direction:

>You're such an asshole.

My, my. Tetchy, this morning, oh vowelless one...

At 11:17 AM -0700 10/21/05, cyphrpunk wrote:
>This is what you characterized as a "unitary global claim". Aside from
>the fact that "unitary" is meaningless in this context, his claim was
>far from "global".

That's "One size fits all", for those of you in Rio Linda. A little bit of
an Irwin Corey joke for the apparently humor-impaired. Be careful now, I'll
start on the Norm Crosby stuff soon, and you might get an aneurysm, or
something.

>While Daniel Nagy has been a model of politeness and modesty in his
>claims here, you have reverted to your usual role as an arrogant
>bully.

Moi?

I kick sand in your face on a beach somewhere I don't remember about?

Seriously, I tell him who did an exchange protocol, Silvio Micali, and that
they're a dime a dozen, second only to Mo' An' Better Auction Protocols,
and he wants me to go out on google, same as *he* can do, and do his work
for him.

Feh.

At 11:17 AM -0700 10/21/05, cyphrpunk wrote:
>I would encourage Daniel not to waste any more time interacting with Hettinga.

Indeed. Especially when he makes with the wet-fish slapping-sounds you do
when actual words are supposed to come out of your mouth. Okay, maybe it's
another orifice. At any rate, you are lacking some, shall we say, ability
to express yourself, on the subject. Be careful, though. Burroughs has this
great cautionary tale about teaching your asshole to talk, speaking of the,
heh, devil...

Cheers,
RAH
Who'll start in on insulting his mother soon, unless Mr. "cyphrpunk" has
taken that Charles Atlas course he send out for. Hint: Be grateful you
don't have any nipple-hair to get caught in the NEW IMPROVED Charles Atlas
Chest Expander's springs. Hurts like hell, I hear, and deadlifts work
*much* better...
-- 
-
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: [fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems

[cyphrpunk]

On 10/20/05, Daniel A. Nagy <[EMAIL PROTECTED]> wrote:
> On Thu, Oct 20, 2005 at 03:36:54PM -0700, cyphrpunk wrote:
> > As far as the issue of receipts in Chaumian ecash, there have been a
> > couple of approaches discussed.
> >
> > The simplest goes like this. If Alice will pay Bob, Bob supplies Alice
> > with a blinded proto-coin, along with a signed statement, "I will
> > perform service X if Alice supplies me with a mint signature on this
> > value Y". Alice pays to get the blinded proto-coin Y signed by the
> > mint. Now she can give it to Bob and show the signature on Y in the
> > future to prove that she upheld her end.
>
> I like this one, though there might be a problem if Alice does everything,
> except giving Bob the signed version of Y in the end. I can imagine scenarios
> where this might be a problem.
>
> However, it can be relatively easily solved if the mint publishes every
> signed proto-coin (instead of being handed to the payer, it goes to the
> public records, from where the payer can retrieve it). There's no reason not
> to.

Good idea! Even without this, if there is a problem then everything
will come out in the dispute resolution phase, where Alice will be
forced to reveal the mint's signature. Bob may claim at that time
never to have seen it before, while Alice may claim that she had sent
it earlier, but once they get this far both sides will be forced to
agree that Bob has now been paid so the contract can be completed. So
this method would be OK for contracts where timeliness is not an
important issue. But your idea of having the mint publish its
signatures could help even more.


> > A slightly more complicated one starts again with Bob supplying Alice
> > with a blinded proto-coin, which Alice signs. Now she and Bob do a
> > simultaneous exchange of secrets protocol to exchange their two
> > signatures. This can be done for example using the commitment scheme
> > of Damgard from Eurocrypt 93. Bob gets the signature necessary to
> > create his coin, and Alice gets the signed receipt (or even better,
> > perhaps Bob's signature could even constitute the service Alice is
> > buying).
>
> This one requires additional infrastructure which needs to be rolled out,
> which is expensive. Simultaneous exchange of secrets is an elegant
> cryptographic feat, but the required tools are not available to the general
> public right now and the motivation to obtain them are insufficient. Thus, a
> system relying on this cannot be phased in cheaply.

I'm not sure what costs you see here. There are two main technologies
I am familiar with for signature (or general secret) exchange. One is
purely local and involves bit by bit release of the signatures. Both
parties first commit to their signatures and use ZK proofs to show
that the committed values are in fact signatures over the required
data. They then release their sigs a bit at a time, taking turns. If
one party aborts prematurely he has at most a factor of 2 advantage
over the other in a brute force search to find the missing bits of the
signature. While this takes many rounds, it is still pretty fast. Of
course the users don't manually initiate each round, it all happens
automatically under control of the software. I saw some code to
implement this a couple of years ago somewhere on Sourceforge. It
actually exchanged PGP signatures, of all things. It does not take any
new infrastructure.

The other technology is so-called "optimistic" exchange, where the
signatures are provably encrypted to the public key of a trusted third
party. The two parties each exchange such encryptions and prove they
are valid. Then they exchange the actual signatures in the
straighforward manner. If one party does not send his sig, the other
can go to the TTP and get it. Since this option exists, there is no
incentive for the parties not to complete the transaction and hence
the TTP will in practice almost never be used. This one does require
the TTP to exist and his public key to be available, but that should
be no more new infrastructure than is required for the cash issuer and
his key to be distributed. In fact the issuer could be the TTP for
dispute resolution if desired.

> The desirability of a payment vehicle depends on the assortment of goods and
> services available for it. Now, the lack of non-reversibility might be
> either a show-stopper or a significant additional cost in the case of some
> goods and services, while receipts are required in the case of others.
>
> Both might be required for transactions in the $100 ... $1000 range between
> a power-seller and one-time buyers in a low-trust environment. From the
> seller's point of view, the risk of a reversal might not be acceptable
> (basically, he cannot assess the probability of it, while the cost is
> substantial), because the value is too high, so he needs irreversibility.
> From the buyer's point of view, the risk of losing the money is not
> catastrophic, but highly undesirable; he wants to be abl

Re: [fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems

[cyphrpunk]

On 10/20/05, R.A. Hettinga <[EMAIL PROTECTED]> wrote:
> At 12:32 AM +0200 10/21/05, Daniel A. Nagy wrote:
> >Could you give us a reference to this one, please?
>
> Google is your friend, dude.
>
> Before making unitary global claims like you just did, you might consider
> consulting the literature. It's out there.

You're such an asshole. Daniel's actual statement was simply:

>> I know of no protocol for transfering blinded tokens with a receipt, but I
>> do not rule out the possibility of its existence.

This is what you characterized as a "unitary global claim". Aside from
the fact that "unitary" is meaningless in this context, his claim was
far from "global". Instead it was a very modest statement about what
aspects of the technology he was familiar with, and explicitly
admitted the possibility that he might be mistaken. I don't think you
could ask for anything more in a world where no one has perfect
knowledge about any topic.

While Daniel Nagy has been a model of politeness and modesty in his
claims here, you have reverted to your usual role as an arrogant
bully. If Daniel's project should be successful then you will
undoubtedly switch over to your other mode of communication,
obsequious ass-kissing. I have experienced both from you, in my many
names and roles, and I have no taste for either one.

I would encourage Daniel not to waste any more time interacting with Hettinga.

CP

Phearmcy Add sense

[Leocadio Vides]

Lion was caught by some hunters, who bound him by st ropes to the  together to consider the best means of protecting it from the  
 VjAGRR.A Now $69
S.oama
UIttra.m
CjALLj.S Now $99
Xana.nax
Prropec.ja
VAL.LjUM Now $84
Amn.bjen
Proaza.c
L.evvjtra

 And many other http://dualismxwq.madintrotcom
Have a nice day
--had not given up the rights of the ash, we might yet have  mirror every day: you, my son, that you may not spoil your beauty  never have indulged your ears at the cost of your belly.  well-read scholar, who gave up high civil distinctions that he  very great amusement.  

Re: Judy Miller needing killing

[Tyler Durden]

Cyphrpunk wrote...



The notion that someone who is willing to spend months in jail just to
keep a promise of silence "needs killing" is beyond bizarre and is
downright evil. This list supports the rights of individuals to tell
the government to go to hell, and that is exactly what Judy Miller
did. She should be a hero around here. It's disgusting to see these
kinds of comments from a no-nothing like "Major Variola".



While I agree that Variola has his bizarre moments, much of what he says at 
least merits further investigation. He partially fills a role that May 
filled, before his final descent into madness...


I, for one, welcome his return to posting, and it's not too much effort to 
hit the delete button on a post-by-post basis.


-TD

[EMAIL PROTECTED]: nym-0.4 released (now includes Javascript)]

[Eugen Leitl]

- Forwarded message from Jason Holt <[EMAIL PROTECTED]> -

From: Jason Holt <[EMAIL PROTECTED]>
Date: Fri, 21 Oct 2005 09:22:34 + (UTC)
To: [EMAIL PROTECTED]
Subject: nym-0.4 released (now includes Javascript)
Reply-To: [EMAIL PROTECTED]


The most notable feature in this release of nym is that you can now use nym 
entirely from your web browser:

http://www.lunkwill.org/src/nym/javascript/jsnymclient.html

Until someone figures out how to create client certificate requests in 
Javascript, the CA will have to do so instead (or, you could generate the 
request on a separate machine and paste it in with a trivial hack).  This 
means the CA will know your certificate's private key; this is bad if you 
want to make sure you can never be impersonated.  It's actually good if you 
want deniability, since you can always claim that the CA chose to 
impersonate you.

There are other miscellaneous bugfixes which break compatibility with 
earlier versions.

Sources (including the javascript client) are available here, as always:

http://www.lunkwill.org/src/nym/

-J

- End forwarded message -
-- 
Eugen* Leitl http://leitl.org";>leitl
__
ICBM: 48.07100, 11.36820http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE


signature.asc
Description: Digital signature

[EMAIL PROTECTED]: Re: SSL fro hidden services]

[Eugen Leitl]

- Forwarded message from "Dan Mahoney, System Admin" <[EMAIL PROTECTED]> 
-

From: "Dan Mahoney, System Admin" <[EMAIL PROTECTED]>
Date: Thu, 20 Oct 2005 19:18:08 -0400 (EDT)
To: [EMAIL PROTECTED]
Subject: Re: SSL fro hidden services
Reply-To: [EMAIL PROTECTED]

On Thu, 20 Oct 2005, loki tiwaz wrote:

>hi,
>
>That said, the certificate naming scheme may be way off, since there's 
>no concept of a valid certificate (I doubt verisign will want to sign 
>one for 786237261871621.onion :)
>
>i am considering running an onion-based CA which could be used... i simply 
>need to make a script which allows a user to sign a certificate signing 
>request and produce a signed server key. the server key only needs to have 
>its onion address as content, nothing more is required, and a link to 
>import the CA key into the browser so that it can be trusted automatically 
>by the browser.
>
>However, assuming the user installs your self-signed cert, it *should* 
>work the same unless there's something I'm missing.)
>
>Of course, you're really just protecting content from being sniffed 
>between the user and the entry node (usually, the same machine, but not 
>always), and the exit node and the hidden service (presumably, you 
>control both).
>
>This is my understanding of it -- if someone has a better one please 
>step on me without hesitation :)
>
>yes, this is the case, and it is a valid reason to use ssl. in my opinion, 
>since tor already uses multi-layered encryption anyway, one more layer at 
>the core is not going to create that much of an extra load on the server, 
>and it means that there is no way the traffic can be sniffed at any point - 
>for example a trojan could sniff localhost traffic. also, using onion 
>routing defeats the one way in which SSL can be attacked, by 
>man-in-the-middle intermediaries on the network pathway, which of course 
>cannot be known within the tor network. Also, it should be noted that tor 
>exit nodes could potentially be modified to become men-in-the-middle, 
>although this would not be possible without compromising the key of the 
>server being contacted - another aspect of the advantage of using tor.
>
>onion addresses are impossible to remember though - which brings me to 
>another idea - of a name resolution system within the tor network so 
>simpler names can be used. this would require a second directory system, i 
>don't know if it is practical or not, but i thought i should put the idea 
>out there because i2p has name resolution systems, and benig able to type 
>in oniondomainname.onion rather than u15syoa125au.onion would be nice. it 
>would increase the rate of take-up of hidden services, both use and hosting.

The other thing that could be interesting of course is an onion-only 
search engine, which could either compliment or reduce the need for vanity 
names.

Still, I don't see why the directory servers can't maintain this info.  It 
would have to (for the most part) be first-come first-served, and I 
suppose some sort of uptime monitoring should also play a part (i.e. if 
you don't use it for say 6 months, you lose it).

Shame there's not a whole lot of clients that make use of SRV records, as 
an onion specifier in there could prove remarkably useful in some way.

--

"If you aren't going to try something, then we might as well just be
friends."

"We can't have that now, can we?"

-SK & Dan Mahoney,  December 9, 1998

Dan Mahoney
Techie,  Sysadmin,  WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144   AIM: LarpGM
Site:  http://www.gushi.org
---

- End forwarded message -
-- 
Eugen* Leitl http://leitl.org";>leitl
__
ICBM: 48.07100, 11.36820http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE


signature.asc
Description: Digital signature

[EMAIL PROTECTED]: Re: SSL fro hidden services]

[Eugen Leitl]

- Forwarded message from loki tiwaz <[EMAIL PROTECTED]> -

From: loki tiwaz <[EMAIL PROTECTED]>
Date: Thu, 20 Oct 2005 22:57:24 +
To: [EMAIL PROTECTED]
Subject: Re: SSL fro hidden services
Reply-To: [EMAIL PROTECTED]

hi,

That said, the certificate naming scheme may be way off, since there's 
no concept of a valid certificate (I doubt verisign will want to sign 
one for 786237261871621.onion :)

i am considering running an onion-based CA which could be used... i simply 
need to make a script which allows a user to sign a certificate signing 
request and produce a signed server key. the server key only needs to have 
its onion address as content, nothing more is required, and a link to import 
the CA key into the browser so that it can be trusted automatically by the 
browser.

However, assuming the user installs your self-signed cert, it *should* 
work the same unless there's something I'm missing.)

Of course, you're really just protecting content from being sniffed 
between the user and the entry node (usually, the same machine, but not 
always), and the exit node and the hidden service (presumably, you 
control both).

This is my understanding of it -- if someone has a better one please 
step on me without hesitation :)

yes, this is the case, and it is a valid reason to use ssl. in my opinion, 
since tor already uses multi-layered encryption anyway, one more layer at 
the core is not going to create that much of an extra load on the server, 
and it means that there is no way the traffic can be sniffed at any point - 
for example a trojan could sniff localhost traffic. also, using onion 
routing defeats the one way in which SSL can be attacked, by 
man-in-the-middle intermediaries on the network pathway, which of course 
cannot be known within the tor network. Also, it should be noted that tor 
exit nodes could potentially be modified to become men-in-the-middle, 
although this would not be possible without compromising the key of the 
server being contacted - another aspect of the advantage of using tor.

onion addresses are impossible to remember though - which brings me to 
another idea - of a name resolution system within the tor network so simpler 
names can be used. this would require a second directory system, i don't 
know if it is practical or not, but i thought i should put the idea out 
there because i2p has name resolution systems, and benig able to type in 
oniondomainname.onion rather than u15syoa125au.onion would be nice. it would 
increase the rate of take-up of hidden services, both use and hosting.

onion domains could be propagated throughout the onion network, so that 
every tor node can translate a name into an onion hashed address. there 
would also need to be a system to prevent name spoofing... how to ensure 
there is no collisions of names would be tricky - very likely it would 
require a set of authoritative name servers similar to how there is 
authoritative onion directory servers.

ah dammit, i am always ideas ideas ideas and so little action... 
prioritising goals is something i find difficult... i think i should make 
this idea a priority, however, which means joining the dev effort and, at 
the very least, defining a protocol, if not implementing code... well, 
anyway, i have put the idea out now. i think that the idea is a good one. 
tor is coming of age now and ideally tor should aim to provide all of the 
features one would expect in an internet layer, but with the guiding 
principle of protecting anonymity always ascendant. an onion-based CA would 
work much better if the name-resolution system were in place, so i think it 
should be the priority.

loki

_
FREE pop-up blocking with the new MSN Toolbar - get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/

- End forwarded message -
-- 
Eugen* Leitl http://leitl.org";>leitl
__
ICBM: 48.07100, 11.36820http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE


signature.asc
Description: Digital signature

Re: [fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems

[R. Hirschfeld]

> Date: Thu, 20 Oct 2005 11:31:39 -0700
> From: cyphrpunk <[EMAIL PROTECTED]>

> >  2. Cash payments are final. After the fact, the paying party has no
> >  means to reverse the payment. We call this property of cash
> >  transactions _irreversibility_.
> 
> Certainly Chaum ecash has this property. Because deposits are
> unlinkable to withdrawals, there is no way even in principle to
> reverse a transaction.

This is not strictly correct.  The payer can reveal the blinding
factor, making the payment traceable.  I believe Chaum deliberately
chose for one-way untraceability (untraceable by the payee but not by
the payer) in order to address concerns such as blackmailing,
extortion, etc.  The protocol can be modified to make it fully
untraceable, but that's not how it is designed.

> >  3. Cash payments are _peer-to-peer_. There is no distinction between
> >  merchants and customers; anyone can pay anyone. In particular, anybody
> >  can receive cash payments without contracts with third parties.
> 
> Again this is precisely how Chaum ecash works. Everyone can receive
> ecash and everyone can spend it. There is no distinction between
> buyers and vendors. Of course, transactions do need the aid of the
> issuer, but that is true of all online payment systems including
> Daniel's.

Apart from the transferability issue, I think there are some systems
that do not rely on an issuer at all (in effect any payee is an
issuer).  Manasse's Millicent comes to mind, but I confess that I
don't fully remember the details.

Ray