4 ms·

The Noise framework (and Wireguard) deliberately support the combination of psk and public key authentication. One clear benefit is that you get redundancy agai

The Noise framework (and Wireguard) deliberately support the combination of psk and public key authentication. One clear benefit is that you get redundancy against a failure in either mode. If your DH implemention is broken, the attacker still has to compromise your shared secret. Alternatively if the attacker compromises your shared secret, they still have to break your public key crypto. In short, its an excellent hedge against user or implementor error. Less tangibly, it can prevent an adversary from recording your traffic now, waiting until Quantum Computers are practical, breaking your public key crypto and reading your messages. Sure, you can't just slap both modes together and claim the adversary has to break both, some care is involved, but it absolutely isn't strange at all. tl;dr there are plenty of good reasons to use a combination of modes. Both Noise and Wireguard have built on support for strengthening public key crypto with psks.

lvh 8y ago
I get the general argument, but the spec doesn't really try to make that case. The default knock and PSK are (PQ) tiny: they appear to be 20 base32-encoded bytes or 96 bits of entropy. If they were being used in the same sense as Wireguard/Noise's PQ, I'd expect them to be 256 bits. EDIT: I take it back: the keys _used_ to be 96 bits (example given in the protocol description), but are now 256 judging by the keygen code. Apparently (I'm spelunking in the bug tracker) they were short once because there was an attempt to make them diceware-style verbally transmittable? Regardless: at least it looks like an effective PQ measure assuming the key derivation works. (Generally hedging against DH snafus makes a lot of sense to me, hedging against clients who can somehow manage to hold on to one kind of key material but not another is less convincing. I guess you could have P-256 on a smartcard and PSK on disk or something?)
lvh 8y ago
FWIW: I followed up on the "slapping both modes together" part: if you assume both parts work individually, PBKDF2's them together as part of the transport rekeying: https://github.com/oxy-secure/transportation/blob/9cf9356ad50a5b933529d824a480179b4ffd0460/src/encrypted_transport.rs#L63 https://github.com/oxy-secure/transportation/blob/9cf9356ad5... The code relying on that just extends the generated key with the statically found key, so it appears to be fine as long as you just chuck enough entropy in. So it appears an empty shared secret would just do what you'd expect: just the DH bit.
lvh 8y ago
Ah! I figured out the underlying reason: in the default configuration the PSK isn't per-peer-pair, it's per server. That makes a ton more sense! You get to keep the relatively simple key distribution mechanism, keep identity despite a team-shared PSK (that's what signing solves), and you get PQ resistance. (The problem this addresses is a passive observer who eventually gets a quantum computer, but can't pop any machines to just steal the PSK or whatever.)

lvh 8y ago

I get the general argument, but the spec doesn't really try to make that case. The default knock and PSK are (PQ) tiny: they appear to be 20 base32-encoded bytes or 96 bits of entropy. If they were being used in the same sense as Wireguard/Noise's PQ, I'd expect them to be 256 bits. EDIT: I take it back: the keys _used_ to be 96 bits (example given in the protocol description), but are now 256 judging by the keygen code. Apparently (I'm spelunking in the bug tracker) they were short once because there was an attempt to make them diceware-style verbally transmittable? Regardless: at least it looks like an effective PQ measure assuming the key derivation works. (Generally hedging against DH snafus makes a lot of sense to me, hedging against clients who can somehow manage to hold on to one kind of key material but not another is less convincing. I guess you could have P-256 on a smartcard and PSK on disk or something?)

lvh 8y ago

FWIW: I followed up on the "slapping both modes together" part: if you assume both parts work individually, PBKDF2's them together as part of the transport rekeying: https://github.com/oxy-secure/transportation/blob/9cf9356ad50a5b933529d824a480179b4ffd0460/src/encrypted_transport.rs#L63 https://github.com/oxy-secure/transportation/blob/9cf9356ad5... The code relying on that just extends the generated key with the statically found key, so it appears to be fine as long as you just chuck enough entropy in. So it appears an empty shared secret would just do what you'd expect: just the DH bit.

lvh 8y ago

Ah! I figured out the underlying reason: in the default configuration the PSK isn't per-peer-pair, it's per server. That makes a ton more sense! You get to keep the relatively simple key distribution mechanism, keep identity despite a team-shared PSK (that's what signing solves), and you get PQ resistance. (The problem this addresses is a passive observer who eventually gets a quantum computer, but can't pop any machines to just steal the PSK or whatever.)