Fearghas McKay forwarded:
--- begin forwarded text
Subject: Re: [Asrg] 6. Email Path Verification
You might want to check out the camram.org project.
http://camram.org/
(Above URL is broken, use http://www.camram.org/ instead.)
I like the idea of hashcash as an increase-spammer-costs strategy, but
there's one big fly in the ointment. The computational requirements
effectively make a hashcash-based system impractical for small,
ultra-portable or autonomous devices.
this problem has been fully acknowledged and dealt with. Ultraportable or
autonomous devices are highly unlikely to be end SMTP nodes on the net
delivering e-mail to other end nodes. This may change in the future but it's a
reality for the near term (i.e. next five years). We're choosing to deal with
the problem by deferring the stamp generation phase to the actual MTA. The load
shouldn't be too horrible because the white listing process will reduce the
number of stamps it will need to generate. keep in mind that you only generate
stamps when you are talking to a stranger. If it does become a problem, then
there should be enough money to pay for purchasing additional compute power.
After all, how many e-mails will people send using crippled keypad devices (AKA
telephones) :-)
A modern PC might only take a few seconds to generate a 20-bit hashcash, but
an ARM-based PDA or mobile phone might take a lot longer (burning battery
power all the while), and a toaster would take forever. Not to forget the
old Macs (usually 68030 based) that are commonly resurrected to help elderly,
disadvantaged or disabled people establish lines of contact. (Yes, I know
someone who actually does this. Old Macs are amazingly durable.)
there are two solutions. first: defer processing to upstream machine (back of
the envelope numbers look plausible. Need to do some empirical tests on real
mail servers). The second solution is to look at a memory based POW which
exercises the memory bus instead of just the cache and CPU which reduces the
effect of Moore's Law inflation at a potential cost of stalling the entire
machine as you flush the cache hard.
How long is it acceptable for a hashcash algorithm to take on such a low-end
box? That's the limiting factor when deciding how much each mail will
"cost".
not surprisingly, I disagree. The limiting factor is how long you are willing
to keep the machine on for. Properly done stamp generation happens in
background away from user visibility. If the system is interrupted by a
shutdown, then stamp generation restarts from its last checkpoint. Think
reliable mail delivery. also keep in mind that you only generate stamps when
talking to a stranger. It's not a continual process.
A 20-kilogate FPGA development kit costs $300, individual 20Kgate FPGAs cost
in the $tens, and a set of custom PCBs can be had for $hundreds at worst.
So, let's say the incremental cost is of the order of $25 per FPGA, giving
perhaps 25 hashcash tokens per second on average (yes, I'm being faintly
optimistic). Even allowing for one-off development and equipment-manufacture
costs, spam would appear to be worth enough to make such a system affordable.
That puts Granny and her long-suffering Mac*[1] at even more of a
disadvantage.
that's why we need to develop a repertoire of proof of work stamps, postage due
notices which handle rejection classes (insufficient postage, wrong postage,
etc.), and widespread availability of accelerators built actually into
motherboards and available at CompUSA on plug-in cards for $25. You see, if a
spammer can develop such a device, Taiwan Inc. can develop a faster device that
cost less and get it distributed further which means postage costs takes a huge
jump upward (further encouraging sales of accelerator's) and the arms race needs
to go in a different direction.
seriously, I do believe that the additional stamp definitions and proper postage
due notice system can handle most of the attacks caused by spammer specific
hardware acceleration.
being a strong advocate of recycled machines for things like firewalls (IPCop,
another one of my crimes against humanity), I have learned that sometimes
certain classes of old machines just aren't worth the effort anymore. You need
to learn when to go for higher quality junk instead of wasting your time
swearing and bleeding over a cantankerous 486.
However, a system that uses hashcash as a fallback for other authentication
methods would be an interesting concept. For example, use hashcash only to
initiate "stranger" communications, and use a strongly-authenticated
whitelist otherwise. Reading the rest of that site, I see that's in fact
what it suggests.
yes it does. I haven't had the time to rewrite and clarify because I been
working on the prototype. Apologies. Remember, strangers cost, friends fly
free.
It still doesn't help Granny if it takes her (say) 4 hours to make hashcash,
even if she only needs to do that once in a blue moon.
I think you exaggerate. A four-hour stamp is around 31 bits on a Pentium II/333
MHz and I don't think we'll need stamps that big anytime soon. when you put
stamp generation in background, you find yourself really not caring how long it
takes to make a stamp. It just gets done. I will say however that that is
spoken with the bias of someone who leaves machines on 24 by 7 by 365 modulo
power failures.
However, there's another problem with CAMRAM, though it's less obvious. Users
will build up a list of public keys over time, presumably stored on their own
machine. Their private keys will also presumably be stored locally. It's
reasonably trivial for a worm to pick up a selection of these keys as it
propagates, and deliver them to the black-hats by any of a variety of means.
problem understood and quite frankly, there is no camram specific solution to
this. Any time someone can get their code to run on your machine outside of the
sandbox, you are well and truly fucked. As we place more and more important
piece of data on known vulnerable machines, they become increasingly attractive
to attackers hoping to profit from this data or system resources.
One solution would be to use a stored value key (i.e. USB flash+) to hold
private keys and other kinds of important data. Accessing the data requires
specific acknowledgment and you take the key with you when you leave the
machine. Such a device could also hold accelerator for proof of work puzzles.
Two problem solved at once..maybe...
However, you cannot overcome laziness and any attempt to do so will be met with
resentment and firm resistance. People will demand features that will enable
them to get screwed because it is convenient to or increases the effectiveness
of how they work. Short of a major eugenics program, that part of human nature
isn't going to change.
Suddenly, they have the means to send spam to a lot of people - and even
better (in the case of a mass-mailing attachment-based worm), these are
mostly the clueless types who are most likely to respond positively to spam
and scams. Oh dear.
why work so hard to steal keys and generate correctly forged e-mail? It's far
more convenient and less traceable to generate stamps and send spam directly
from the person's PC. This is one of the failings of any distributed defense
against Spam especially with large numbers of easily compromised machines such
as the ones compromised over the past few weeks. there are no ready solutions
for this problem. In time, Linux or any other popularized OS will suffer from
similar compromises as a result of the trade-offs triggered by ease-of-use.
the only benefit of such an attack is that there'll be an even stronger
incentives to identify the compromised machines and get them off the net.
Additionally, it would be interesting to see if you could bring numerous charges
of theft of service against the advertising party. (I.e. legal muscle backing
up the technological solution)
This second problem is the main reason why any mainstream authentication
solution requires the authentication to be done via third-party,
(semi-)trusted servers. It's much harder to pick keys off a dedicated server
than some newbie's desktop, and if they are, that server can be de-listed
quite quickly until it fixes the problem.
that doesn't solve the problem either. Third party servers can be either
compromised or removed from the picture in a variety of ways which cause
different types of failures, all of which are painful.
I wish there was some way to easily protect a private key without requiring
passphrases. Passphrases are death to cryptography from a human factors
perspective. Any other identification mechanism that can be put into a USB fob
would be infinitely preferable to a pass phrase. Whatever solution we develop
must be able to deal with the fact that people will leave machines on all the
time with USB fob inserted.
to tell you the truth, the solution doesn't even need to be person specific.
The question asked is more along the lines of "is there someone there" rather
than "is the correct person there". It's just something to simply stop or
slowdown automated attacks and theft. And it has to be dirt cheap and
infinitely replaceable without losing the private key. I know, I don't want
much. :-)
disadvantaged folks in the American desert. So, if someone wants to know
exactly how long a given algorithm will take on that machine, there's at
least half a chance I'll run it and let them know.
Please run the C hashcash code found at hashcash.org. I would appreciate seeing
the performance numbers. I would also like to see them for any non Intel
machines as well like Sparc and Alpha.
---eric
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg