Re: will spammers early adopt hashcash? (Re: Spam Spotlight on Reputation)

[Adam Back]

Ben and Richard CLayton's paper makes several assumptions and we'll
see how those pan out in the field as time goes on.

We don't really know what the true cost of maintaining ownership of
many machines.  No doubt much lower than it should be because of poor
security on microsoft OSes.  But even so there must be some turn over
as the user instals AV, firewalls, gets cut off by ISP, gets IP
blacklisted etc.

The general argument is in the FAQ quoted below.

Essentially whatever resources spammers do have, hashcash is going to
slow them down because the balance of CPU power vs bandwidth is such
that 20-bit hashcahs with current hardware is likely to slow down the
output of a typical consumer destkop+DSL line down by afact or 10-100x
less spam.  (Depnds on CPU power, DSL uplink, and number of Bcc
recipients per message).  Hashcash costs equal cpu per Bcc recipient.
Without hashcash Bcc recipients to the same domain or to a hub cost a
tiny bit of bandwidth -- the size of the email address (+"RCPT TO
\r\n").

Will it be enough -- we don't know yet, but if widely deployed it
would make spammers adapt.  We just don't yet know how they will
adapt.

The other question Ben & Richards paper doesn't explore is the CAMRAM
way of using hashcash.  In this model you only pay hashcash for
_introductions_.  After parties have replied to a mail, the mail is
whitelisted (short term by address only (risky no auth, joe-job
hazard) medium term with CAMRAM email header signatures).  If simple
hashcash per mail turns out not to be enough, CAMRAM can increase the
work factor, as people do not reply to spammers; and many emails are
to-and-fro vs first introduction emails.  (So the sender can afford to
pay more on average).  Eric sent a spreadsheet with some of this type
of calculation.

There may also be some mileage in Hal Finney's RPOW
http://www.rpow.net where the legitimate user can re-use stamps he
receives.  (The scaling issues of the RPOW servers would need to be
engineered carefully, there are servers, they can be per eg domain ,
but still compared to hashash this is more infrastructure as hashcash
is pure end-to-end).

Adam

http://www.hashcash.org/faq/ 2c and 2d

| 2c But won't spammers steal CPU time?
| 
| Spammers already compromise security on many users machines to make
| so-called "Zombie" armies to send spam from. However currently the
| rate at which spammers can send mail on a zombie machine is limited
| purely by the speed of those machine's internet links. A typical DSL
| user might be able to send 25 unique messages per second each of size
| 1KB (assumes 256kbit uplink). Or many more messages per second if the
| messages are delivered to multiple users at once (using multiple Cc or
| Bcc recipients). Even a 20-bit stamp takes 1/2 second per recipient on
| the highest end pc hardware at time of writing. This would slow
| spammers down by a factor of 10-100 or more per compromised machine
| (depending on whether the messages sent are sent individually or to
| many users at once).
| 
| 2d But won't spammers deliver to many recipients at once?
| 
| Spammers commonly optimize the amount of spam they can send over a
| given link speed by delivering messages to 100s or 1000s of Bcc
| recipients at once directly to an end-site, or to an ISP mail-hub. In
| this way they can consume just 3.5KB of bandwidth in sending messages
| to 100 recipients compared to the 100KB which would be used to send
| each message separately. This would allow a spammer to send 700
| messages per second (assumes DSL with 256kbit uplink).
| 
| Delivering in batches reduces the degree of customization the spammer
| can make because all of the message bodies in a batch have to be the
| same, but never-the-less is a trick spammers commonly use to increase
| the number of mails per second they can send.
| 
| However with hashcash a separate stamp is required for each individual
| recipient, which stops this spammer trick. If the spammer has to put a
| hashcash stamp for each recipient, even a 3Ghz Pentium 4 can only
| generate 2 stamps per second, compared to 700 per second with no
| hashcash, so using hashcash in this scenario slows the number of mails
| the spammer can send by 350x.

Adam

On Mon, Sep 13, 2004 at 10:37:47AM -0400, Adam Shostack wrote:
> On Mon, Sep 13, 2004 at 01:18:32PM +0100, Ben Laurie wrote:
> | Adam Shostack wrote:
> | 
> | >On Tue, Sep 07, 2004 at 04:13:13PM -0400, Adam Back wrote:
> | >
> | >| Well we'll see.  If they have lots of CPU from zombies and can get and
> | >| maintain more with limited effort maybe even they can, and CAMRAM's
> | >| higher cost stamp on introductions only will prevail as the preferred
> | >| method.
> | >
> | >Adam,
> | >
> | >   You've thought about this more than me.  What do you see as
> | >equilibrium postal rates if the spammers have 10k, 100k, or a million
> | >nodes to send?
> | >
> | >Will spammers run under nice?  Use your graphics card as a
> | >co-processor?  Is the rate of new

Re: [anonsec] Re: potential new IETF WG on anonymous IPSec (fwd from [EMAIL PROTECTED]) (fwd from [EMAIL PROTECTED])

[Anne & Lynn Wheeler]

At 11:43 AM 9/11/2004, Peter Gutmann wrote:
So in other words it's the same baby-duck security model that's been quite
successfully used by SSH for about a decade, is also used in some SSL
implementations that don't just blindly trust anything with a certificate
(particularly popular with STARTTLS-enabled MTAs/MUAs where you don't want to
bother with CA-issued certs), and is even used in various X.509 applications
(via "certificate fingerprints"), although the X.509 folks don't like to admit
that because it implies that a known-good cert fingerprint is more reliable
than a CA :-).

