Re: bulk postage fine (was Re: non-censorous spam control)

On Sun, Aug 03, 1997 at 12:29:37PM +0100, Adam Back wrote:
> Here's the sequence of events as I see it:
> 
>  1. spammer spams you with adverisement for phone sex line
>  2. you try to sue phone sex line company
>  3. phone sex company denies all knowledge
>  4. government says all email must be authenticated 
>  5. government issues internet drivers license
>  6. anonymous remailers work around authentication requirement
>  7. government outlaws remailers
> 
> See any flaws in that logical and undesirable sequence of events?

The flaws become apparent if you try to attach a *realistic*
probability to each step.

-- 
Kent Crispin				"No reason to get excited",
kent@songbird.com			the thief he kindly spoke...
PGP fingerprint:   B1 8B 72 ED 55 21 5E 44  61 F4 58 0F 72 10 65 55
http://songbird.com/kent/pgp_key.html

At 10:05 AM -0700 8/6/97, Adam Back wrote:

>2) When the government or whoever wants to sue someone for spam they
>   will have to prove who the spammer is.  (Right?)  So now they'll
>   look at the From address at it will say remailer@foo.com.  So
>   they'll go have a chat to Fred Q Cypherpunk who operates foo, and he
>   won't be able to cooperate because he doesn't keep logs.  They won't
>   be happy with Fred, and will pass this information along to him by
>   stealing his equipment, prosecuting him for assisting in a felony
>   crime (they'll make it a felony right?), lock him and throw away
>   the key.  But what about Freds constitutional protection of the
>   speech forwarded by his remailer?  (Judge + congress-critter:
>   Constitution wassat?)

Delivery services are not held liable for the contents of the packages they
deliver, generally. (If they are parties to the crime, natch. And some say
they can be compelled to assist in law enforcement activities.)

Nor are delivery services required to "know their customer" or to have
ironclad proof of where a package originated. (Hell, even the U.S. Postal
Service allows mail with no valid return address, and this was my
experience in Europe as well.)

The "From:" field in e-mail is not to be confused with the "originator"
(whatever that may be).

Not even the U.S. courts are so dumb as to accept the claim that a package
delivered by the U.S. Postal Servie or by UPS means that Joe Deliveryman is
the "sender."

When this "From:" thing eventually gets to a court, I expect this
distinction will be obvious to all.

Remailers are just middlemen in a delivery process.

(Further protection in the U.S. comes from the ECPA, of course, which
explicitly makes it illegal for a middleman to examine e-mail. How can they
screen e-mail for illegal words if they are forbidden to look?)


--Tim May



There's something wrong when I'm a felon under an increasing number of laws.
Only one response to the key grabbers is warranted: "Death to Tyrants!"
---------:---------:---------:---------:---------:---------:---------:----
Timothy C. May              | Crypto Anarchy: encryption, digital money,
tcmay@got.net  408-728-0152 | anonymous networks, digital pseudonyms, zero
W.A.S.T.E.: Corralitos, CA  | knowledge, reputations, information markets,
Higher Power: 2^1398269     | black markets, collapse of governments.
"National borders aren't even speed bumps on the information superhighway."

Tim May <tcmay@got.net> writes:
> [...]
> Nor are delivery services required to "know their customer" or to
> have ironclad proof of where a package originated. (Hell, even the
> U.S. Postal Service allows mail with no valid return address, and
> this was my experience in Europe as well.)

Because there is a from address people get picky that it ought to
contain a valid return address.  Many ISPs apparently have policies
which state that you aren't allowed to do SMTP forgeries.

Paper mail doesn't have this expectation.  Pity the people who
designed SMTP didn't leave this one out -- at this point it would be
difficult to get a From field added.  They could have followed the
paper mail norm and left it to the user to include (or not) whatever
contact info he wanted.  Of course you can see the natural convenience
of a From, or Replyto field, which is why it's there.

Now that the from field is there, it'll be even harder to remove from
implementations and protocols... basically impossible.

Still the spam counter-measure which many people are starting to use
of forging headers to avoid getting their email snarfed helps reduce
the expectation that the From field will contain anything useful.

However that isn't the only problem... the series of Received headers
allow those with the know how to recognise and narrow down where
forged mail came from.  But usually only to a mail hub where it was
injected at best, and then often only tentative with out collaboration
with involved sites.

Course Received: headers have their uses also, to debug sendmail
configs, and work out where mail is going.  Still would have been nice
if the feature was only included in the SMTP delivery stuff when
debugging mode was turned on.

> The "From:" field in e-mail is not to be confused with the "originator"
> (whatever that may be).
> 
> Not even the U.S. courts are so dumb as to accept the claim that a package
> delivered by the U.S. Postal Servie or by UPS means that Joe Deliveryman is
> the "sender."
> 
> When this "From:" thing eventually gets to a court, I expect this
> distinction will be obvious to all.
> 
> Remailers are just middlemen in a delivery process.

I hope you're right.

I still think laws against spam are the wrong approach, even if the
courts declare remailers as delivery mechanisms only.

	"Write code, not Laws."

(Btw who's quote is that?  I like it and wanted to quote it in an
article on Eternity.)

Re spam problems and writing code and not laws, hashcash was my best
attempt:

	http://www.dcs.ex.ac.uk/~aba/hashcash/

However coding is not the only problem, the other is getting people to
use stuff.  Advertising, subscribing to appropriate newsgroups, going
to IETF meetings, deployment wins, but stuff dies due to little
investment in advocacy.  I haven't got the energy or resources to
advertise the above.  I reckon you could make nearly a full time job
just reading and corresponding with people on enough news admin groups
and mailing lists to get your message across to enough people to even
begin to make an impact.

I wrote the eternity service implementation 3 months ago, released
source code: no interest.  (Bar a few email messages saying "cool").
No demonstration system was the problem.

Mike Duvos provided a demonstration system last week when I reposted
the announce due to his discussing similar ideas, and poof: 4 eternity
servers, wired article, another request to write an article for some
magazine, offers to give talks at US universities.  Wew.

I also reckon, though obviously this is difficult to measure, that the
few hours invested in producing the flashy title bar graphics with a
more professional take off of the cypherpunks rose on field of entropy
logo and pirate skull with crossed-swords added more to the appeal of
the service than adding more features.  My normal HTML coding style of
drab grey with no graphics at all just doesn't look appealing.

Adam
-- 
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

On Fri, 8 Aug 1997, Adam Back wrote:

> > Remailers are just middlemen in a delivery process.
> 
> I hope you're right.
> 
> I still think laws against spam are the wrong approach, even if the
> courts declare remailers as delivery mechanisms only.
> 
> 	"Write code, not Laws."
> 
> (Btw who's quote is that?  I like it and wanted to quote it in an
> article on Eternity.)
> 
> Re spam problems and writing code and not laws, hashcash was my best
> attempt:
> 
> 	http://www.dcs.ex.ac.uk/~aba/hashcash/
> 
> However coding is not the only problem, the other is getting people to
> use stuff.  Advertising, subscribing to appropriate newsgroups, going
> to IETF meetings, deployment wins, but stuff dies due to little
> investment in advocacy.  I haven't got the energy or resources to

I think you never answered the fundamental question:

But to what advantage is it for *ME* to use hashcash?

Saying that it is neat, patriotic, pious, or any other adjective won't get
my anonymous mail through any faster unless you can create a cartel of
remailers that expidite hashcashed mail, or use some type of new remailer
that others don't have and build hashcash into the distribution. 

You still have the problem that a large organization can buy large
computers just to do hashcash - look for networkable hashcash generators
if it becomes popular.

If it doesn't solve an immediate problem, it is similar to advocating
solar energy when it is more expensive and/or cumbersome than fossil
fuels.  If/when enough remailers are clogged, hashcash is likely to be
adopted, but it is difficult to sell something when others offer the same
thing for free.

> I wrote the eternity service implementation 3 months ago, released
> source code: no interest.  (Bar a few email messages saying "cool").
> No demonstration system was the problem.
> 
> Mike Duvos provided a demonstration system last week when I reposted
> the announce due to his discussing similar ideas, and poof: 4 eternity
> servers, wired article, another request to write an article for some
> magazine, offers to give talks at US universities.  Wew.

Having interesting content draws interest, and proposing a method is far
from doing a prototype (questions like "are newsgroups stored long
enough?" and "will the cgi script work properly?" are only answered by
a working implementation, and a few of the eternity servers I tried
returned nothing from the links, but are probably fixed).

The legal problems still need to be resolved.  As long as no copyrighted
material appears I think things will be fine, but when MSwhatever appears,
someone is going to say the eternity server is like an illegal cable
descrambler or make up something very similar to ban them since they
aren't merely forwarding the content from alt.anonymous.messages - if
encryption is an envelope, the eternity server opens it.

Otherwise, you could simply post the plaintext to an alt group.  If that
doesn't happen now (why?), then adding an encryptor and decryptor isn't
going to change it, otherwise simply post the encrypted text, and the
passphrase in the same message, or the encrypted text, the secret key,
etc.  Except that the URL interface makes access more convienient.

--- reply to tzeruch - at - ceddec - dot - com ---

nospam-seesignature@ceddec.com writes:
> On Fri, 8 Aug 1997, Adam Back wrote:
> 
> > [hashcash]
> 
> I think you never answered the fundamental question:
> 
> But to what advantage is it for *ME* to use hashcash?
> 
> Saying that it is neat, patriotic, pious, or any other adjective won't get
> my anonymous mail through any faster unless you can create a cartel of
> remailers that expidite hashcashed mail, or use some type of new remailer
> that others don't have and build hashcash into the distribution. 

I wasn't talking about remailers above, but about end users.  Hashcash
allows the recipient to filter out email that hasn't got postage.

As an interim upgrade path ISPs adopting it could be to bounce
messages with out payments, and include a nonce, and instructions to
resend including the nonce.  Set up the filter so that the second post
gets through.  Spammers often don't have forged reply addresses for
obvious reasons.  

(If spam crept up too badly in-spite of this you could at that point
disable non-hash cash postage and give a URL for a java implementation
where they just go to the web page and their browser will generate
them some hash cash.  Obviously this is inconvenient so I would be
interested to see how the spammers adapted to just the nonce first.
It's much easier to block spammers if they have to include replyable
email addresses.)

You would also have a no-postage list, for mailing lists etc.


If we arrange so that spam won't get through without payment, it
disincentivizes spammers.  If some users go running around asking for
`government to do something about spam', it could be suggested to them
that it would be more effective to ask their ISP to install a hashcash
patched sendmail.

A remailer won't answer the bounce with nonce, so you automatically
won't get remailer traffic without postage -- unless you put remailers
on your no-postage list.

If you're some media celebrity and you get too much email -- just turn
up the squech, increase the postage required rate, and add people you
do want to your no-postage list.

You could auto-add anyone you ever manually replied to to the
no-postage list even.

> You still have the problem that a large organization can buy large
> computers just to do hashcash - look for networkable hashcash generators
> if it becomes popular.

I think the easiest initial way for the spammer to continue spamming
you would be to target mailing lists, using forged addresses.

Spam on mailing lists instead of mail is also a good thing for us,
because we already have solutions for spam on mailing lists:
decentralised 3rd party ratings -- NoCeMs can be applied to mailing
lists.  Allowing us to recommend good posts or mark what we consider
spam.  Individual users can decide which rating service to use.

If you consider that hashcash can be setup to only charge postage for
people you have never replied to in the past, this heavily
discriminates against people who send large amounts of mail to random
people.  (Which is precisely the spammers mailing pattern!)


Another solution with real ecash is to send ecash payment with mail
and have filters that will similarly bounce messages if there is no
ecash.

The recipient by societal convention is expected not to cash the
payment.  People who cash your money you don't tend to send more email
to.  You could easily charge $1 and that would be a high price for the
spammer -- it would be cheaper to snail mail you the spam.

The above doesn't seem very friendly, or very in keeping with the
spirit of free discourse.  I think hashcash is nicer in this respect.

I've taken the stuff on eternity to another message.

Adam
-- 
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

> As an interim upgrade path ISPs adopting it could be to bounce
> messages with out payments, and include a nonce, and instructions to
> resend including the nonce.  Set up the filter so that the second post
> gets through.  Spammers often don't have forged reply addresses for
> obvious reasons.  

I don`t think we even want to get into the issue of ISPs being involved 
in hashcash or any other form of postage, a better system is a simple 
user<->user model where the users mail reader can be configured to filter 
email without hashcash, procmail scripts to do this wouldn`t be hard 
either I imagine (disclaimer: I`m no procmail expert, and this may be 
entirely wrong).

