Re: [9front] [patch] /sys/src/cmd/ssh.c notify user of unavailable cipher

[cinap_lenrek@felloff.net]

> Yes, I'd prefer that too. I can review the RFC to see how far
> off-base the current implemenation is. Also, I am not a crypto
> expert and my beginning perusal of the 9front code didn't yield
> info for me on where to begin with adding new ciphers.

that code was never written to support multiple ciphers (all
the other ciphers are slow and insecure/broken anyway). i just
had no time for bullshit like this as i was writing this over
a weekend, fast.

the initial version didnt even bother with password and
keyboard-interactive authentication, and only supported
RSA public key auth. only what i needed (for my dayjob
as admin).

the nice thing about chacha20/poly1305 is that is is a AEAD
cipher construction. that is, it does authentication (MAC)
and encrypion as a single operation. so that cuts down
complexity and pointless-combinations down.

we later learned that github.com doesnt understand this
and insist on at least ONE mac algorithm to be listed in
the negotiation, even tho it is never used as AEAD ciphers
imply the MAC. (thanks to ori's git client work).

> So I guess this would be a good time to ask: do you (or does anyone else)
> have some pointers on where I would begin with adding other ciphers?

the question is if you want to support all combinations or not.
i'd do some research what the most common cipher+mac combination
is supported on old ssh2 versions. maybe its not possible i
dont know. just be as lazy as possible.

and maybe just implement one encryption+mac algrithm. then
the code needs less indirection and you can just have to
adapt recvpkt() and sendpkt(). they do the encryption in
place (at the beginning of recvpkt() or at the end of
sendpkt()).

if the versions you want to support dont implement curve25519
diffie-hellman, then you might also need to implement FFDH.
but its easy and libsec has you covered. all the complexity is
mostly with the negotiation. thats why i avoided this.

anyway.

try it out. you dont need to me much of a cryptographer as
the design has already been done by the ssh people. the RFC's
is really all you need.

maybe consider if it really is required for our ssh client to
support old versions of sshd with flawed algorithms. the best
way might be to just wait it out until ther servers get hacked
or they update.

--
cinap