spf-discuss
[Top] [All Lists]

Re: SRS timestamp

2004-02-17 08:39:15
On Tue, Feb 17, 2004 at 03:22:56PM +0000, Shevek wrote:
(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 difference is that the timestamp value does not recycle, because I'd use
the *full* timestamp in the hash calculation, derived from the current day
offset by the 4 bit value. In the copy of srs.pdf that I have, it says that
the timestamp recycles every 11 years, because it is calculated as

            (utime / 86400) mod 2^12

I am suggesting the timestamp used in the hash is (utime / 86400) without
the mod, and you use the 4-bit value to select one of the previous 16 days.

No big deal, but it saves 8 bits without opening you up to use of recycled
hashes every 16 days.

But secrets have to be replaced every few days. We can't autogenerate 
them, otherwise they're predictable

I disagree, but feel free to explain your reasoning.

If the secret is    ( realsecret + utime/86400 )

then your hash is as safe as 'realsecret'. If there are 128 bits of entropy
in realsecret, the fact that each days' hashes are related to each other
does not help an attacker.

Generating a new random realsecret every few days is paranoia. It will only
be learned if someone has broken into your machine, and if that's the case,
you have much worse problems than relaying of spam bounces.

Brian.


<Prev in Thread] Current Thread [Next in Thread>