Any form of ISP censorship, bouncing or filtering is a bad move.

        Datacomms Technologies data security
       Paul Bradley, Paul@fatmans.demon.co.uk
  Paul@crypto.uk.eu.org, Paul@cryptography.uk.eu.org    
       Http://www.cryptography.home.ml.org/
      Email for PGP public key, ID: FC76DA85
     "Don`t forget to mount a scratch monkey"

On Fri, Aug 08, 1997 at 10:45:29PM +0100, Adam Back wrote:
[...]
> I wasn't talking about remailers above, but about end users.  Hashcash
> allows the recipient to filter out email that hasn't got postage.

Ie, hashcash is a fancy techie oriented self-labelling technique.  :-)

I didn't read the code, but it seems that the double spending
protection is just local to the recipient (ie, there isn't a trusted
central clearinghouse that checks against double spending on a global
basis).  Thus, a spammer could calculate postage for a message, then
send 100000 copies.  Hashcash would guarantee that each user only got
one copy, but there are easier ways to do that.  [If the checking was
done at an ISP level, of course, only one message would get through. 
But that requires widespread deployment at the ISP level, not the
individual user level, and checking at the ISP level requires
that the ISP keep a database of users mail preferences.]

But without a central clearinghouse hashcash seems useless to me as a 
means of combating spam.  And of course, a central clearinghouse 
brings up a whole raft of other issues concerning trust and so on...

