From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: **
X-Spam-Status: No, score=2.4 required=5.0 tests=DATE_IN_PAST_06_12,RDNS_NONE
	autolearn=no autolearn_force=no version=3.4.4
Received: (qmail 20396 invoked from network); 20 Jun 2021 22:48:05 -0000
Received: from unknown (HELO 1ess.inri.net) (216.126.196.35)
  by inbox.vuxu.org with ESMTPUTF8; 20 Jun 2021 22:48:05 -0000
Received: from duke.felloff.net ([216.126.196.34]) by 1ess; Sun Jun 20 10:56:36 -0400 2021
Message-ID: <7E7CCAAABA337DF1906098CC2567EA47@felloff.net>
Date: Sun, 20 Jun 2021 16:56:24 +0200
From: cinap_lenrek@felloff.net
To: 9front@9front.org
In-Reply-To: <CABO6shfTEKNjFdx4O1e_tU-XPn+bu7J=tE6GZF_7xXPDthRyZA@mail.gmail.com>
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: element deep-learning-aware factory-scale generator 
Subject: Re: [9front] libsec: various tls changes
Reply-To: 9front@9front.org
Precedence: bulk

> also, after a bit of diving in the rfcs i found out that
> the x25519 rfc specifies an optional step that if the
> shared secret turned out to be all zeroes, abort.
> rfc 8422 (tls ecc rfc) says that this MUST be done.

yeah, good catch. this is also what boringssl does.

> i was unsure if i should have added that check to
> curve25519_finish, as it would break source compatibility,
> so i added it to tlsSecECDHE*.

yeah, but this function is used rarely (only ssh and tlshand
right now) so it is not a big deal to change the return value
from void to int and fix the callers.

i think it is better todo it internally, especially as the caller
might forget todo the cehck in a timing-safe way.

pushed a fix for both plan9front and drawterm.

--
cinap