1. 15
  1.  

  2. 2

    Agree completely (thus happy to hear from someone more versed that disagree @Loup-Vaillant ?). Some added reasons:

    1. pre-authenticated part of the code base is smaller
    2. pre-authenticated round-trip used for better things, e.g. ephemeral curve-25519 keypair like in minimaLT
    3. zero- plaintext communication or identifiable pubkey used, you can key the HMAC and KDF for cipher of hello packet - with a version/suit dependent string (mixed with short-lived preshared secret for authenticating n-unknown public keys in lieu of PKI or ‘please type yes for MiM- ssh’.
    4. with (2), sneak in some CSPRNG from the other side in the encrypted hello to mix into the local pool (bootstrap in poor- rng environments without asking for mouse jiggling…)

    Incidentally, the first draft implementation of a12 (the networking protocol in Arcan used to cover/replace the uses cases of rdp/vnc/spice/ssh/… for remote interactive desktop applications) follows the scheme mentioned with some change in primitives (ChaCha8/x25519/blake3).

    1. 2

      zero- plaintext communication or identifiable pubkey used, you can key the HMAC and KDF for cipher of hello packet - with a version/suit dependent string

      hmmm. If you want zero plaintext, you need some prior/out-of-band knowledge of keys or something, right? I can’t imagine how a completely zero plaintext connection to a new server you don’t know anything about (like in TLS) would work?

      networking protocol in Arcan used to cover/replace the uses cases of rdp/vnc/spice/ssh/… for remote interactive desktop applications

      Interesting. What is the reasoning behind not using ssh? Remote applications is a hard enough problem. I think waypipe is right to focus on that and outsource networking to good old ssh.

      1. 2

        mmm. If you want zero plaintext, you need some prior/out-of-band knowledge of keys or something, right? I can’t imagine how a completely zero plaintext connection to a new server you don’t know anything about (like in TLS) would work?

        I typically don’t remote forward desktop windows, or connect to remote desktops that I don’t know in advance - (ok that’s a lie, every year I have CCC tickets, I port scan the internet for open vnc, take a screenshot and make the most depressing virtual quilt ever).

        The cases (for me) where it is more convenient with a preshared secret used for bootstrapping only authenticating n unknown public keys are:

        1. my prep:ed netboot images that have some periodically rotated default (I typically run mobile apps and browser tabs on ephemeral ‘boot-shoot-kill (but save crashes)’ devices, e.g. sopine modules on a clusterboard.

        2. when I want to give temporary access to someone I have a side channel through (voice or IM) where ‘find key, copy key, verify fingerprint…’ dance is more error prone than saying ‘the key is teledildonics’ and watching the exchange live.

        Interesting. What is the reasoning behind not using ssh? Remote applications is a hard enough problem. I think waypipe is right to focus on that and outsource networking to good old ssh.

        1. There is tons of improvements that can be made on throughput, latency and efficiency if you stop abusing ssh for things it was never designed to deal with.
        2. The feature list I am aiming for requires tight vertical integration and dealing with out of order processing while still have confidentiality/integrity and (which is a bane for remote desktop like scenarios) side channel resistance (can you match 1 packet on the wire to a keypress? game over).
        3. I can dynamically redirect single ‘windows’ (audio, video, input and meta-data) back and forth, with fallbacks should certain machines become unavailable - example, squeezing that into ssh is uncomfortable to say the least.

        Waypipe does some serious contortions to >try< and serialize wayland and pipe through ssh, and it cost him (much) more effort in both optimization and lines of code to proxy-fixup and then latency it to hell by endless copy+repackage+rebuffer than implementing / designing something for the actual use case - it was a 1 student GSoC after all…