What is or is not PFS-protected?

[elimisteve]

From telehash.org/v3/spec/v3.0.0-stable.pdf --

Message packets... are used for creating ephemeral handshakes to establish synchronous channel encryption with forward secrecy guarantees.

Does this merely mean that setting up the synchronous crypto channel uses PFS, or that each message within that channel has PFS? Thanks!

[fd]

E3X Messages are not PFS. After compromising the private keys the attacker can decrypt any Message.
E3X Channel Packets on the other hand are PFS. After compromising the private keys the attacker still doesn't know the ephemeral keys to decrypt recorded channel packets.

Obviously compromised keys can still be used to pose as the original peer allowing an attacker to decrypt/encrypt new channel packets (after negotiating a new exchange).

I believe this illustrates the situation.

source

[elimisteve]

I get PFS in general, but yes you answered my question, thanks.

Relatedly, is there a really simple breakdown of the Telehash jargon
anywhere that's up do date with v3? I looked at the spec but am hoping for
something simpler so I can more easily grasp your answer/what role channels
play. Gracias.
On Dec 21, 2015 2:43 AM, "Simon Menke" notifications@github.com wrote:

E3X Messages are not PFS. After compromising the private keys the attacker
can decrypt any Message.
E3X Channel Packets on the other hand are PFS. After compromising the
private keys the attacker still doesn't know the ephemeral keys to decrypt
recorded channel packets.

Obviously compromised keys can still be used to pose as the original peer
allowing an attacker to decrypt/encrypt new channel packets (after
negotiating a new exchange).

I believe this illustrates the situation.
[image: diagram]
https://camo.githubusercontent.com/444a6736c6772358df738aec18925aebdbf85b07/687474703a2f2f7777772e77656273657175656e63656469616772616d732e636f6d2f6367692d62696e2f63647261773f6c7a3d64476c30624755675532566a4367704262476c6a5a53302d4b304a76596a6f675457567a6332466e5a517043623249745069734146675541437770756233526c49484a705a3268304947396d4941415742304a7659694268626d514143515967626d393349476868646d556759534232595778705a43426c65474e6f5957356e5a516f4b624739766343425459575a6c4948567564476c736243426a636e6c7764473867596e4a6c5957747a436941674144776a4145344e5957356b49484e685a6d566362674264434342695a574e6864584e6c4948526f5a53426c6347686c625756795957776763484a70646d46305a5342725a586c7a58473568636d5567626d393049485a7063326c69624755676447386752585a6c43694141675573474c54344167674d4651326868626d356c6243425159574e725a58514b49434141676777464149494a4277414f443256755a416f4b525859414d7768546447566862484d41614130416234454f6377434365515541675446534149524342793041684338484149514c426d64765a584d6762325a6d6%202476c75414952504279304168475146516d396949484a6c63325630637743454741734168464d4f52585a6c4f694246646d5567593246754948426c636d5a76636d30675953424e5356524e584735695a5852335a57567541495277423246755a4143464241566f5a584a6c414956444477434645675a6a6232316c6379426959574e724947397562476c7541433047633256755a4342684947304168566b6341483243506743444d41647a41494d56493178756347397a6157356e4947467a49454a765967434a44776f4168414d4641494d644b69416f52585a6c49476c75644756795932567764484d6764476870637743445877566e5a536b416879494741494e4f466b4e766258427662576c7a5a5751674b474a316441434a5651566a623356735a434275623352705932557041496761436743464667554169424d524149645f425143465a443041694545464c51434663416b416868495026733d717364

—
Reply to this email directly or view it on GitHub
#186 (comment)
.

[quartzjer]

There is the glossary but it doesn't sound like what you're asking for, there's been a couple attempts at having some visuals to help explain the roles/flows but none cleaned up enough to be helpful yet.

Channels are the primary data transport, messages are primarily used just for handshakes to help set-up channels and store-and-forward patterns where there is no reverse channel possible.

Keep asking questions and filing issues though, that'll help pull out more detail :)

[fd]

Another quick diagram