From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from duke.felloff.net ([216.126.196.34]) by ewsd; Tue Apr 21 19:25:58 EDT 2020 Message-ID: <40289B1E19DD4906838B30C398B0A16D@felloff.net> Date: Wed, 22 Apr 2020 01:25:48 +0200 From: cinap_lenrek@felloff.net To: 9front@9front.org Subject: Re: [9front] [patch] /sys/src/cmd/ssh.c notify user of unavailable cipher In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: proven package XML over YAML singleton metadata-scale configuration-scale full-stack framework > 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