Re: [Cfrg] How to (pre-)compute a ladder [revised version]

Mike Hamburg <> Fri, 12 May 2017 21:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 592CC13149B for <>; Fri, 12 May 2017 14:19:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id w0Ni5y8YwjNY for <>; Fri, 12 May 2017 14:19:42 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 68E16129C01 for <>; Fri, 12 May 2017 14:15:02 -0700 (PDT)
Received: from [] (unknown []) (Authenticated sender: mike) by (Postfix) with ESMTPSA id 4161BA0061; Fri, 12 May 2017 14:15:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=sldo; t=1494623701; bh=cQmpyCZL/d8zBIuQZPEEfGDdCuNjWLmv6Y/hht9hF8A=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=Rg7/T1gXAI/YfNQldTJGllRaajY/MZ/LFc32M2IdAZ42RZZD5BC26IWkK7EmbT04e 4ptOK3VbpMzlCrpkGXxFJ9PU3w66M9jDeI5W8PaW5CIhBzpGhUwI4ZwOOUb739TlqQ vPbRx3jnxMSPa8I1liY0r1y+TtMowb9qtZ7p4MHU=
From: Mike Hamburg <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_09B506A7-1BBE-4797-A5E2-930E29C1F42E"; protocol="application/pkcs7-signature"; micalg="sha1"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Fri, 12 May 2017 14:15:00 -0700
In-Reply-To: <>
Cc: "" <>, Julio César Lopez <>, Thomaz Oliveira <>,
To: Francisco Rodriguez- Henriquez <>
References: <> <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3273)
X-Virus-Scanned: clamav-milter 0.99.2 at astral
X-Virus-Status: Clean
Archived-At: <>
Subject: Re: [Cfrg] How to (pre-)compute a ladder [revised version]
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 12 May 2017 21:19:45 -0000

Hello Francisco et al,

This is a clever and useful piece of work.  It’s a good intermediate between just using the standard Montgomery ladder for everything, and going to a full Edwards implementation with combs or something.  It especially seems useful where power analysis resistance is required, because other precomputation methods usually aren’t suitable.  The RTL Montgomery ladder (or Joye double-add ladder) is already known to be useful in this situation, at least with some modification to prevent coordinates from staying the same between iterations.  Since you’re speeding up the RTL Montgomery ladder, your optimization can slot right in to some implementations.

You should probably compare to existing Edwards precomputation methods in your paper, since they are the likely alternative to your technique.  In particular, I noticed that you compared against the EBACS version of Ed448-Goldilocks.  With a fixed base point, your method uses 41% less time for the Montgomery ladder with a 25kiB table.  However, the EBACS version of Ed448-Goldilocks doesn’t use the Montgomery ladder for fixed-base scalarmul.  Instead it uses a combs algorithm, which uses a 15kiB table and takes about 70% less time than the Montgomery ladder; see <>.  Libdecaf likewise uses precomputed combs for fixed-base scalarmul.  But your new technique is certainly simpler.

— Mike

> On May 11, 2017, at 5:14 PM, Francisco Rodriguez- Henriquez <> wrote:
> Dear CFRG community,
> We would like to draw your attention to an improved version of our IACR pre-print 2017/264 now entitled:
> 	"How to (pre-)compute a ladder"
> In this revised version, we present an improved differential addition formula that uses pre-computation to match the computational cost of the classical Montgomery differential addition.
> Accordingly, our estimates suggest that a full implementation of our pre-computable ladder proposal should outperform state-of-the-art software implementations of the X25519 and X448 functions by a 40% speedup when working in the fixed-point scenario.
> We would be delighted to receive feedback (including sightings of typos) from the CFRG community.
> With best regards,
> Thomaz Oliveira, Julio López, Hüseyin Hisil and Francisco Rodríguez-Henríquez_______________________________________________
> Cfrg mailing list