From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from duke.felloff.net ([216.126.196.34]) by ewsd; Fri Jun 12 18:58:51 EDT 2020
Message-ID: <46EAF705F4A303B4565307D8950670A3@felloff.net>
Date: Sat, 13 Jun 2020 00:58:41 +0200
From: cinap_lenrek@felloff.net
To: 9front@9front.org
Subject: Re: [9front] [PATCH] ssh.c algorithm negotiation + ssh-dss key exchange
In-Reply-To: <8008101F-B2C7-4DB7-BFD9-5BA7E82DBC54@cpan.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: polling element realtime-java-aware control 

no. we'r not going to bring back dsa from the grave.

are you sure rsync.net does not support rsa keys?

they give an example on ther website how to generate a keypair
using 4096-bit rsa as an example:

https://rsync.net/resources/howto/ssh_keys.html

introducing edwards-curve support should go into libsec,
and we'd need to add factotum support.

this stuff is fun, but tricky to get right.

we already implemented edwards curves for dp9ik using libmp,
the reason i havnt added edwards curve support for tls is
that the intrgration is quite a bit tricky and the standard
was still in draft at the time.

on the code, it adds quite alot of lines. i hate pointer
typedefs and i dont like the introduction of global "pub"
variable. and all these if(strcmp())'s.

also there are some misleading comments:

+	/*
+	'At some future time, it is expected that another algorithm, one with better
+	strength, will become so prevalent and ubiquitous that the use of
+	"3des-cbc" will be deprecated by another STANDARDS ACTION.' - RFC4253
+	No standards action has yet deprecated it, but have not seen it supported
+	by default in any server.
+	*/
+	algsp->cipher = "chacha20-poly1305@openssh.com";

what is that supposed to mean? what has 3des todo with chacha20-poly1305?

are you trying to indicate that the IETF is going to deprecate it?

--
cinap