i've referred to it as identity agnostic ... as opposed to anonymous ... 
even with public key use. the scenario is that the original identity 
x.509  certificates created huge privacy issues.

the the current credit card scenario, it carries a name ... in theory 
so  that the merchant or point-of-sale can cross-check the name against 
additional forms of identification  as a means of authentication (where 
the merchant is sort of a stand-in agent for the consumer's financial 
institution  even tho the merchant and the consumer's financial 
institution may have significantly different and possibly opposing 
interests). in effect it is transforming something that should be purely an 
authentication operation (is the entity entitled to perform a transaction 
for the account) into a much more difficult (and privacy invasive) 
identification operation.

the x9.59 scenario  is that the transaction is simply authenticated 
with a digital signature that the merchant passes thru to the consumer's 
financial institution. the consumer financial institution verifies the 
digital signature with public key on file for that account.  the 
verification of the digital signature implies some form of "something you 
have" authentication (implies that you uniquely have the corresponding 
private key).

it becomes a straight-forward authentication operation and identity 
agnostic ... w/o the horrible identity and privacy invasive that can 
accompany a x.509 identity certificate.

while it may be possible for various agents to associated the 
authentication operation  the operations themselves, at least don't 
carry the possibly mandatory identity information & privacy invasive 
information that can be found in identity x.509 certificates.

--
Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/ 

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: potential new IETF WG on anonymous IPSec

[Bill Stewart]

At 11:45 AM 9/12/2004, Sam Hartman wrote:
No.  opportunistic encryption means I have retrieved a key or cert for
the other party, but do not know whether it is actually the right
cert.  This is slightly different although at the level of current
discussion it has the same security properties.
Actually, FreeSWAN's "Opportunistic Encryption" meant
"if you've got IP traffic for somebody,
see if they can do encryption with you and use it if you can."
Because Gilmore wanted to make sure encryption was always done securely,
their implementation used a common PKI - DNSSEC and inverse DNS -
which has the advantage that a security gateway can use it when
all it knows is the IP address of the destination (which is typically the 
case),
but the severe disadvantage that very few people have control
over that DNS space and also that an IP address may belong to more than one 
domain.