[...]

> You could auto-add anyone you ever manually replied to to the
> no-postage list even.

I would rather pursue a "tit-for-tat" strategy for email, but
unfortunately tit-for-tat requires stable identities... 

-- 
Kent Crispin				"No reason to get excited",
kent@songbird.com			the thief he kindly spoke...
PGP fingerprint:   B1 8B 72 ED 55 21 5E 44  61 F4 58 0F 72 10 65 55
http://songbird.com/kent/pgp_key.html

Kent Crispin <kent@songbird.com> writes:
> On Fri, Aug 08, 1997 at 10:45:29PM +0100, Adam Back wrote:
> [...]
> > I wasn't talking about remailers above, but about end users.  Hashcash
> > allows the recipient to filter out email that hasn't got postage.
> 
> Ie, hashcash is a fancy techie oriented self-labelling technique.  :-)

Yes, if you like.  If techie people can make themselves pretty much
immune to spam, perhaps the non-techies will get interested to use our
solution.  Make it easy enough to install at ISP level, and interim
migration paths for people without it so it still interoperates, and
you might get somewhere.

All depending on how spammers and hashcash interact when they bump
into it as a major block on their ability to spam.  They'll obviously
try their damnest to work around it.  But I think that the
inconvenience and cost to them, as hardly anyone ever replies to their
mail (costs are only for first email that isn't replied to), is a much
better spam preventer than the current status quo, which has
practically no protection other than manual blocking lists which
hardly anyone has software installed for, or for complaints to
ISPs... but then the spammers use forged email addresses, and there
are a few ISPs who apparently (from discussion here) are willing to
knowingly sell spammers bandwidth.  Someone's going to do it.

> I didn't read the code, but it seems that the double spending
> protection is just local to the recipient (ie, there isn't a trusted
> central clearinghouse that checks against double spending on a global
> basis).  

It's supposed to be 100% decentralised -- the network strain on any
kind of centralised clearling house for postage for _all_ email would
be Terrabits/second.

OK, so you might be able to split it up a bit, and have multiple
banks, and inter-bank clearing, and various trade-offs, but it's still
a major engineering effort with large bandwidth overheads.

> Thus, a spammer could calculate postage for a message, then
> send 100000 copies.  Hashcash would guarantee that each user only got
> one copy, but there are easier ways to do that.  

You missed one aspect of the design.  What the collision is calculated
on is the recipients email address.  If the collision is on someone
elses email address, you reject it out of hand.  So the hashcash
postage token is specificly minted by the sender and made out in the
email address of the individual that you are trying to send email to.
It is useless for sending email to anyone else.  You can never spend
it twice on the same person, and sending it to anyone else it will
have zero value.  

Also it includes in the hash collision an expiry date when you
generate it, but this is not significant to the email spam control
aspect, but is just there to ensure that the users double spend
database doesn't grow -- you discard expired double spend entries --
as you wouldn't accept them anyway -- because they are out of date.

> [If the checking was done at an ISP level, of course, only one
> message would get through.  But that requires widespread deployment
> at the ISP level, not the individual user level, and checking at the
> ISP level requires that the ISP keep a database of users mail
> preferences.]

ISP level checking is nice because you can get away with out changing
email clients.  The short term solution of sending nonces will help
provide a reasonable solution for those with out new clients.

> > You could auto-add anyone you ever manually replied to to the
> > no-postage list even.
> 
> I would rather pursue a "tit-for-tat" strategy for email, but
> unfortunately tit-for-tat requires stable identities... 

tit-for-tat would be reasonable also.

Stable identities already have advantages... you can block remailers
etc.

Stable identities could include signed documents.

[btw: Kent: I tried out your .midi file under win95, all I had to do
was double click on it.  Almost melodic in an weird modern sort of
way.  Most cool anyway :-]

Adam
-- 
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

On Sat, Aug 09, 1997 at 10:14:28AM +0100, Adam Back wrote:
[...]
> You missed one aspect of the design.  What the collision is calculated
> on is the recipients email address.  If the collision is on someone
> elses email address, you reject it out of hand.

Ah -- of course.  

[...]

> [btw: Kent: I tried out your .midi file under win95, all I had to do
> was double click on it.  Almost melodic in an weird modern sort of
> way.  Most cool anyway :-]

Of course, I am prejudiced, but I seriously think it qualifies as
legitimate art.  I spent a fair amount of time tweaking things so it
would sound good to my ear. 

Years ago I did a lot of experimentation with algorithmically
generated music -- it really grows on you.  In "the old days" of DOS I
had code that would drive a midi synth directly -- putting things to
midi files makes things static, and not quite as interesting -- I liked 
having things that never sounded exactly the same thing twice.  But I
haven't had time to keep up with midi drivers in the Windows world. 

But this experiment sends my mind twitching off in other aesthetic 
directions -- your code was short enough so that it isn't boring -- 
if you had 20 minutes of "music" like that it would drive you nuts, 
and I would like to try some longer things -- a couple hundred lines 
of C code, for example.  To make that work I was thinking of putting 
in a strong basic harmonic background, like a blues progression, and 
using the code text to drive a solo voice over it.  Something like 
the "Triple-DES blues"...

-- 
Kent Crispin				"No reason to get excited",
kent@songbird.com			the thief he kindly spoke...
PGP fingerprint:   B1 8B 72 ED 55 21 5E 44  61 F4 58 0F 72 10 65 55
http://songbird.com/kent/pgp_key.html

Kent Crispin <kent@songbird.com> writes:
> > [btw: Kent: I tried out your .midi file under win95, all I had to do
> > was double click on it.  Almost melodic in an weird modern sort of
> > way.  Most cool anyway :-]
> 
> [...]
> But this experiment sends my mind twitching off in other aesthetic 
> directions -- your code was short enough so that it isn't boring -- 
> if you had 20 minutes of "music" like that it would drive you nuts, 
> and I would like to try some longer things -- a couple hundred lines 
> of C code, for example.  To make that work I was thinking of putting 
> in a strong basic harmonic background, like a blues progression, and 
> using the code text to drive a solo voice over it.  Something like 
> the "Triple-DES blues"...

Well here's DES... shouldn't be hard to construct a 3DES out of it

#!/bin/perl -s-- DES in perl5
$/=" ";sub u{$_=<DATA>;s/\s//g;map{-33+ord}/./g}$"='';$[=1;@S=map{[u]}1..8;@I=
u;@F=u;@C=(split//,unpack B64,pack H16,$k.0 x16)[u];@D=splice@C,29;@p=u;$_=11 .
2222221 x2;for$l(/./g){map{push@$_,splice@$_,1,$l}\@C,\@D;$K[++$i]="@{[(@C,@D)
[@p]]}"}@E=u;@P=u;%a=map{unpack(B8,chr$_),$_}0..63;while(read STDIN,$b,8){@L=(
split//,unpack B64,$b."\0"x7)[@I];@R=splice@L,33;for$i(1..16){$i=17-$i if$d;@t
=@R[@E];$j=1;$n=0;for(($K[$i]^"@t"|0 x48)=~/.{6}/g){($n<<=4)+=${$S[$j++]}[$a{
"00$_"}+1]};@t=(split//,unpack B32,pack N,$n)[@P];@X=split//,"@L"^"@t"|0 x32;
@L=@R;@R=@X}print pack B64,join'',(@R,@L)[@F]}__END__~printunpacku,'$2F%P:```'
/!%0.("%#/0#,.)"$++''--,&**&!$()%0"-/))#.%'*#",(0&-,*$(/$++!&'!. 0$".)%/('0,#$
)%/*-(!#".+-'!*&,+&!./)(+,"+$%0.%"#&,)'-('-*!$&#/0* +.!(*!/*'$$%0'&+"#.)-&(/,-
%,#0)"."'+%.*!)'0*$)!(,%"0#/-$&,+&/#(- (..)/,$&!''0*!+$"%#()#&-,"-+%/0*+$'0*!!
'-+,"(..)0*"%$&/,&-#()#%/ #/-,%#"-(%+(,.'")&&!$00+.$!*/)*'%,#)"-,(+"./(#).0'*0
-!&*'+$%!&/$ -+"0+%0#*(#-'*)&!'."$.%//!(,&$,)*%/$0#&-#*)&-0$+(,!/%"+("'.!,)'. 
%.,!#,/(0%!*)".+$/-$*&(-&#+0')"'"'%,,..)-"$%(+/(+*0&'!)0!/&#*$#- ."#0).%)'+0$,
("%+-*&$'/,&!!/-*(#(#,"%/"(*%-+/)#.!0'-+*.!0$$&&'), [SKC;3+#]UME=5-%_WOG?7/'aY
QIA91)ZRJB:2*"\TLD<4,$^VNF>6.&`XPH@80( I)Q1Y9aAH(P0X8`@G'O/W7_?F&N.V6^>E%M-U5]
=D$L,T4\<C#K+S3[;B"J*R2Z: ZRJB:2*"[SKC;3+#\TLD<4,$]UME`XPH@80(_WOG?7/'^VNF>6.&
=5-% /2,9"&$=0'6+84-%;)1(<5.#JU@FPX?ITNBQMRHYCVOKSE>A A"#$%&%&'()*)*+,-.-./012
12345656789:9:;<=>=>?@A" 1(56>-=2"08;&3@+#)9/A<$*4.?'7,%:


