Re: [MLS] On the Insider Security of MLS

Natanael <natanael.l@gmail.com> Thu, 29 October 2020 18:22 UTC

Return-Path: <natanael.l@gmail.com>
X-Original-To: mls@ietfa.amsl.com
Delivered-To: mls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF773A07D3 for <mls@ietfa.amsl.com>; Thu, 29 Oct 2020 11:22:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7dIFzI9X2r4 for <mls@ietfa.amsl.com>; Thu, 29 Oct 2020 11:22:12 -0700 (PDT)
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 284973A097D for <mls@ietf.org>; Thu, 29 Oct 2020 11:22:12 -0700 (PDT)
Received: by mail-ed1-x536.google.com with SMTP id v19so4015647edx.9 for <mls@ietf.org>; Thu, 29 Oct 2020 11:22:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jMApxUqcxAy7E3UBkRY1WJUh1fqcANk0uRoxQrWmY90=; b=ZmV4EmpMmZPAi9hVg8yC43VGCZZYHfGg+EV8D0ByqG3L46LOzYHeKVLoEOIIenFhib MW6du0Y1uhXcDXgrs22WWrwKntjEzeQiGgEp7qkuKSCUFbeMqIY+4Z2Q9cCjQcDbXO3e JG6k/eFDfmdGaXMe6gVstWlGNjettMRt+ZdGPVnTAokazqdmXD2dGXwEvdZMMMrHAJX4 vF0/2R/Qu/pfSgZflaSyOkzYWRHXHYeyOFZY/4mW0IjXmbdvc9Va3TNXEbUG6vObkfh0 aMC6i0AFfqY2yyom1GpQeCiGVbBpqiuKLOh66R8HnC92gTvAJKQyvHk7egorJ9KJwErP EKwQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jMApxUqcxAy7E3UBkRY1WJUh1fqcANk0uRoxQrWmY90=; b=pezyTfa6e/t3xFwRXQegQ8o+Bw508isKFXAj+rR1SVqoVXxzdycVhRYAX6VSD4SYLJ t4vEnLxNB6WIP3tBW6xv/lplL1rTNbMKxXjx1vuRvXl0QbxP9aVU0hEg3C9Oq8xedhfa 9VGktXf0BzW7XENGb/8iBI7pu2D7GNfhmBc3EybdYnJLFYjiKKyo4SrDq2ccw93gHplk R7pooP/H19RsaCiCgzwOSgbGSkM16AlVanVaYgxD+A0vzN7HY+IH0J/9e22LVCt6wmSC PGaFOtQBcNimlsFIb5kGPRZqkhR3hISkLuaTOvKnJFePMDGBdgWioKqVhaBYeiY8rPVe 4zJg==
X-Gm-Message-State: AOAM53254ONSpD1u0AJkuVABw0RGAcDJo1FdkZhIMLMjqxoH7a08LSal gz8p/carlH/kZN5O18wFOtHg8EKfsUGoixwtwWQ=
X-Google-Smtp-Source: ABdhPJxoUzxU2lLsQzj2hrnnuhwCyA1H31GP5k1WhAgQIYJboRtFHKlXEFEyTF8XEujK1RFdf4U5x6Ky/hQTYPamoJc=
X-Received: by 2002:aa7:d404:: with SMTP id z4mr5266384edq.334.1603995730562; Thu, 29 Oct 2020 11:22:10 -0700 (PDT)
MIME-Version: 1.0
References: <mailman.905.1603447209.11144.mls@ietf.org> <ea512940-15e7-75d7-917e-ca3075edfc34@rub.de> <ada77e27-beb3-b582-175a-dcf715a1a434@wickr.com>
In-Reply-To: <ada77e27-beb3-b582-175a-dcf715a1a434@wickr.com>
From: Natanael <natanael.l@gmail.com>
Date: Thu, 29 Oct 2020 19:21:59 +0100
Message-ID: <CAAt2M18AfstuHSS57g3UEjAW_1Mtv8V8ru3opfR+-sWXujXDCw@mail.gmail.com>
To: Joel Alwen <jalwen@wickr.com>
Cc: =?UTF-8?B?UGF1bCBSw7ZzbGVy?= <paul.roesler@rub.de>, mls@ietf.org, Jost Daniel <dajost@inf.ethz.ch>, Marta Mularczyk <mumarta@ethz.ch>
Content-Type: multipart/alternative; boundary="000000000000bdd7e505b2d35b85"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/o7JISR0KWa_drH_UO9ZRLfxkLIA>
Subject: Re: [MLS] On the Insider Security of MLS
X-BeenThere: mls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Messaging Layer Security <mls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mls>, <mailto:mls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mls/>
List-Post: <mailto:mls@ietf.org>
List-Help: <mailto:mls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mls>, <mailto:mls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Oct 2020 18:22:14 -0000

Randomness Improvements for Security Protocols - randomness wrapper, for
use with deterministic signatures

https://tools.ietf.org/html/rfc8937

Does this have the properties you need?

Den mån 26 okt. 2020 13:57Joel Alwen <jalwen@wickr.com> skrev:

> Yeah, EdDSA, and especially (randomized) ECDSA, really aren't ideal
> choices from
> a security perspective. But I think their main advantage over other schemes
> (like XEdDSA) is that they are widely implemented (at production quality)
> and
> even part of various standards (e.g. FIPS) which people have to adhere to.
> For
> MLS that's available implementations are a must. (Thats why MLS doesn't
> use UPKE
> like in rTreeKEM though the security benefits are clear.)
>
> Do you happen to know if there are any alternative schemes with better
> properties (like XEdDSA) that have at least some amount of production
> quality
> implementations?
>
> - Joël
>
> On 23/10/2020 12:36, Paul Rösler wrote:
> > Hi Joël,
> >
> > this sounds indeed promising and interesting! One point on the security
> > of EdDSA:
> >
> > On 23.10.20 12:00, Joel Alwen <jalwen@wickr.com> wrote:
> >>  2) ECDSA vs. EdDSA : We found that we could have proven stronger
> security if
> >> only EdDSA were used vs. if ECDSA is permitted. ECDSA sigs produced
> with a bad
> >> PRNG (i.e. not enough entropy) can result in sigs that reveal the
> signing keys.
> >> EdDSA signatures are deterministic and so aren't susceptible to this.
> ECDSA can
> >> also be de-randomized (RFC 6979) to avoid the problem.
> >
> > While EdDSA (and deterministic ECDSA) is not vulnerable to weak
> > randomness, it can be attacked equally devastatingly via fault attacks
> > (e.g., bit flips), which we demonstrate in [2]. Since attacks against
> > randomness and bit flips during signing can both be practical, a
> > compromise between the benefits of both signing variants, like XEdDSA,
> > could probably fit better.
> >
> > Cheers,
> > Paul
> >
> > [2] Attacking Deterministic Signature Schemes using Fault Attacks.
> > Poddebniak, Somorovsky, Schinzel, Lochter, Rösler.
> > https://eprint.iacr.org/2017/1014.pdf
> >
>
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls
>