For convenience, I've put together an html-version of Linus' reference
list, as well as links to our files etc, at
http://www.lysator.liu.se/~nisse/misc/mta-hashcash.html
The files are also in the doc-directory in the cvs, feel free to add
more references, or comment on the scope and relevance of the
documents. Updating the files on the web requires a manual cvs update
&& make install-www WWWDIR=webdir on the right machine, so prod me
whenever the www version seem out of sync.
Regards,
/Niels
Linus Nordberg <linus(a)nordberg.se> writes:
> nisse(a)lysator.liu.se (Niels Möller) wrote
> 28 Sep 2004 09:16:35 +0200:
>
> | resource bör nog innehålla avsändare och mottagare (från
> | smtp-kuvertet) och slumpmässigt salt (som bestäms av servern).
>
> Behöver vi plocka isär resource igen, tro? I sådana fall behöver vi en
> separator mellan komponenterna. Inte ':'.
Some answers to related questions:
* The client must check that the resource string is …
[View More]constructed
according to the rules, in order to avoid interleaving attacks.
* I think the most robust way to achieve that is to let the client
construct the resource string independently. The server only sends
the salt in the challenge message.
* I think it's good cryptographic practice to have the function that
constructs the resource string from its inputs be collision free.
I.e. there should not be two sets of input that results in the same
resource string. The simplest ways to do that is to either use
unique separator (if a suitable character exists), or add explicit
length prefixes to each component.
> | Datumet tror jag inte spelar så stor roll för oss. Men ska det
> | verkligen bara vara två siffror för årtalet?
>
> Det är tydligen default. Man kan visst välja mellan 6, 10 och 12 med
> `-z'.
What does the ten-chracter format look like? 6-character dates is just
too stupid for this millennium.
> Skall epost-listan hållas på engelska tycker ni?
English makes some sense, even if at the moment you and I are the only
two subscribers.
One other comment: I noticed that you refer to RFC 821 in the comments
in your code. You should also look at the updated version, RFC 2821.
/Niels
[View Less]
Linus Nordberg <linus(a)nordberg.se> writes:
> http://www.cl.cam.ac.uk/users/rnc1/proofwork.pdf
Now I've read that article. I didn't really try follow all the
juggling and hand-waving with numbers.
As I understand the conclusions, these are the important points as
they apply to us:
1. We must be prepared to use challenges that take several minutes
to solve.
2. To make things work for legitimate email, one must use a some
"hybrid system" where hash-cash is used only …
[View More]occasionally for
legitimate email.
3. The effectiveness depends on many hard-to-estimate factors, such
as to number and cpu power of machines "0wned" by spammers.
As for 2., that's exactly what we're doing. For 1., it seems we will
make SMTP transactions take considerably longer time, and that
"smarthost" MTA:s will easily get into trouble if for some reason the
authentication mechanism doesn't work.
Regards,
/Niels
[View Less]
Earlier, when thinking about aliases, we discussed the risk of having
to come up with some mechanism for sharing key/correspondent databases
between MTA's.
There's another reason to discuss that, namely sites that use separate
MTA's for sending and receiving and/or have more than one
sending/receiving MTA. Large sites probably have lots of both.
Smaller sites might have a setup with one host in some DMZ or similar,
receiving all mail and then forwarding it to some internal host that's
not …
[View More]reachable from the Internet. Outbound mail might take another
route.
As long as all the MTA's are operated by a single administrative
entity, this might have some solution outside the scope of this work,
perhaps using a central SQL server or similar but I'm not sure. It
would of course be nice if we could present a simple and robust
mechanism for database synchronization.
[View Less]