How high can you crank up the bit rate?  How about pgp.exe (270k or so
from pgp263)?

Couldn't you sample voices, and use that through a vocoder?  Say one
line of the music was DES above which would come out as a real short
burst... even pgp.exe at 270k wouldn't be that long at stereo CD
quality sample, right?

Adam
-- 
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

On Mon, Aug 11, 1997 at 08:56:07AM +0100, Adam Back wrote:
> 
[...]
> 
> Well here's DES... shouldn't be hard to construct a 3DES out of it
[...]

I will try this.

> 
> How high can you crank up the bit rate?  How about pgp.exe (270k or so
> from pgp263)?

Say 300k.

I think the lower limit would be about twice the imput file size. 
Playing time: suppose each byte in the input was a single note, and,
say 30 notes/sec (damn dense music).  10k seconds.  About 3 hours
long.  Also, 30 notes/sec is too dense for any pitch-to-midi to work.

Not really very practical :-)

> Couldn't you sample voices, and use that through a vocoder?  Say one
> line of the music was DES above which would come out as a real short
> burst... even pgp.exe at 270k wouldn't be that long at stereo CD
> quality sample, right?

Totally different technology than midi, of course.  Certainly you
could treat any data as a sample.  The interesting question to me is
whether anything aesthetically meaningfull could be generated --
pgp.exe as a sound sample would just be a short white noise-ish clip,
probably -- "PGP - the noise".

