[Cfrg] Server hardware acceleration....

Phillip Hallam-Baker <phill@hallambaker.com> Fri, 01 August 2014 14:06 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84D8F1A0653 for <cfrg@ietfa.amsl.com>; Fri, 1 Aug 2014 07:06:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.122
X-Spam-Level:
X-Spam-Status: No, score=0.122 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
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 hVjJBqMTfqyP for <cfrg@ietfa.amsl.com>; Fri, 1 Aug 2014 07:06:18 -0700 (PDT)
Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B754C1A004A for <cfrg@irtf.org>; Fri, 1 Aug 2014 07:06:17 -0700 (PDT)
Received: by mail-la0-f43.google.com with SMTP id hr17so3303262lab.30 for <cfrg@irtf.org>; Fri, 01 Aug 2014 07:06:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=Znes3QlBzMTmZU67tHGRHkosU8R7LYP+PghJC0w7SRI=; b=hY0XER+Ev2PbJ3EI0I0g6qzu6U/Un3WQ4eafz7eM/hrCrMtD4UwRtlJrPeEgOT1a2n IGTBjeHaVW14kUcrsf8nPdJqUkDxstpk2ZwgbvdeOrMIWFDK1F3eVddoERLBVCHi/Kmc 04uANb9iIiAhlCP8Ce23IioKiUVj/3akOfArMlG6wEhiPHdIQvcclyH+1dncN6w9tv7p kZOKZyC/RT2LOkKNDDHrO1pOupSNHpT0X69o/lxDyeX+GJFOay8MI8iD/BHTy5hdxofc McW/jCvWxE/bLVgoTL1VbF7eVmqIYtc0F8T/FqIhf6qnW/r8X/LtKK+QEieB4krUTD0Z mQVQ==
MIME-Version: 1.0
X-Received: by 10.112.139.196 with SMTP id ra4mr5801887lbb.28.1406901975562; Fri, 01 Aug 2014 07:06:15 -0700 (PDT)
Sender: hallam@gmail.com
Received: by 10.112.122.50 with HTTP; Fri, 1 Aug 2014 07:06:15 -0700 (PDT)
Date: Fri, 1 Aug 2014 10:06:15 -0400
X-Google-Sender-Auth: zmi6NNLqpqPe7x69us7X8zTn-fE
Message-ID: <CAMm+LwjJ+f7VgugkhD1psYMiofBpNMHThWj7CVOHjFRgA2etgA@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: "cfrg@irtf.org" <cfrg@irtf.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/G29bF-4dEMPE7xn651U66mVPY70
Subject: [Cfrg] Server hardware acceleration....
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Aug 2014 14:06:20 -0000

One issue that I had overlooked in earlier messages is that while ECC
is generally faster than RSA this is only true if we are comparing
like with like, i.e. ECDH with DH, ECDSA with DSA.

The rub here is that while RSA is fast for public values and slow for
private, DSA is the other way around.  RSA2048 signature verification
is actually faster than DSA with the 512 bit NIST curves by a factor
of 8 roughly. Key agreement is a lot faster though.

Another difference that is likely to have a large impact on the APIs
is that we are not talking about doing ECC encryption, nor do we need
it. We are actually talking about ECC key agreement. So unlike in the
RSA case, the encryption and decryption routines are not direct
inverses. We don't 'encrypt with the private key' to sign as some
people describe it.


Now the performance difference might actually be better. The decision
to deploy TLS is taken by the server, not the client. And since we can
do 600 signature verifications/sec on a middling box on the slow NIST
curves, the disadvantage to the client is not a major concern.

I don't have figures for how much faster the server operations get but
it looks like its at least 20 times faster on the NIST curves and
thats before we start choosing the curves cleverly or doing
precalculations on the static keys.

So the need for hardware acceleration is arguably open.


But if we do want hardware acceleration:
https://www.pgroup.com/lit/articles/insider/v2n1a5.htm

Most machines sold today already have a co-processor with a 512 bit
data bus on them. Going above 512 is going to be really hard for a
long time and if you miss and have to do two fetches you take twice as
long.

I think that is a convincing argument against E521 if we accept the
need for hardware acceleration. But as I point out, that might not be
a major concern.

Those processors could be a good way to provide side channel
resistance though. If you have 1024 cores at 32 bits each and you gang
16 of them together to do one 512 bit ECC calculation, you can do 64
operations in parallel. That could be 64 operations with the same key
or 64 operations with 63 dummy keys.