On Tue, 17 Feb 2004, Brian Candler wrote:
What doesn't seem to have been suggested so far is that it's not even
necessary to include the timestamp in the SRS address at all.
This has been proposed in various forms.
(1) In the simplest case: you rotate your signing secret every day (e.g. by
appending utime/86400 to it). Then if you want to check that a message is
valid up to 7 days old, you just check the hash against the last 7 days'
secrets.
(2) As an optimisation: you can include say the low 4 bits of the day value
in the signature. This would let you select which of the last 16 days the
message could have been sent, and perform only one hash validation. If you
want to validate messages up to 32 days old then you would perform two hash
validations, etc.
I don't understand quite what change is being proposed here. You happen to
propose 4 bits, whereas in fact we keep the low 12 bits of the day value.
The length of the timestamp is reasonably up for grabs, but 2 characters
of either base64 or base36 seems to suit the cause well without requiring
bruteforcing of the hash. Neither of these is a significant change from
the current proposal. However, it's a timestamp, and it makes sense to
keep it in a field which we call "timestamp".
This was one of the first major changes from Mail::SRS 0.10, where the
timestamp was involved in the cryptosystem as the salt.
To validate an incoming message:
rcv_daycode = (daycode & ~15) | rcv_dayselect
rcv_daycode -= 16 if rcv_daycode > daycode
Repeat until bored.
recalculate signature using rcv_daycode and compare the 21 bits
This gives a random signature a 1-in-2 million chance of being correct.
The entire signature is then 5 characters, plus separator and extra
domain(s) as per the SRS spec.
Unlike the original SRS proposal, where signatures could be reused once
every 11 years, signatures would not be recycled at all here, except for
random events once every 2^21 days (5,745 years) on average.
But secrets have to be replaced every few days. We can't autogenerate
them, otherwise they're predictable (unless we use something like an RC4
keystream, which has very complex issues of its own). And this all saves
us 2 bytes over the existing 4 byte signature and 2 byte timestamp.
I'm sorry, I don't think this has sufficient advantages to merit the
complexity and administrative overhead.
The SRS spec also omits an optimisation where the sender is signed by the
same domain, i.e. you could have
srs+a83cd+user(_at_)source(_dot_)com
(equivalent to srs0+a83cd+source(_dot_)com+user(_at_)source(_dot_)com). This
would be useful
if all outgoing mail is signed when relayed via a smarthost.
Smarthosts are already free to do this kind of transformation for their
own purposes. It isn't necessary to specify this within SRS. Were we to do
so, it would introduce a third address format. We already have two. There
are nearly a dozen possible interactions between the three addressing
formats, where currently there are only three cases.
S.
--
Shevek http://www.anarres.org/
I am the Borg. http://www.gothnicity.org/