Once again, there seems to be no practical value to such an encoding,
that I can think of at least, so aesthetics are the only reason to
generate something.  Midi gives you the opportunity of mirroring
textual patterns in sound, and since text is meaningful, the game I am
playing is to try to make a musical meaning out of it.  It's kind of 
fun... 

-- 
Kent Crispin				"No reason to get excited",
kent@songbird.com			the thief he kindly spoke...
PGP fingerprint:   B1 8B 72 ED 55 21 5E 44  61 F4 58 0F 72 10 65 55
http://songbird.com/kent/pgp_key.html

At 4:53 PM -0700 8/8/97, Kent Crispin wrote:>I didn't read the code, but it
seems that the double spending
>protection is just local to the recipient (ie, there isn't a trusted
>central clearinghouse that checks against double spending on a global
>basis).  Thus, a spammer could calculate postage for a message, then
>send 100000 copies.

My understanding is that value of hashcash postage is imtimately involved
with receptient email address, thus mass duplication is prohibited.

--Steve

-----BEGIN PGP SIGNED MESSAGE-----


    Kent Crispin said:

>On Sun, Aug 03, 1997 at 12:29:37PM +0100, Adam Back wrote:
>> Here's the sequence of events as I see it:
>> 
>>  1. spammer spams you with adverisement for phone sex line
>>  2. you try to sue phone sex line company
>>  3. phone sex company denies all knowledge
>>  4. government says all email must be authenticated 
>>  5. government issues internet drivers license
>>  6. anonymous remailers work around authentication requirement
>>  7. government outlaws remailers
>> 
>> See any flaws in that logical and undesirable sequence of events?
>
>The flaws become apparent if you try to attach a *realistic*
>probability to each step.

