From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pb-smtp2.pobox.com ([64.147.108.71]) by ewsd; Wed Apr 22 01:40:45 EDT 2020 Received: from pb-smtp2.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 52AC957354 for <9front@9front.org>; Wed, 22 Apr 2020 01:40:33 -0400 (EDT) (envelope-from unobe@cpan.org) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=date :in-reply-to:references:mime-version:content-type :content-transfer-encoding:subject:to:from:message-id; s=sasl; bh=AO5Zn3Nt+NaaVE4+zEywmriAYGA=; b=v/4tRMW0NIYVh9C8YM9kc5utkr0R eZI9YUVDTD1GeBQHjQb/W3AL2Whucz2TmcTte4caQPvVruWrereUL2g2gGgV1VOZ FFpUM5lDA0iJnsvzk/bXqBNRsoZG1VK2n8GanEoRmIWGtlc3sbSNCEe/Sr1kncBn 6+AQIFJbw96E+Zo= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 4B6EE57353 for <9front@9front.org>; Wed, 22 Apr 2020 01:40:33 -0400 (EDT) (envelope-from unobe@cpan.org) Received: from [10.0.1.31] (unknown [137.25.138.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 27B6C57351 for <9front@9front.org>; Wed, 22 Apr 2020 01:40:32 -0400 (EDT) (envelope-from unobe@cpan.org) Date: Wed, 22 Apr 2020 05:40:29 +0000 In-Reply-To: <40289B1E19DD4906838B30C398B0A16D@felloff.net> References: <40289B1E19DD4906838B30C398B0A16D@felloff.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [9front] [patch] /sys/src/cmd/ssh.c notify user of unavailable cipher To: 9front@9front.org From: Romano Message-ID: <4513BA4E-8C84-4D96-BD99-F7648754A61B@cpan.org> X-Pobox-Relay-ID: C8125F4A-845B-11EA-BB78-D1361DBA3BAF-09620299!pb-smtp2.pobox.com List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: content-addressed extensible STM JSON map/reduce-based hosting-oriented frontend On Tue, Apr 21, 2020, at 4:25 PM, cinap_lenrek@felloff=2Enet wrote: > maybe consider if it really is required for our ssh client to > support old versions of sshd with flawed algorithms=2E the best > way might be to just wait it out until ther servers get hacked > or they update=2E I agree that it would be better to not have servers hacked, and be up-to-d= ate=2E I hope the sysadmin for the (work) server I need access to will be o= pen to including the chacha20/poly1305 cipher=2E I'll let the list know, h= opefully sometime next week, what I hear=2E > that code was never written to support multiple ciphers (all > the other ciphers are slow and insecure/broken anyway)=2E i just > had no time for bullshit like this as i was writing this over > a weekend, fast=2E I've looked a bit online for more information about all the other ciphers = being insecure/broken=2E I didn't see anything about AES256-CTR being insec= ure or broken, but I probably missed something=2E I read that one has to b= e careful with the key used, and that AES-256 is the "gold standard" presum= ably because the U=2ES=2E government uses it (argument from authority--yay!= )=2E The server I was trying to connect to does support AES256-CTR, and I p= lan to follow-up next week w/the sysadmin of that server to understand why = that's supported, but not chacha20/poly1305=2E Would you (or someone else r= eading this on the list) have a paper or something handy that I can read re= : the insecurity and brokenness of that cipher specifically? That would hel= p in my conversation with the sysadmin=2E > the initial version didnt even bother with password and > keyboard-interactive authentication, and only supported > RSA public key auth=2E only what i needed (for my dayjob > as admin)=2E Since I am now using this software, I really appreciate the time you took = to update it to accept a password=2E For one-off testing, that was helpful= =2E And I am grateful that you're taking the time to reply to me on this l= ist=2E > the nice thing about chacha20/poly1305 is that is is a AEAD > cipher construction=2E that is, it does authentication (MAC) > and encrypion as a single operation=2E so that cuts down > complexity and pointless-combinations down=2E Very cool! I did not know any of this=2E > the question is if you want to support all combinations or not=2E > i'd do some research what the most common cipher+mac combination > is supported on old ssh2 versions=2E maybe its not possible i > dont know=2E just be as lazy as possible=2E >=20 > and maybe just implement one encryption+mac algrithm=2E then > the code needs less indirection and you can just have to > adapt recvpkt() and sendpkt()=2E they do the encryption in > place (at the beginning of recvpkt() or at the end of > sendpkt())=2E >=20 >=20 > if the versions you want to support dont implement curve25519 > diffie-hellman, then you might also need to implement FFDH=2E > but its easy and libsec has you covered=2E all the complexity is > mostly with the negotiation=2E thats why i avoided this=2E Fortunately, the server in question does support curve25519 for key exchan= ge=2E > try it out=2E you dont need to me much of a cryptographer as > the design has already been done by the ssh people=2E the RFC's > is really all you need=2E Hopefully this won't be needed, but I did look into what might be needed i= f I had to do it=2E I'd focus on AES-256-CTR=2E From what I see in 9front, = there's aes(2) which provides OFB and is similar to CTR[1], but is not CTR= =2E So that implementation would have to be added to aes(2), no? In terms= of steps I'd take, I'd dig into how the OFB implementation works on 9front= , then determine how to adjust in order to implement CTR=2E For authentication, I'd focus on hmac-sha2-512, which is available from se= chash(2) on 9front=2E Thanks again for taking the time to respond=2E [1] https://en=2Ewikipedia=2Eorg/wiki/Block_cipher_mode_of_operation#Count= er_(CTR)