There's a significant policy question there - if you don't have
a common PKI of some sort, is it worthwhile encrypting anyway,
protecting against passive eavesdroppers but not MITM,
or is that a false sense of security because the people who
most need security are the people most likely to have a government
annoyed enough at them to do the work of running a MITM attack?
Encryption against passive eavesdroppers makes password-stealing
and traffic analysis harder, so it's probably worth the risk,
but that wasn't the choice that FreeSWAM made.

Bill Stewart  [EMAIL PROTECTED] 

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: potential new IETF WG on anonymous IPSec

[Sam Hartman]

> "Tim" == Tim Shepard <[EMAIL PROTECTED]> writes:

Tim> Sam said:

>> No.  opportunistic encryption means I have retrieved a key or
>> cert for the other party, but do not know whether it is
>> actually the right cert.

Tim> If the key is retrieved from the other end of a TCP
Tim> connection (like vanilla ssh works the first time), is that
Tim> included within the definition of "opportunistic encryption"?

Yes.


Note that for at least one of the uses of anonymous ipsec you
specifically don't want this behavior because you specifically don't
want people to cache keys in an ssh known_hosts style.  For other uses
you would want this behavior.


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: will spammers early adopt hashcash? (Re: Spam Spotlight on Reputation)

[Adam Shostack]

On Mon, Sep 13, 2004 at 01:18:32PM +0100, Ben Laurie wrote:
| Adam Shostack wrote:
| 
| >On Tue, Sep 07, 2004 at 04:13:13PM -0400, Adam Back wrote:
| >
| >| Well we'll see.  If they have lots of CPU from zombies and can get and
| >| maintain more with limited effort maybe even they can, and CAMRAM's
| >| higher cost stamp on introductions only will prevail as the preferred
| >| method.
| >
| >Adam,
| >
| > You've thought about this more than me.  What do you see as
| >equilibrium postal rates if the spammers have 10k, 100k, or a million
| >nodes to send?
| >
| >Will spammers run under nice?  Use your graphics card as a
| >co-processor?  Is the rate of new vulns high enough to keep their CPU
| >pools filled?
| 
| We have some figures for that kind of stuff in 
| http://www.apache-ssl.org/proofwork.pdf.

Thanks!  That was exactly what I was hoping wouldn't get said, because
I no longer believe that hashcash is substantially useful.

Adam S

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: [anonsec] Re: potential new IETF WG on anonymous IPSec (fwd from [EMAIL PROTECTED]) (fwd from [EMAIL PROTECTED])

[Peter Gutmann]

"Steven M. Bellovin" <[EMAIL PROTECTED]> writes:

>>Maybe it's worth doing some sort of generic RFC for this security model to
>>avoid scattering the same thing over a pile of IETF WGs, 
>
>Sounds good.  Who wants to write it...?

Since there seems to be at least some interest in this, I'll make a start on
it.  If anyone else wants to add their $0.03 to it [0], let me know.

Peter.

[0] Or $0.04 if you're paying in Euros.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: will spammers early adopt hashcash? (Re: Spam Spotlight on Reputation)

[Ben Laurie]

Adam Shostack wrote:
On Tue, Sep 07, 2004 at 04:13:13PM -0400, Adam Back wrote:
| Well we'll see.  If they have lots of CPU from zombies and can get and
| maintain more with limited effort maybe even they can, and CAMRAM's
| higher cost stamp on introductions only will prevail as the preferred
| method.
Adam,
You've thought about this more than me.  What do you see as
equilibrium postal rates if the spammers have 10k, 100k, or a million
nodes to send?
Will spammers run under nice?  Use your graphics card as a
co-processor?  Is the rate of new vulns high enough to keep their CPU
pools filled?
We have some figures for that kind of stuff in 
http://www.apache-ssl.org/proofwork.pdf.

Cheers,
Ben.
--
ApacheCon! 13-17 November! http://www.apachecon.com/
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/
"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
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Looking for Source of AES code