Wasn't the UPS trying to promote some system of authentication (where you 
pay just as like you purchase postage stamps now) at a trade show of some 
description in the US this year or late last year? I recall a post on 
this to this list but can't recall the detail. Anyone recall the details 
of that post?

I know last year the australian post office suggested such a role for 
themselves and they didn't see it as a voluntary proposal. I haven't 
heard anything from them lately so maybe it was all just too difficult.

- -- 
   .////.   .//    Charles Senescall             apache@bear.apana.org.au
 o:::::::::///     PGP mail preferred            apache@quux.apana.org.au
>::::::::::\\\     Finger me @bear for PGP PUBKEY      Brisbane AUSTRALIA
   '\\\\\'   \\    Apache



-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQEVAwUBM+iwwXawhvoxf0r9AQGnTwf/ZvFB+PlCUqiNvXoPmkhDSw3YlBfOjpW2
4JnOeKA3kLys23FMKvSeNd1BulrKhVwVZGpGHCsOS7/aiyxvshZb3Mjakw20mV6Z
O0gy/Si1yOLVk65e3vXWsn78xPdfXmvTEdwiFEGT3/HvICzuWzfbUIJkhdmDXK3j
D8uXE+p97NYyMscg1+qlZzD3D4uIl5jwht/giu+ztVtjJgGYqmMk4z9WZ3Vk245N
RAYhF3zgeJz/cTxNTTlT8v05kbJOcZJJlRHMLE3BlCSSY338hnXuodttc54JEoEZ
Gb04DO12bphTW2sdIqdxmQY9jjAxlO10w3CHlzuB2G05x/lyakScWg==
=lS/d
-----END PGP SIGNATURE-----

