Linus Nordberg linus@nordberg.se writes:
nisse@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 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
nisse@lysator.liu.se (Niels Möller) wrote 29 Sep 2004 21:38:58 +0200:
| * 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.
This kind of collision?
Sender Recip Salt a@b.cd e@f.g 123 a@b.c de@f.g 123
| What does the ten-chracter format look like? 6-character dates is just | too stupid for this millennium.
Nah, it's a long time until that poses a problem. ;-)
Seems like date is YYMMDD[hhmm[ss]]. How bizarre. :-(
| > 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.
For the record, then.
BTW, have you seen http://asrg.sp.am/ or read anything on the accompanying lists?
| 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.
That's inherited from the original code. I'll change it.
I'm thinking of ditching the original code altogether and just steal the general design with subclassing of an SMTP class containing the logic of the state machine, with something that implements the actions.
Linus Nordberg linus@nordberg.se writes:
This kind of collision?
Sender Recip Salt a@b.cd e@f.g 123 a@b.c de@f.g 123
Exactly. These two inputs should result in distinct "resource" strings.
| What does the ten-chracter format look like? 6-character dates is just | too stupid for this millennium.
Nah, it's a long time until that poses a problem. ;-)
Seems like date is YYMMDD[hhmm[ss]]. How bizarre. :-(
Then I guess we can just as well go with the 6 character format. The date isn't particularly relevant in our context anyway (I think we may eventually want to define our own hashcash syntax, but I understand if you want to reuse the existing code).
BTW, have you seen http://asrg.sp.am/ or read anything on the accompanying lists?
No. Have they done any work on hashcash? I guess the chair, John R. Levine, is the same guy who is known for moderating comp.compilers and for the Linkers & Loaders book?
/Niels
nisse@lysator.liu.se (Niels Möller) wrote 29 Sep 2004 23:02:32 +0200:
| > Seems like date is YYMMDD[hhmm[ss]]. How bizarre. :-( | | Then I guess we can just as well go with the 6 character format. The | date isn't particularly relevant in our context anyway (I think we may | eventually want to define our own hashcash syntax, but I understand if | you want to reuse the existing code).
I think they use the date for stamp expiration.
Couldn't we support both, or even more? Popular formats, from widely distributed implementations, that we deem good enough could be defined as methods accepted in XHASHCASHCHALLENGE.
| > BTW, have you seen http://asrg.sp.am/ or read anything on the | > accompanying lists? | | No. Have they done any work on hashcash? I guess the chair, John R.
Don't know for sure, but it doesn't seem like it. I just spotted it.
I wonder if this
http://asrg.sp.am/wiki/ "The ASRG wiki is temporarily disabled until we set up some user authentication to keep the spammers out. Sigh."
is a sign of a problem with researching this topic.
Nice title on this one: http://www.ietf.org/rfc/rfc3098.txt :-)
| Levine, is the same guy who is known for moderating comp.compilers and | for the Linkers & Loaders book?
I wouldn't know (even if I once read that book with big eyes).
Linus Nordberg linus@nordberg.se writes:
Couldn't we support both, or even more? Popular formats, from widely distributed implementations, that we deem good enough could be defined as methods accepted in XHASHCASHCHALLENGE.
We should keep the number of required methods to a minimum. Otherwise, every implementation that wants to interoperate has to be bloated by implementing a dozen different ways of doing essentially the same thing. That's no good.
Regards, /Niels
nisse@lysator.liu.se (Niels Möller) wrote 30 Sep 2004 08:38:21 +0200:
| > Couldn't we support both, or even more? Popular formats, from widely | > distributed implementations, that we deem good enough could be defined | > as methods accepted in XHASHCASHCHALLENGE. | | We should keep the number of required methods to a minimum. | Otherwise, every implementation that wants to interoperate has to be | bloated by implementing a dozen different ways of doing essentially | the same thing. That's no good.
Right.
We could easily change the format but keep the rest of the existing implementation, I guess.
I found a Python implementation BTW. Slow of course, but nice for playing around with in our test implementation.
mta-hashcash@lists.lysator.liu.se
-
Linus Nordberg -
nisse＠lysator.liu.se