Re: [Cfrg] 8032(PureEdDSA) question

Tony Arcieri <bascule@gmail.com> Fri, 21 December 2018 16:38 UTC

Return-Path: <bascule@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD046130E8A for <cfrg@ietfa.amsl.com>; Fri, 21 Dec 2018 08:38:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 VnttTXo96N3v for <cfrg@ietfa.amsl.com>; Fri, 21 Dec 2018 08:38:21 -0800 (PST)
Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) (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 B2327130E9C for <cfrg@irtf.org>; Fri, 21 Dec 2018 08:38:21 -0800 (PST)
Received: by mail-oi1-x236.google.com with SMTP id t204so5246055oie.7 for <cfrg@irtf.org>; Fri, 21 Dec 2018 08:38:21 -0800 (PST)
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=IEkdvNCM5TZRFx4CO5/M5DXpFnIDsXeQrQGW3OjqjKI=; b=eJ+dHKUgVRJvU2x9IBqAAK/7x8s166/W6XlRrQb+lk5CDVCWuZ5a4HI5TkBaauXySU siYKrKCyC/rYJiA90W3LNf0ga2zyt5Xukl3U0LWtbF26DP3Y9x/1vXBnnbIKbi5gZ4wZ VH0s3E++s0s9a/zZqw6QX2aIXJh0VT40r/IvBeQuVmdY/f6TmWAERf1OuGNIiFwDeg7b U0W2ERT+dTIcFY+/yLAG06S7H/glf183QEbGjJqRbyqj3219c/7UOFzBgfk0Zz8HVEhM /IRhzV1lDxZtQ5bxrMJtZ6lZ8wG1Eq2UYQUM6f+/XBKCk6MTpOJPdD3rmqzhISIvV0rD 57AA==
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=IEkdvNCM5TZRFx4CO5/M5DXpFnIDsXeQrQGW3OjqjKI=; b=fZnjEUAptSVtdgyRyVWlBzqrjHt/e+wZitFZhDaEUHig0LlntHwK0HoxDcvP0rb/Xc dJ4Q3K+1BjhgRvUaIv8wECiLLgQfAdo96+1pNG8ydOhPPjXY0XAeeFlCujUS8zRbJG0q jN/nDrJMnXW+F3mljYW8orfDKAnrDkrnc0hiVYfF8yfdhhkcS+BwQS8S6kFt82o+p9TC 8iC/vHKH90DC0rotbj9FzNp1aZNx7kVjJIZ+WF6M7f9SzWy4eJ4zBxb0ahB8SV+G+fSp 8nJdEoy/Re4eyIq4axElJeVTQRPanKbgwt8Mn2ochWkJkGzaQS1qyrEldMVY7ZwQn90e 5LGg==
X-Gm-Message-State: AA+aEWbvSUtmNrNBzSQvKcX1YW9d5HXDjUA/wypRTlYmLhzwuA3TFc7S lNZGPk93BFCjWArNgiExtL94BTtb4XqaYwFY7MI=
X-Google-Smtp-Source: AFSGD/V9K4NL6wxBen5lZwqHFwi6QVf1Ow2sRDppEdvWUh83O0TzLVSrjfEKraL1DdHGUQJMnAkRgJ1+5bpX1bNY4PA=
X-Received: by 2002:aca:5c87:: with SMTP id q129mr1936259oib.189.1545410300806; Fri, 21 Dec 2018 08:38:20 -0800 (PST)
MIME-Version: 1.0
References: <810C31990B57ED40B2062BA10D43FBF501D57D41@XMB116CNC.rim.net>
In-Reply-To: <810C31990B57ED40B2062BA10D43FBF501D57D41@XMB116CNC.rim.net>
From: Tony Arcieri <bascule@gmail.com>
Date: Fri, 21 Dec 2018 08:38:09 -0800
Message-ID: <CAHOTMVLJ49iAMeZzd7mtFdju4TF9mw1MLB-Q5uT4Qc6wwR6+sw@mail.gmail.com>
To: Dan Brown <danibrown@blackberry.com>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Content-Type: multipart/alternative; boundary="000000000000030ce3057d8ae064"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/Lal7nBHBUDqR7ixh4-0lbPqwdes>
Subject: Re: [Cfrg] 8032(PureEdDSA) question
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Dec 2018 16:38:31 -0000

On Fri, Dec 21, 2018 at 8:16 AM Dan Brown <danibrown@blackberry.com> wrote:

> My suggestion would be *either* to amend the main claims as
>
> "The collision resilience property means EdDSA is secure even if it is
> feasible to compute collisions for the hash function, provided the hash
> remains at least  <XYZ-secure> ",
>
> for some value of <XYZ-secure>.
>
> As I recall, <XYZ-secure> should include things like prefix 2nd preimage
> resistance (to prevent some forgeries, and maybe to make security proofs
> work
> ....) and pseudorandom (to protect r generation).


It's true if a second preimage attack were found that collision resistance
would be violated, but that's like saying remote code execution attacks
also make you vulnerable to local file disclosure attack. But RCE is a
distinct and much more severe attack, and if someone said they offered a
"local file disclosure" defense, personally I would not expect that
guarantee to hold in the event of RCE.

By analogy, that's how I feel about the text regarding collisions here:
you're saying the text is untrue in the presence of an adversary who has
capabilities beyond what it sates, because the attacker could de-escalate
to the less powerful attack if they so desired. That seems to be colluding
the less powerful attack with the more powerful one, which I find confusing.

The text makes sense to me as-is.

-- 
Tony Arcieri