Kent Crispin <kent@songbird.com> writes:
> On Sun, Aug 03, 1997 at 12:29:37PM +0100, Adam Back wrote:
> > Here's the sequence of events as I see it:
> > 
> >  1. spammer spams you with adverisement for phone sex line
> >  2. you try to sue phone sex line company
> >  3. phone sex company denies all knowledge
> >  4. government says all email must be authenticated 
> >  5. government issues internet drivers license
> >  6. anonymous remailers work around authentication requirement
> >  7. government outlaws remailers
> > 
> > See any flaws in that logical and undesirable sequence of events?
> 
> The flaws become apparent if you try to attach a *realistic*
> probability to each step.

Difficult to do.

However, consider:

1) Government anti-spam laws won't work (too many loop holes, #1 of
   which is there are other countries in the world other than US, #2 is
   remailers will be used which will leave remailer operator rather than
   spammer to face the music).

2) When the government or whoever wants to sue someone for spam they
   will have to prove who the spammer is.  (Right?)  So now they'll
   look at the From address at it will say remailer@foo.com.  So
   they'll go have a chat to Fred Q Cypherpunk who operates foo, and he
   won't be able to cooperate because he doesn't keep logs.  They won't
   be happy with Fred, and will pass this information along to him by
   stealing his equipment, prosecuting him for assisting in a felony
   crime (they'll make it a felony right?), lock him and throw away
   the key.  But what about Freds constitutional protection of the
   speech forwarded by his remailer?  (Judge + congress-critter:
   Constitution wassat?)

3) Repeat step 2 x 100 and "something will have to be done" about the
   remailers (if there are any left!)  It really isn't that far
   fetched to have laws against remailers in the US.  Not so long ago
   the guy from the two-man band Georgia EFF were telling us about how
   they fought some law which had already tried to do this in that
   state.

