Re: [Cfrg] When TLS is an overkill... Tue, 26 February 2019 09:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 130DD130E9F for <>; Tue, 26 Feb 2019 01:06:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Sf8KpzxzDGBr for <>; Tue, 26 Feb 2019 01:06:43 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AF9CE130E9E for <>; Tue, 26 Feb 2019 01:06:43 -0800 (PST)
Received: from (unknown []) by (Postfix) with ESMTP id 0195E102E56 for <>; Tue, 26 Feb 2019 10:06:40 +0100 (CET)
Received: from ( []) (Authenticated sender: by (Postfix) with ESMTPSA id 0B9462F8DD6C; Tue, 26 Feb 2019 09:06:37 +0000 (UTC)
Date: Tue, 26 Feb 2019 09:06:35 +0000
User-Agent: K-9 Mail for Android
In-Reply-To: <>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----Z7O8YDE9VULFQ2CPIHI840O51IWACO"
Content-Transfer-Encoding: 7bit
To:, Ruslan Kiyanchuk <>, "Dr. Pala" <>
Message-ID: <>
X-Ovh-Tracer-Id: 117093593486638925
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedutddrudelgddtudcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd
Archived-At: <>
Subject: Re: [Cfrg] When TLS is an overkill...
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 26 Feb 2019 09:06:46 -0000

Sounds like goal is quite similar to what noise protocol framework tries to achieve. 

On 26 February 2019 08:45:45 GMT, Ruslan Kiyanchuk <> wrote:
>> What I am trying to do is quite simple: /provide a building block
>> developers and engineers can use to secure the communication between
>> two peers by using a low number of messages/.
>> In particular, I think that this building block could help many
>> developers to do the right thing when not using TLS. Do not get me
>> wrong, TLS is great.. however, it might be useful to have an
>> alternative. My particular use case (but this is just one, there
>> be many others) is specifically EAP. In EAP, it seems, people always
>> try to re-use
>I think you might be trying to reinvent Noise protocol framework
><> :)
>It's a framework designed to be simple and straightforward for for
>securing 2-party communication. By combining different elements of the
>protocol you achieve various security properties. There is also a third
>party website Noise Explorer <> where you can
>explore various settings of the framework and corresponding security
>By your description so far it sounded like a good fit.
>Another mention that may be relevant is Google's ATLS
>(it's their home-grown TLS alternative, I'm not aware how much scrutiny
>and analysis it underwent).
>Good luck!