[Damien O'Rourke]

Hi,

I have some AES code here in C and I am trying to find it's author and
source.  I can't find
it on the Internet so I figure it was taken from a book.  Now I don't want
to send the entire
code to the list for obvious reasons however I was hoping you could help me
from the following
small snippet.  Maybe the use of " _fastcall " might jog someone's memory.
If there is
code that appears similar to this but is not exactly the same I would
appreciate the source
of that also.


void _fastcall encrypt(FILE *Encryption_File, FILE *Encrypted_File, unsigned
*expkey)
{
uchar in[16], out[16];
unsigned state[NumberOfBytes], rnd, i;

while (!feof(Encryption_File))
{
  uchar k=0;
   fread(in,sizeof(uchar),16,Encryption_File);/

   *(state+0)= *(in+0)<<24 | *(in+1)<< 16  | *(in+2)<<8  | *(in+3);
   *(state+1)= *(in+4)<<24 | *(in+5)<< 16  | *(in+6)<<8  | *(in+7)  ;
   *(state+2)= *(in+8)<<24 | *(in+9)<< 16  | *(in+10)<<8 | *(in+11)  ;
   *(state+3)= *(in+1)<<24 | *(in+3)<< 16  | *(in+14)<<8 | *(in+15)  ;

   AddRoundKey (state, expkey);

 for( rnd = 1; rnd < NumberOfRounds + 1; rnd++ )
 {
  ByteSub((uchar *)state);
  ShiftRows ((uchar *)state);
  if( rnd < NumberOfRounds )
MixColumns ((uchar *)state);
  AddRoundKey (state, expkey + rnd * NumberOfBytes);
 }


Many Thanks,
Damien.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: potential new IETF WG on anonymous IPSec

[Sam Hartman]

> "Zooko" == Zooko O'Whielcronx <[EMAIL PROTECTED]> writes:

Zooko> On 2004, Sep 09, , at 16:57, Hal Finney wrote:
>> To clarify, this is not really "anonymous" in the usual sense.
>> Rather it is a proposal to an extension to IPsec to allow for
>> unauthenticated connections.  Presently IPsec relies on either
>> pre-shared secrets or a trusted third party CA to authenticate
>> the connection.  The new proposal would let connections go
>> forward using a straight Diffie-Hellman type exchange without
>> authentication.
Zooko> ...
>> I don't think "anonymous" is the right word for this, and I
>> hope the IETF comes up with a better one as they go forward.

Zooko> I believe that in the context of e-mail [1, 2, 3, 4] and
Zooko> FreeSWAN this is called "opportunistic encryption".
No.  opportunistic encryption means I have retrieved a key or cert for
the other party, but do not know whether it is actually the right
cert.  This is slightly different although at the level of current
discussion it has the same security properties.

--Sam

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

On the Voting Machine Makers' Tab

[R. A. Hettinga]

The New York Times
September 12, 2004

On the Voting Machine Makers' Tab

As doubts have grown about the reliability of electronic voting, some of
its loudest defenders have been state and local election officials. Many of
those same officials have financial ties to voting machine companies. While
they may sincerely think that electronic voting machines are so trustworthy
that there is no need for a paper record of votes, their views have to be
regarded with suspicion until their conflicts are addressed.

Computer scientists, who understand the technology better than anyone else,
have been outspoken about the perils of electronic voting. Good government
groups, like Common Cause, are increasingly mobilizing grass-roots
opposition. And state governments in a growing number of states, including
California and Ohio, have pushed through much-needed laws that require
electronic voting machines to produce paper records.

 But these groups have faced intense opposition from election officials. At
a hearing this spring, officials from Georgia, California and Texas
dismissed concerns about electronic voting, and argued that
voter-verifiable paper trails, which voters can check to ensure their vote
was correctly recorded, are impractical. The Election Center, which does
election training and policy work, and whose board is dominated by state
and local election officials, says the real problem is people who "scare
voters and public officials with claims that the voting equipment and/or
its software can be manipulated to change the outcome of elections."

What election officials do not mention, however, are the close ties they
have to the voting machine industry. A disturbing number end up working for
voting machine companies. When Bill Jones left office as California's
secretary of state in 2003, he quickly became a consultant to Sequoia
Voting Systems. His assistant secretary of state took a full-time job
there. Former secretaries of state from Florida and Georgia have signed on
as lobbyists for Election Systems and Software and Diebold Election
Systems. The list goes on.

Even while in office, many election officials are happy to accept voting
machine companies' largess. The Election Center takes money from Diebold
and other machine companies, though it will not say how much. At the
center's national conference last month, the companies underwrote meals and
a dinner cruise.

 Forty-three percent of the budget of the National Association of
Secretaries of State comes from voting machine companies and other vendors,
and at its conference this summer in New Orleans, Accenture, which compiles
voter registration databases for states, sponsored a dinner at the Old
State Capitol in Baton Rouge.

 There are also reports of election officials being directly offered gifts.
Last year, the Columbus Dispatch reported that a voting machine company was
offering concert tickets and limousine rides while competing for a contract
worth as much as $100 million, if not more.

When electronic voting was first rolled out, election officials and voting
machine companies generally acted with little or no public participation.
But now the public is quite rightly insisting on greater transparency and
more say in the decisions. If election officials want credibility in this
national discussion, they must do more to demonstrate that their only
loyalty is to the voter.

Making Votes Count: Editorials in this series remain online at
nytimes.com/makingvotescount.


-- 
-
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'

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: [anonsec] Re: potential new IETF WG on anonymous IPSec (fwd from [EMAIL PROTECTED]) (fwd from [EMAIL PROTECTED])

[Steven M. Bellovin]

In message <[EMAIL PROTECTED]>, Peter Gutmann writes:
>Eugen Leitl <[EMAIL PROTECTED]> writes:
>

>
>Maybe it's worth doing some sort of generic RFC for this security model to
>avoid scattering the same thing over a pile of IETF WGs, things like the
>general operational principles (store a hash of the server key, compare it on
>subsequent connects), how to present the value to the user (a format that's
>consistent across protocols would be nice), maybe a simple /etc/passwd-type
>file format listing servers and their matching hashes, etc etc etc.
>

Sounds good.  Who wants to write it...?

--Steve Bellovin, http://www.research.att.com/~smb


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: potential new IETF WG on anonymous IPSec

[Zooko O'Whielacronx]

On 2004, Sep 11, , at 17:20, Sandy Harris wrote:
Zooko O'Whielcronx wrote:
I believe that in the context of e-mail [1, 2, 3, 4] and FreeSWAN  
this is called "opportunistic encryption".
That is certainly not what FreeS/WAN meant by "opportunistic  
encryption".
http://www.freeswan.org/freeswan_trees/freeswan-1.99/doc/ 
glossary.html#carpediem
That link leads to the following definition: "A situation in which any  
two IPsec-aware machines can secure their communications, without a  
pre-shared secret and without a common  PKI or previous exchange of  
public keys. This is one of the goals  of the Linux FreeS/WAN project,  
discussed in our introduction section. Setting up for opportunistic  
encryption is described in our  configuration document."

This definition is indeed consistent with the concept that we are  
discussing.

If FreeS/WAN's implementation boils down to using DNS as a common PKI  
that is too bad, but their definition (which explicitly excludes a  
common PKI) seems to be the same as mine.

This concept is too important to go without a name.  Currently the best  
way to tell your interlocutor what concept you are talking about seems  
to be "you know, the way SSH does it, with the  
first-time-unauthenticated public key exchange".  I heartily  
approve of Peter Gutmann's suggestion to write an RFC for it.

Regards,
Zooko
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]