Re: Async rekey?

Peter Gutmann <[email protected]> wrote:
> This is actually a bad thing in some cases.  In a lot of SCADA use the amount
> of traffic sent over an SSH channel is tiny, so that it would take about
> 6.023e23 years before a sufficient amount of data is exchanged that rekeying
> would be justified.

Well, assuming that the only threat rekeying protects against is
compromise of the session keys due to analysing large amounts of
transmitted data.

Another risk is exposure of the session keys from the implementation's
memory, via Heartbleed-style leakage or deliberate enemy action, so
time-based rekeying has value even when not much data is being
transmitted, to limit the use of keys stolen that way. At least that was
the original rationale, as I understand it - and with Spectre having
become a thing since then, I don't really see that it's become _less_
significant as a threat.

I take your point that sometimes you'd like to dial down the enthusiasm
of the time-based rekey policy. But it's one thing to do that
consensually on purpose, and another thing to do it unilaterally by
accident, so a defence against the latter is still useful.

Cheers,
Simon

-- 
for k in [pow(x,37,0x1a1298d262b49c895d47f) for x in [0x50deb914257022de7fff,
0x213558f2215127d5a2d1, 0x90c99e86d08b91218630, 0x109f3d0cfbf640c0beee7,
0xc83e01379a5fbec5fdd1, 0x19d3d70a8d567e388600e, 0x534e2f6e8a4a33155123]]:
 print("".join([chr(32+3*((k>>x)&1))for x in range(79)])) # <[email protected]>