Re: Forward secrecy in spiped

[Colin Percival <cperciva@tarsnap.com>]

On 04/24/14 15:27, Frederick Akalin wrote:
>> From reading through the protocol, it seems there are two modes for 
>> forward secrecy:
> 
> A) Use forward secrecy, but allow the other side to turn it off. (default) 
> B) Turn off forward secrecy.

Correct.

> However, there could conceivably be a third mode:
> 
> C) Use forward secrecy, and terminate any connection that tries to turn it
> off.
> 
> The only problem is that if an endpoint receives 1 for the y value of the
> other side, it doesn't necessarily know that the other side has 0 for its x
> value. (I'd have to check whether it's possible, given the specific modulus
> and the possible range of x, to rule out a non-zero x for a zero y value,
> unless someone already knows the answer to this...)

If you receive y=1 from a protocol-compliant endpoint, it is running with
FPS turned off.

Protocol non-compliant endpoints could hardcode other values, e.g., y=2,
which would also have the effect of breaking FPS, but of course non-compliant
endpoints could do all sorts of things to deliberately leak keys.

> This third mode would make it possible to guard against misconfigurations,
> e.g. I might want forward secrecy to be always used, and for stuff to blow
> up / complain if that changes. Is this a valid use case?

It's certainly plausible as an anti-foot-shooting mechanism.  It doesn't gain
you any theoretical security (since it can be circumvented), but it might still
be useful in practice.

Want to send me a patch?

-- 
Colin Percival
Security Officer Emeritus, FreeBSD | The power to serve
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid