Re: [Cfrg] Balloon-Hashing or Argon2i.

Bill Cox <waywardgeek@gmail.com> Mon, 15 August 2016 14:34 UTC

Return-Path: <waywardgeek@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 785E412D933 for <cfrg@ietfa.amsl.com>; Mon, 15 Aug 2016 07:34:59 -0700 (PDT)
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, 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 OTgaZVqKycUX for <cfrg@ietfa.amsl.com>; Mon, 15 Aug 2016 07:34:55 -0700 (PDT)
Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (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 8269812D92B for <cfrg@irtf.org>; Mon, 15 Aug 2016 07:34:54 -0700 (PDT)
Received: by mail-yw0-x229.google.com with SMTP id z8so27181543ywa.1 for <cfrg@irtf.org>; Mon, 15 Aug 2016 07:34:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OoER52BMY8iBjQ5z5i8gZeHt3ogoc/W46S6KV0vLU8g=; b=yf+fltFImfmetVxSwsXJP7YzKptPdZICT2d1TMPaA25Qh07IKNVMDxZFTKl8kHyxC8 zBH9U3Ho+BVaG1xS2BTcTyj9tROcXzzUJ3UjakfEceZWS4dWUbk+/KPWErOhBPci6AoR RrkTfqfdOIDuKBVPbmVT0c4ciL+XAXY/T0E8cj2y0+97iwy207HqX3js9QAAt8E4Hyfo r2YR9Rw8mxHmMwlfZM0EYoXupylyyCmqbgNDJcubA1bTqqbpBQEpyLtII4tAEavptBuc oxHMADR7wW8QVdy3cSsO9SWv4oNusmRdh9Kigh+sbqTpGWfPotmgEv7xopEeRxpvwouE e52g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OoER52BMY8iBjQ5z5i8gZeHt3ogoc/W46S6KV0vLU8g=; b=EKHUBbhzub93SsTvcUYU5qqFMfMMMrjNl0DuRLB3FGEbnKH7wrM1k3b8K5hNc5mTJY yTqVUt6i0NLC6E43+FbsYortX1M+HuQt/jTSe2mKGYhPJzFj36HRdHfu02elyql8XXxl PfEqiAVW7Zu9cui/fEz3vY0qc6UDIoPB8+aubzb1Ou8xEvI7Zx8rhAWgrKp4QHwfeznV U5MMqSvlAhI+yWeR3rEgvITtByMSxnVBkZLBTQfMLo/60utgG8JgIpeN2iZzc0U2YmNW 9vKjA5KaI5Yzq6YtEzn1j9g2jD/UXdPuGrnZUHgRbFKame6atefBPJtbWFwIJtBkkl6n AKLw==
X-Gm-Message-State: AEkooutEP6XfGHUfBTmYpHdIkWKNiZd6y1XAsSKHu3y8kav1P+ZjYtiTKIakyk65CKOh1XXjy03WUkXq0m9QSA==
X-Received: by 10.13.216.22 with SMTP id a22mr21376060ywe.5.1471271693829; Mon, 15 Aug 2016 07:34:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.53.17 with HTTP; Mon, 15 Aug 2016 07:34:53 -0700 (PDT)
In-Reply-To: <CAEB_pdfpOji2KhkFYrFJCpmYirspSdfXvuX2Jfy+8vRcDhDEEQ@mail.gmail.com>
References: <CAMgMiWcWts5LWsLD2bW8s1g1M0ZkRRc_PO-z2iE-iEoeTMAFRA@mail.gmail.com> <CAGiyFdf3aZ7neHfptnha47FfucKXWJrbTziTWBHAhR0o-C4Bcg@mail.gmail.com> <CAEB_pdfpOji2KhkFYrFJCpmYirspSdfXvuX2Jfy+8vRcDhDEEQ@mail.gmail.com>
From: Bill Cox <waywardgeek@gmail.com>
Date: Mon, 15 Aug 2016 07:34:53 -0700
Message-ID: <CAOLP8p7R3F2uZe+6c69O6m0CRoiU3E8KDMCZ9enNwAgcu3s_fA@mail.gmail.com>
To: Stefano Tessaro <tessaro@cs.ucsb.edu>
Content-Type: multipart/alternative; boundary="001a114e3e08add471053a1d22dd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/U4dshtFN7vVyUKVyPaELuK6_dAY>
Cc: IRTF CFRG <cfrg@irtf.org>, krzysztof pietrzak <krzpie@gmail.com>
Subject: Re: [Cfrg] Balloon-Hashing or Argon2i.
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
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: Mon, 15 Aug 2016 14:34:59 -0000

On Sun, Aug 14, 2016 at 11:17 PM, Stefano Tessaro <tessaro@cs.ucsb.edu>
wrote:

>
> Concretely, for memory hardness, I think there are two questions:
>
> = Are the metrics in the [AB16] attacks realistic or not? If not
> (which seems to be the claim), can we state precise metrics that would
> be appealing to practitioners and that theoreticians can work with?


Correct, I do claim they are unrealistic.  I like their quality measure:
total energy.  The problem is their model was simplified too much.  In
particular:

1) The energy in DRAM is dominated by the high-speed interface
<http://people.duke.edu/~bcl15/documents/malladi2012-micro.pdf>.  Adding
additional size to the DRAM increases power slightly, and not at all
proportionally.  Storing data in a tiny capacitor continues to be super
efficient in terms of power in general.

2) There was no model for the power required for parallel cores to
communicate between them, and as a die gets large (they assumed up to
500mm^2), this power will dominate in their attack.

The right approach to analyzing ASIC attacks is to iterate with the ASIC
design community.  Every new model is an advance, but to make them more
effective we need to adapt them to make them more realistic.

I strongly agree with Jean-Philippe Aumasson above.  Any theoretical notion
of security needs to be tested fleshed out and tested in more realistic
attacks.  Any realistic ASIC attack will have to specify H.  We'll hear
about how the attacker takes advantage of deep pipelining and interleaving
to do multiple attacks in parallel more efficiently.  We'll hear about
custom cache architectures.  We'll also hear about exactly how data will
get routed between cores, and all of these various components will have
size and power estimates.

I have worked with ASICs for many years, but I do not consider myself a
world-class expert in ASIC design, nor am I familiar with changes in ASIC
design in the age of fin-fets.  However, I would be happy to help flesh out
more realistic attacks for anyone who wants to see how their model might
work in a real ASIC attack.

Bill