4) New laws nearly always reduce your freedoms - in phrasing the law,
   and compromising their way around whatever "issues" they try to
   construct, they'll try to hide something else in there which we don't
   want.  (eg no encrypted email, or no import of crypto, or something
   stupidly unrelated -- happens all the time).

5) It's the net man, what do you want government officials crawling all
   over it, and lawyers arguing about it's content for?  It sets a bad
   precedent.

ps Kent, did you convert your rsa.midi to a .au file?  I haven't got
my /dev/midi configured properly under linux, but can play .au files,
and am dying to hear it :-)

Adam
-- 
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

>Nor are delivery services required to "know their customer" or to have
>ironclad proof of where a package originated. (Hell, even the U.S. Postal
>Service allows mail with no valid return address, and this was my
>experience in Europe as well.)

As an aside are there any anonymous postal remailers?  If not, it might be
interesting to set them up.  Maybe you could include a diskette with the
'nested' remailer information now used on Net and ecash payments at each
layer of the 'onion'.  Users would be encouraged to use uniform box
dimensions, wrapping and weight (via liquid 'filler weights) to thwart
traffic analysis.

--Steve

--Steve

On Wed, 6 Aug 1997, Adam Back wrote:

> 2) When the government or whoever wants to sue someone for spam they
>    will have to prove who the spammer is.  (Right?)  So now they'll
>    look at the From address at it will say remailer@foo.com.  So
>    they'll go have a chat to Fred Q Cypherpunk who operates foo, and he
>    won't be able to cooperate because he doesn't keep logs.  They won't
>    be happy with Fred, and will pass this information along to him by
>    stealing his equipment, prosecuting him for assisting in a felony
>    crime (they'll make it a felony right?), lock him and throw away
>    the key.  But what about Freds constitutional protection of the
>    speech forwarded by his remailer?  (Judge + congress-critter:
>    Constitution wassat?)
> 
> 3) Repeat step 2 x 100 and "something will have to be done" about the
>    remailers (if there are any left!)  It really isn't that far
>    fetched to have laws against remailers in the US.  Not so long ago
>    the guy from the two-man band Georgia EFF were telling us about how
>    they fought some law which had already tried to do this in that
>    state.

I suppose you could sue a local office or copier services place if I sent
one "unsolicited commercial fax" using their equipment, but it would be
impractical.

Most of the spam I get has thousands of other recipients, and none of it
has ever gone through a remailer, and always points to a "spam-friendly" 
ISP, or often already has their account cancelled by the time I report it. 

If we could get AGIS (the last of the large bandwidth suppliers) to pull
the plug on the IEMMC sites - I already have many spams from their members
violating their code - most spam would disappear.  It also seems that AGIS
is getting a bad reputation, but I don't know how many sites are leaving
or joining, but if they don't have interesting content, and don't pull the
plug on the IEMMC, adjustments to enough routing tables will accomplish
the same thing.

If we can stop the bulk spammers, things would quiet down.  The problem is
to stop the smokestack belching smoke without preventing me from using a
torch in my back-yard at night.

If remailers don't automatically do anonymous mailings to a 10,000 entry
Bcc: list, they would only be able to spam a few hundred people at a time
even using remailers.

Generally that isn't enough to be worth the time since only a tiny
fraction of a percentage will respond to generic requests.  If you can
only do 500, it would then pay to get a narrower list, or even personalize
things, and I might actually read something that interests me.  No one
considers announcements for cryptographic technology products on this list
as "SPAM".

--- reply to tzeruch - at - ceddec - dot - com ---