Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4036112D1BC for ; Fri, 29 Jul 2016 06:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 Rd2kc5Cfs_nf for ; Fri, 29 Jul 2016 06:42:41 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (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 4426312B00B for ; Fri, 29 Jul 2016 06:42:41 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id j185so106314855oih.0 for ; Fri, 29 Jul 2016 06:42:41 -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=Eoo1dm2RL3ByrVB3u1IyRYQynUjf99RE0L3orzShkEM=; b=Ln1BMTEbdGn9c9JALHdZHsgOhy9u0s8KPrCpzjVi2xpIwc6xRGlVnA0IMKpRIFbS0p /0glzmOmE5RtMMv03wC5boq3CMUcKWKKVR8S19ck6PY/ixTd3IzXsJn8JzLhofgn25yN YZIrjWcWwdZJAdzilkyXl9AIuBmWMSVKjif1Lp4CNN/hsjQi95WsxdG8bDuBAHI1lbzm 6+xgoKanFLbsNiA3cmvJhsJGTOypznpczimYXplo4Q3XjP9OAOGIWeLDmeqp7X4GQLNi tITsvMuJb055c61AY7bmzlGRJHVCWhx7GV3ve/EOMWaL63KetbNXQK2jZXlbPyc4Bn5r z/ag== 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=Eoo1dm2RL3ByrVB3u1IyRYQynUjf99RE0L3orzShkEM=; b=GEQBMQNQAofsYlJDrGr7AtzJLCC4L+JIXRwyS4AjM29l+CCwnYCjQW1Chsht7EYozG GXRK4YiJgj03aKj5Vw+/UNKYLnK9Z9nlg80+RrWFvkCu31vrUDNiYcvoT0NcgZUv7FSn 32PAue++fXUClvrpmBj9bzVaWZtvKx5dhaBa90TDbPIG99yPFsZ5K/GFVjRz8LmIuLsA 4AwxTUz/xy3onz4AAFUBy+2UqqkyBM0TTp9XZtLAb9NADUnp8YbrkGJmToZJVcb2Ti07 cEWBBM5tW7Xc/zntT0h2kQIUnNma3HLkvWWxpxV3P+oBaaP8MgazkGv9WN4t/42l/2fl LI1A== X-Gm-Message-State: AEkoouuFZsXRZ2+BlkMGmbTxhArJMfZuwgIdKoLasXPQb+ZD4n7mapVcO7afjtmc9QRa6oBIHK1UF4Grhkm3lA== X-Received: by 10.202.61.198 with SMTP id k189mr22701996oia.106.1469799760627; Fri, 29 Jul 2016 06:42:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.179.85 with HTTP; Fri, 29 Jul 2016 06:42:39 -0700 (PDT) In-Reply-To: References: <57964980.5000203@gmx.net> From: Pascal Urien Date: Fri, 29 Jul 2016 15:42:39 +0200 Message-ID: To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=001a113ddd829f8eb70538c66ccb Archived-At: Cc: Michael StJohns , "ace@ietf.org" , Somaraju Abhinav Subject: Re: [Ace] on signature verification times for sec192r1 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 13:42:43 -0000 --001a113ddd829f8eb70538c66ccb Content-Type: text/plain; charset=UTF-8 This data sheet from NXP gives many figures for coprocessor processing performances (including ECC 192 bits) http://www.nxp.com/documents/line_card/75016728.pdf Rgs 2016-07-25 20:45 GMT+02:00 Pascal Urien : > Hi Hannes > > > 2016-07-25 19:16 GMT+02:00 Hannes Tschofenig : > >> Hi Pascal, >> >> I guess you are saying that the performance of the verify operation is >> 60ms + the hash needed over the actual message (which is 3.5 msec for a >> 64 byte block). >> >> > That 's right. A few ms per bloc is a common figure > > >> In another paper I have seen that some hardware crypto chips have a >> fairly slow interface and that has to be taken into account as well. Is >> this an issue with this smart card? What is your experience there? >> > > I have not a lot of data for ECC processing in smartcards, because of the > difficulty in finding this type of component with ECC support. > > Neverless ECC is usually faster than RSA > > An other issue is to estimate the cost of countermeasures; computing > performance is not always the first cobjective of crypto processors > according to the EAL evaluation needed > > Let's say there is a balance between the sign/verify cost and the function > computing > > Rgs > > >> Ciao >> Hannes >> >> On 07/25/2016 12:28 PM, Pascal Urien wrote: >> > Hi Abhinav >> > >> > The extra time (2ms/bloc) comes from the hash procedure (sha1 in the >> > example) that works with 64 bytes blocs >> > >> > Rgs >> > >> > Pascal >> > >> > 2016-07-25 12:04 GMT+02:00 Somaraju Abhinav >> > >: >> > >> > Hi Pascal,____ >> > >> > __ __ >> > >> > Thanks for the information. Could you please explain what is >> > nb_bloc_512bits?____ >> > >> > __ __ >> > >> > Regards,____ >> > >> > Abhinav____ >> > >> > __ __ >> > >> > *From:*Ace [mailto:ace-bounces@ietf.org >> > ] *On Behalf Of *Pascal Urien >> > *Sent:* Sonntag, 24. Juli 2016 11:51 >> > *To:* Michael StJohns > > > >> > *Cc:* ace@ietf.org >> > *Subject:* Re: [Ace] on signature verification times for >> sec192r1____ >> > >> > __ __ >> > >> > I fully agree...____ >> > >> > __ __ >> > >> > J3A081M can be found at 10$ over the WEB____ >> > >> > __ __ >> > >> > Futhermore this class of cheap device can process TLS or DTLS as >> > illustrated in____ >> > >> > __ __ >> > >> > >> https://tools.ietf.org/html/draft-urien-uta-tls-dtls-security-module-00____ >> > >> > __ __ >> > >> > They could be used for numerous applications in the IoT____ >> > >> > __ __ >> > >> > Rgs____ >> > >> > __ __ >> > >> > Pascal____ >> > >> > __ __ >> > >> > __ __ >> > >> > 2016-07-23 23:59 GMT+02:00 Michael StJohns > > >:____ >> > >> > On 7/23/2016 11:10 AM, Pascal Urien wrote:____ >> > >> > Hi All____ >> > >> > __ __ >> > >> > J3A081M is a javacard device from NXP____ >> > >> > __ __ >> > >> > The micocontroller should be the P5CD081V1A, which comprises >> > a crypto processor____ >> > >> > >> > There's a number of these from a number of vendors. I'd >> > actually look at the A7xxx series of chips as they're designed >> > to be embeddable. I've become a big fan of javacard style >> > solutions over the years. >> > >> > In any event, the number of relatively inexpensive public key >> > crypto accelerator chips (e.g. googl for "secure authentication >> > chips") is greater than zero and continues to climb. And for >> > not a lot of money. Estimating what from prices on Digikey, I'd >> > think something less than $.50 for Quantity large as of today >> > and half that or less in 1-2 years as its gets bundled into the >> > "Swiss Army Knife" style of process (e.g. support for wireless >> > 900mhz plus ... plus ... plus ... plus security...) (google for >> > iot module secure element 900mhz for example). >> > >> > Later, Mike >> > >> > >> > >> > >> > ____ >> > >> > __ __ >> > >> > The performances with the curve secp192r1 are the following >> > (for ECDSA + SHA1)____ >> > >> > __ __ >> > >> > Sign = 40ms + nb_bloc_512bits x 3.5 ms____ >> > >> > Verify = 60ms + nb_bloc_512bits x 3,5 ms____ >> > >> > __ __ >> > >> > __ __ >> > >> > By the way this chip has enough crypto ressouces for >> > processing TLS or DTLS____ >> > >> > __ __ >> > >> > Rgs____ >> > >> > __ __ >> > >> > Pascal____ >> > >> > __ __ >> > >> > ___________________________________________________ >> > >> > Ace mailing list____ >> > >> > Ace@ietf.org ____ >> > >> > https://www.ietf.org/mailman/listinfo/ace____ >> > >> > __ __ >> > >> > >> > _______________________________________________ >> > Ace mailing list >> > Ace@ietf.org >> > https://www.ietf.org/mailman/listinfo/ace____ >> > >> > __ __ >> > >> > ________________________________________________________ The >> > contents of this e-mail and any attachments are confidential to the >> > intended recipient. They may not be disclosed to or used by or >> > copied in any way by anyone other than the intended recipient. If >> > this e-mail is received in error, please immediately notify the >> > sender and delete the e-mail and attached documents. Please note >> > that neither the sender nor the sender's company accept any >> > responsibility for viruses and it is your responsibility to scan or >> > otherwise check this e-mail and any attachments. >> > >> > >> > >> > >> > _______________________________________________ >> > Ace mailing list >> > Ace@ietf.org >> > https://www.ietf.org/mailman/listinfo/ace >> > >> >> > --001a113ddd829f8eb70538c66ccb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This data sheet from NXP gives many figures for coprocesso= r processing =C2=A0performances (including ECC 192 bits)

http://www= .nxp.com/documents/line_card/75016728.pdf

= Rgs


2016-07-25 20:45 GMT+02:00 Pascal Urien <= pascal.urien@gm= ail.com>:
= Hi Hannes


2016-07-25 19:16 GMT+02:00 Hannes Tschofenig <hannes.tschofenig@gmx.net>:
Hi Pascal= ,

I guess you are saying that the performance of the verify operation is
60ms + the hash needed over the actual message (which is 3.5 msec for a
64 byte block).


That 's right. A few ms per= bloc is a common figure
=C2=A0
In another paper I have seen that some hardware crypto chips have a
fairly slow interface and that has to be taken into account as well. Is
this an issue with this smart card? What is your experience there?

I have not a lot of data for ECC process= ing in smartcards, because of the difficulty in finding this type of compon= ent with ECC support.

Neverless ECC is usually fas= ter than RSA

An other issue is to estimate the cos= t of countermeasures; computing performance is not always the first cobject= ive of crypto processors according to the EAL evaluation needed
<= br>
Let's say there is a balance between the sign/verify cost= and the function computing

Rgs


Ciao
Hannes

On 07/25/2016 12:28 PM, Pascal Urien wrote:
> Hi Abhinav
>
> The extra time (2ms/bloc)=C2=A0 comes from the hash procedure (sha1 in= the
> example) that works with 64 bytes blocs
>
> Rgs
>
> Pascal
>
> 2016-07-25 12:04 GMT+02:00 Somaraju Abhinav
> <abhinav.somaraju@tridonic.com <mailto:abhinav.somaraju@tridonic.com<= /a>>>:
>
>=C2=A0 =C2=A0 =C2=A0Hi Pascal,____
>
>=C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0Thanks for the information. Could you please explai= n what is
>=C2=A0 =C2=A0 =C2=A0nb_bloc_512bits?____
>
>=C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0Regards,____
>
>=C2=A0 =C2=A0 =C2=A0Abhinav____
>
>=C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0*From:*Ace [mailto:ace-bounces@ietf.org
>=C2=A0 =C2=A0 =C2=A0<mailto:ace-bounces@ietf.org>] *On Behalf Of *Pascal Urien=
>=C2=A0 =C2=A0 =C2=A0*Sent:* Sonntag, 24. Juli 2016 11:51
>=C2=A0 =C2=A0 =C2=A0*To:* Michael StJohns <mstjohns@comcast.net
>=C2=A0 =C2=A0 =C2=A0<mailto:mstjohns@comcast.net>>
>=C2=A0 =C2=A0 =C2=A0*Cc:* ace@ietf.org <mailto:ace@ietf.org>
>=C2=A0 =C2=A0 =C2=A0*Subject:* Re: [Ace] on signature verification time= s for sec192r1____
>
>=C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0I fully agree...____
>
>=C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0J3A081M=C2=A0 can be found at 10$ over the WEB____<= br> >
>=C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0Futhermore this class of cheap device can process T= LS or DTLS as
>=C2=A0 =C2=A0 =C2=A0illustrated in____
>
>=C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0h= ttps://tools.ietf.org/html/draft-urien-uta-tls-dtls-security-module-00____<= /a>
>
>=C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0They could be used for numerous applications in the= IoT____
>
>=C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0Rgs____
>
>=C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0Pascal____
>
>=C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A02016-07-23 23:59 GMT+02:00 Michael StJohns <mstjohns@comcast.net<= /a>
>=C2=A0 =C2=A0 =C2=A0<mailto:mstjohns@comcast.net>>:____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On 7/23/2016 11:10 AM, Pascal Urien w= rote:____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hi All____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0J3A081M is a javacard d= evice from NXP____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The micocontroller shou= ld be the P5CD081V1A, which comprises
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a crypto process= or____
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0There's a number of these from a = number of vendors.=C2=A0 I'd
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0actually look at the A7xxx series of = chips as they're designed
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to be embeddable.=C2=A0 I've beco= me a big fan of javacard style
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0solutions over the years.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0In any event, the number of relativel= y inexpensive public key
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0crypto accelerator chips (e.g. googl = for "secure authentication
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0chips") is greater than zero and= continues to climb.=C2=A0 And for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0not a lot of money.=C2=A0 Estimating = what from prices on Digikey, I'd
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0think something less than $.50 for Qu= antity large as of today
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and half that or less in 1-2 years as= its gets bundled into the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Swiss Army Knife" style of= process (e.g. support for wireless
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0900mhz plus ... plus ... plus ... plu= s security...) (google for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0iot module secure element 900mhz for = example).
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Later, Mike
>
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The performances with t= he curve secp192r1 are the following
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(for ECDSA + SHA= 1)____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sign=C2=A0 =C2=A0 =3D 4= 0ms +=C2=A0 nb_bloc_512bits x 3.5 ms____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Verify=C2=A0 =3D 60ms= =C2=A0 + nb_bloc_512bits x 3,5 ms____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0By the way this chip ha= s enough crypto ressouces for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0processing TLS o= r DTLS____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Rgs____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pascal____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_______________________= ____________________________
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Ace mailing list____ >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Ace@ietf.org <mailto:Ace@ietf.org>____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0htt= ps://www.ietf.org/mailman/listinfo/ace____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__ __
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_____________________________________= __________
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Ace mailing list
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Ace@ietf.org <mailto:Ace@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.= org/mailman/listinfo/ace____
>
>=C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0___________________________________________________= _____ The
>=C2=A0 =C2=A0 =C2=A0contents of this e-mail and any attachments are con= fidential to the
>=C2=A0 =C2=A0 =C2=A0intended recipient. They may not be disclosed to or= used by or
>=C2=A0 =C2=A0 =C2=A0copied in any way by anyone other than the intended= recipient. If
>=C2=A0 =C2=A0 =C2=A0this e-mail is received in error, please immediatel= y notify the
>=C2=A0 =C2=A0 =C2=A0sender and delete the e-mail and attached documents= . Please note
>=C2=A0 =C2=A0 =C2=A0that neither the sender nor the sender's compan= y accept any
>=C2=A0 =C2=A0 =C2=A0responsibility for viruses and it is your responsib= ility to scan or
>=C2=A0 =C2=A0 =C2=A0otherwise check this e-mail and any attachments. >
>
>
>
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
>



--001a113ddd829f8eb70538c66ccb--