[Cfrg] Server hardware acceleration....
Phillip Hallam-Baker <email@example.com> Fri, 01 August 2014 14:06 UTC
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84D8F1A0653 for <firstname.lastname@example.org>; Fri, 1 Aug 2014 07:06:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 ([18.104.22.168]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVjJBqMTfqyP for <email@example.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 <firstname.lastname@example.org>; Fri, 1 Aug 2014 07:06:17 -0700 (PDT)
Received: by mail-la0-f43.google.com with SMTP id hr17so3303262lab.30 for <email@example.com>; 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==
X-Received: by 10.112.139.196 with SMTP id ra4mr5801887lbb.28.1406901975562; Fri, 01 Aug 2014 07:06:15 -0700 (PDT)
Received: by 10.112.122.50 with HTTP; Fri, 1 Aug 2014 07:06:15 -0700 (PDT)
Date: Fri, 01 Aug 2014 10:06:15 -0400
From: Phillip Hallam-Baker <firstname.lastname@example.org>
To: "email@example.com" <firstname.lastname@example.org>
Content-Type: text/plain; charset="UTF-8"
Subject: [Cfrg] Server hardware acceleration....
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:email@example.com?subject=unsubscribe>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:firstname.lastname@example.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.
- [Cfrg] Server hardware acceleration.... Phillip Hallam-Baker