Subject: [Ace] Asymmetric signature performance

From: Michael StJohns <[email-masked]>
Date: Tue, 7 Feb 2017 21:55:22 -0500

Hi -

This is sort of non-obvious, but one or two articles I read suggest that 
RSA 1024 performance may be better than the ECDSA equivalent.

The tradeoff here is obviously the size of the signature and the 
transmission thereof, but...

While 1024 bits isn't an ideal security strength for RSA, using any 
asymmetric key system for source authentication in group systems is 
going to be much better than trying to pretend that symmetric group key 
systems have any authentication properties at all.

I saw a PPT presentation by Hannes that  didn't include any RSA 
performance numbers for the ARM processors even though the key sizes 
were compared. My guess is that someone has numbers for 1024 RSA 
signatures on the tiny ARM processors that might be useful to throw into 
the mix.

https://www.cryptopp.com/benchmarks.html has comparison values for a 
specific library.

What I'm suggesting is that we figure out how to meet the "can't cost 
anything" requirement with weaker asymmetric keys rather than accepting 
a low end fantasy of symmetric key multicast authentication.

Mike

---

From: Somaraju Abhinav <[email-masked]>
Date: Wed, 8 Feb 2017 12:56:19 +0000

Hi Mike,

the signature size of RSA is an issue even in the 1024 bit version. The main wireless protocol, 802.15.4 has a PHY/MAC packet size of 127 bytes so we will have to fragment IP packets (Bluetooth LE is even smaller at just 27 bytes). This makes it very difficult to meet the time to light requirements. This is also a concern for the 70-80 byte overhead of ECC but we can probably just about manage.

Abhinav

________________________________
From: Ace <[email-masked]> on behalf of Michael StJohns <[email-masked]>
Sent: Wednesday, February 8, 2017 3:55:22 AM
To: [email-masked]
Subject: [Ace] Asymmetric signature performance

Hi -

Mike

_______________________________________________
Ace mailing list
[email-masked]
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.

---

From: Mohit Sethi <[email-masked]>
Date: Wed, 8 Feb 2017 15:19:28 +0200

Hi Mike

At least with our measurements on an 8-bit microprocessor platform, 
1024-bit RSA exponentiation was extremely slow. Please have a look at 
Table 1:

https://tools.ietf.org/html/draft-ietf-lwig-crypto-sensors-01

Also, a lot of research in the crypto community is now on faster and 
more efficient elliptic curves. For example, the Crypto Forum Research 
group at the IRTF is currently working on Edwards curve:
https://tools.ietf.org/html/draft-irtf-cfrg-eddsa-08

Hope this helps the discussion.

Thanks
Mohit

On 02/08/2017 04:55 AM, Michael StJohns wrote:
> Hi -
>
> This is sort of non-obvious, but one or two articles I read suggest 
> that RSA 1024 performance may be better than the ECDSA equivalent.
>
> going to be much better than trying to pretend that symmetric group 
> key systems have any authentication properties at all.
>
> signatures on the tiny ARM processors that might be useful to throw 
> into the mix.
>
> anything" requirement with weaker asymmetric keys rather than 
> accepting a low end fantasy of symmetric key multicast authentication.
>
> Mike
>
>
>
>

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Wed, 8 Feb 2017 15:56:38 +0000

One correction: 1024-bit RSA/DSA is not the same security level as 256-bit curve ECDSA or Ed25519. To compare apples to apples you would need 3072-bit RSA/DSA sigs which ends up being far worse in terms of sig size and performance.

Agreed that symmetric group key auth has plenty of limitations. 

Panos

-----Original Message-----
From: Ace [mailto:[email-masked]] On Behalf Of Michael StJohns
Sent: Tuesday, February 07, 2017 9:55 PM
To: [email-masked]
Subject: [Ace] Asymmetric signature performance

Hi -

This is sort of non-obvious, but one or two articles I read suggest that RSA 1024 performance may be better than the ECDSA equivalent.

The tradeoff here is obviously the size of the signature and the transmission thereof, but...

While 1024 bits isn't an ideal security strength for RSA, using any asymmetric key system for source authentication in group systems is going to be much better than trying to pretend that symmetric group key systems have any authentication properties at all.

I saw a PPT presentation by Hannes that  didn't include any RSA performance numbers for the ARM processors even though the key sizes were compared. My guess is that someone has numbers for 1024 RSA signatures on the tiny ARM processors that might be useful to throw into the mix.

https://www.cryptopp.com/benchmarks.html has comparison values for a specific library.

What I'm suggesting is that we figure out how to meet the "can't cost anything" requirement with weaker asymmetric keys rather than accepting a low end fantasy of symmetric key multicast authentication.

Mike

---

From: Derek Atkins <[email-masked]>
Date: Wed, 08 Feb 2017 11:18:19 -0500

Somaraju Abhinav <[email-masked]> writes:

> Hi Mike,
>
> the signature size of RSA is an issue even in the 1024 bit version. The main
> wireless protocol, 802.15.4 has a PHY/MAC packet size of 127 bytes so we will
> have to fragment IP packets (Bluetooth LE is even smaller at just 27
> bytes). This makes it very difficult to meet the time to light requirements.
> This is also a concern for the 70-80 byte overhead of ECC but we can probably
> just about manage.

Is the concern the computation or the transmission time?  Even if you
have to fragment packets I would expect transmission time to be well
fast enough that computation is the major issue?

> Abhinav

-derek
-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Michael StJohns <[email-masked]>
Date: Wed, 8 Feb 2017 11:51:12 -0500

On 2/8/2017 7:56 AM, Somaraju Abhinav wrote:
>
> Hi Mike,
>
>
> the signature size of RSA is an issue even in the 1024 bit version. 
> The main wireless protocol, 802.15.4 has a PHY/MAC packet size of 127 
> bytes so we will have to fragment IP packets (Bluetooth LE is even 
> smaller at just 27 bytes). This makes it very difficult to meet the 
> time to light requirements. This is also a concern for the 70-80 byte 
> overhead of ECC but we can probably just about manage.
>

I could have sworn this was going to be running over IPv6?   E.g. is 
this an "internet protocol" or are you just wrapping it up in IPV6 
packets for marketing?

Or is this yet another requirement - "Must not cause excessive IPv6 
fragmentation"? that needs to be stated.

You are specifying this as  group key multicast protocol on IPv6, but 
I'm finding it hard to figure out whether or not you expect this to work 
in anything except a single subnet, homogeneous transmission technology 
model.  If that's the case, why are we talking about this as an IETF task?

To put it another way - you can't have your cake and eat it too.  If 
this is an internet protocol, then it has to be able to work in the ... 
well.. internet.  If your target is closely connected nodes with 
identical transmission modes, then why not go get IEEE to standardize 
something?

Look - IP protocol is a pretty big hammer and there's this tendency to 
try and make everything look like a nail.  But some things are not nails 
and can never be made to be nails.  This lighting multicast, cheap, low 
latency, control system is really not looking like a nail.

Mike

>
> Abhinav
>
> ------------------------------------------------------------------------
> *From:* Ace <[email-masked]> on behalf of Michael StJohns 
> <[email-masked]>
> *Sent:* Wednesday, February 8, 2017 3:55:22 AM
> *To:* [email-masked]
> *Subject:* [Ace] Asymmetric signature performance
> Hi -
>
> ________________________________________________________ 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.

---

From: Michael StJohns <[email-masked]>
Date: Wed, 8 Feb 2017 12:10:03 -0500

> https://tools.ietf.org/html/draft-ietf-lwig-crypto-sensors-01

I look at Table 1 the first thing I see is that you're using the wrong 
abbreviation for time - (ms is milli second), what you want is micro 
seconds or (us).   Or are you actually trying to claim that a 1024 bit 
operation takes 199 seconds?   Or all of 3+ minutes?     Or are you 
using an abacus and a monkey to do the math?

(And by the way - using "3" as the RSA exponent is just wrong).

Table 1 doesn't actually indicate whether this is a signing operation or 
a verification operation, or whether or not the summary function (SHA1 
or SHA256) is included.

If Table 2 and table 3 have the same mistakes in time abbreviation (and 
I'm not sure why they wouldn't), you're saying that you can do an ECDSA 
function in 2-6 milliseconds.   Which more than meets the requirements.

> https://tools.ietf.org/html/draft-irtf-cfrg-eddsa-08

Aware of this along with Curve25519 and its ilk.  Most important thing 
would be to get the numbers for an ARM M0 or other tiny processor for these.

---

From: Mohit Sethi <[email-masked]>
Date: Wed, 8 Feb 2017 20:34:03 +0200

Hi Mike

Reply inline.

> using an abacus and a monkey to do the math?
It isn't the case of a wrong abbreviation. It actually took that long to 
do the exponentiation operation. We don't implement our own crypto and 
use existing libraries. In this case, we use the following library: 
http://emsign.nl/. The author of the library himself runs some initial 
measurements to find that 512-bit RSA exponentiation can take roughly 26 
seconds.
> (And by the way - using "3" as the RSA exponent is just wrong).
Agree. The point here was to see if we need to invest more time to get a 
secure and efficient RSA implementation working? What we concluded was 
that the performance of ECC is significantly better, at least for our 
platform with the libraries available.
>
> Table 1 doesn't actually indicate whether this is a signing operation 
> or a verification operation, or whether or not the summary function 
> (SHA1 or SHA256) is included.
We do write in the text that the numbers reflect the signing operation 
only. The time does not include the summary function.
>
> If Table 2 and table 3 have the same mistakes in time abbreviation 
> (and I'm not sure why they wouldn't), you're saying that you can do an 
> ECDSA function in 2-6 milliseconds.   Which more than meets the 
> requirements.
>
>
The best time with 163-bit koblitz curve was ~300 ms (for signing). I 
don't think it meets the requirements, but I definitely agree that we 
are getting quite better all the time. And bear in mind we use a 8-bit 
platform that not many deployments have. I think 32-bit is more common 
and cheaper because of economies of scale.
>> more efficient elliptic curves. For example, the Crypto Forum 
>> Research group at the IRTF is currently working on Edwards curve:
In the draft, we also cite an implementation where the authors were able 
to do Ed25519 signing on the same 8-bit platform in ~1,5 seconds.

Thanks
Mohit
>>> What I'm suggesting is that we figure out how to meet the "can't 
>>> cost anything" requirement with weaker asymmetric keys rather than

---

From: Michael StJohns <[email-masked]>
Date: Wed, 8 Feb 2017 17:48:29 -0500

On 2/8/2017 10:56 AM, Panos Kampanakis (pkampana) wrote:
> One correction: 1024-bit RSA/DSA is not the same security level as 256-bit curve ECDSA or Ed25519.

But neither is a group symmetric key of any sized used for 
authentication/authorization.

The point is that weaker but good enough security on the asymmetric side 
is going to be a better solution than ANY group symmetric key.

NIST et al have given some guidance about key strengths and their uses 
with respect to the broadest set of threats and following the guidance 
is pretty much good engineering.  But, looking at something like RSA 
1024 bit (or the ECDSA equivalent of about 166 bits - I think that's the 
right number), and looking at the threat environment for the target 
application, and noting that it's trivial (protocol wise) to change out 
the size of the key (e.g. scale it) in higher threat environments, 
1024/166 bits may not be a bad choice for minimum security for non-man 
rated IOT control things.

Mike

> To compare apples to apples you would need 3072-bit RSA/DSA sigs which ends up being far worse in terms of sig size and performance.
>

---

From: Somaraju Abhinav <[email-masked]>
Date: Thu, 9 Feb 2017 10:50:21 +0000

[AS] This is just cumulative. Adding a second multicast packet increases the transmission time by a few 10s of milliseconds depending on the number of hops. You are right that if we use asymmetric crypto then this contribution is still smaller than the crypto computation time. We will try to provide some tentative numbers in the talk today.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 9 Feb 2017 06:01:44 -0500

There is nothing in IP that makes solving this problem particularly hard, so I have no idea where this argument is coming from. Meeting your favorite security objective is hard in the systems we are talking about. Where the system does not actually have this security objective, we can go ahead with an appropriate solution. Let's stop arguing about whether everybody has to have this security objective; there cannot be any progress in that discussion. But in any case, IP is not the problem, and it is positively weird to see this argument in 2017. 

Sent from mobile

> On 8 Feb 2017, at 11:51, Michael StJohns <[email-masked]> wrote:
> 
> Look - IP protocol is a pretty big hammer and there's this tendency to try and make everything look like a nail.  But some things are not nails and can never be made to be nails.

---

From: Derek Atkins <[email-masked]>
Date: Thu, 09 Feb 2017 10:10:36 -0500

Mike,

Michael StJohns <[email-masked]> writes:

>> 1024-bit RSA exponentiation was extremely slow. Please have a look
>> at Table 1:
>>

>From my personal experience working with tiny microcontrollers I would
guess that there is NOT a typo in those numbers and it really does take
3 minutes to compute an RSA operation.  I've had similar (although
somewhat better) results with ECC on similar platforms (166-bit ECC was
taking around 30s).  Note that this is computation in software.  A
hardware implementation would certainly be faster, but then you actually
need to implement the hardware.

> (And by the way - using "3" as the RSA exponent is just wrong).

It's done frequently in "lopsided" constrained environments in order to
limit the computation required by the more-constrained device.

> ECDSA function in 2-6 milliseconds.   Which more than meets the

I don't think it's a mistake.

-derek

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Thu, 9 Feb 2017 15:32:47 +0000

I am not saying symmetric keys are better than public key auth. 
I am saying that applying an 80-bit security level (RSA/DSA1024) today offers a false sense of security. You might as well not authenticate the messages. 

-----Original Message-----
From: Ace [mailto:[email-masked]] On Behalf Of Michael StJohns
Sent: Wednesday, February 08, 2017 5:48 PM
To: [email-masked]
Subject: Re: [Ace] Asymmetric signature performance

> One correction: 1024-bit RSA/DSA is not the same security level as 256-bit curve ECDSA or Ed25519.

But neither is a group symmetric key of any sized used for authentication/authorization.

The point is that weaker but good enough security on the asymmetric side is going to be a better solution than ANY group symmetric key.

NIST et al have given some guidance about key strengths and their uses with respect to the broadest set of threats and following the guidance is pretty much good engineering.  But, looking at something like RSA
1024 bit (or the ECDSA equivalent of about 166 bits - I think that's the right number), and looking at the threat environment for the target application, and noting that it's trivial (protocol wise) to change out the size of the key (e.g. scale it) in higher threat environments,
1024/166 bits may not be a bad choice for minimum security for non-man rated IOT control things.

Mike

---

From: Derek Atkins <[email-masked]>
Date: Thu, 09 Feb 2017 10:45:00 -0500

Hi,

"Panos Kampanakis (pkampana)" <[email-masked]> writes:

> I am saying that applying an 80-bit security level (RSA/DSA1024) today
> offers a false sense of security. You might as well not authenticate
> the messages.

I disagree.  I think in many cases an 80-bit asymmetric signature is
better than a 128 (or even 256-bit) group-symmetric scheme, precisely
because with the symmetric scheme you only need to acquire the group key
from one node, which means you can attack ANY node, whereas with the
asymmetric scheme you MUST attack the signing node (which can have
better defenses).

Even today, cracking 80-bit-secure asymmetric systems are HARD.  We're
talking RSA-1024 or ECC-160.  To this day, we still have not
successfully factored an RSA-1024 key.  The largest public break is only
768-bits.  So really, unless you're worried about the NSA turning your
lights on and off, 80-bits (RSA-1024/ECC-160/WalnutDSA) is plenty
sufficient for the next several years.

-derek

---

From: Eliot Lear <[email-masked]>
Date: Thu, 9 Feb 2017 16:49:13 +0100

> asymmetric scheme you MUST attack the signing node (which can have

It can, Derek, but it might not.   Think light switch or doorbell button.

Eliot

---

From: "Derek Atkins" <[email-masked]>
Date: Thu, 9 Feb 2017 10:54:38 -0500

> It can, Derek, but it might not.   Think light switch or doorbell button.

Sure, but it's still a single point of attack versus attacking *any member
of the group*.  I.e., you have to direct the attack at the signing entity,
which, as we seem to agree, *could* have better/stronger protections than
the *weakest* member of the group.

This isn't perfect, but it's still IMHO a step in the right direction. 
"The Perfect is the enemy of the Good Enough"

-derek

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Thu, 9 Feb 2017 17:20:31 +0000

About factoring 1024-bits, https://hal.inria.fr/hal-01376934/file/paper.pdf shows that a special 1024-bit p was factored in 2 months. Also it explains that it is possible to factor some primes used on the internet today. Going to 1024 gives a false sense of security. Endorsing it in a standard to be used for some years down the road makes me uncomfortable. 256-bit ECDSA or EdDSA are more sufficient with good performance compared to RSA1024.

-----Original Message-----
From: Derek Atkins [mailto:[email-masked]] 
Sent: Thursday, February 09, 2017 10:55 AM
To: Eliot Lear <[email-masked]>
Cc: Panos Kampanakis (pkampana) <[email-masked]>; Michael StJohns <[email-masked]>; [email-masked]
Subject: Re: [Ace] Asymmetric signature performance

On Thu, February 9, 2017 10:49 am, Eliot Lear wrote:
>>> I am saying that applying an 80-bit security level (RSA/DSA1024) 
>>> today offers a false sense of security. You might as well not 
>>> authenticate the messages.
>> because with the symmetric scheme you only need to acquire the group 
>> key from one node, which means you can attack ANY node, whereas with 
>> the asymmetric scheme you MUST attack the signing node (which can 
>> have better defenses).
>

Sure, but it's still a single point of attack versus attacking *any member of the group*.  I.e., you have to direct the attack at the signing entity, which, as we seem to agree, *could* have better/stronger protections than the *weakest* member of the group.

-derek

---

From: "Derek Atkins" <[email-masked]>
Date: Thu, 9 Feb 2017 12:37:32 -0500

Hi,

On Thu, February 9, 2017 12:20 pm, Panos Kampanakis (pkampana) wrote:
>
> About factoring 1024-bits,
> https://hal.inria.fr/hal-01376934/file/paper.pdf shows that a special
> 1024-bit p was factored in 2 months. Also it explains that it is possible
> to factor some primes used on the internet today. Going to 1024 gives a
> false sense of security. Endorsing it in a standard to be used for some
> years down the road makes me uncomfortable. 256-bit ECDSA or EdDSA are
> more sufficient with good performance compared to RSA1024.

Please do not mix up 1024-bit Diffie-Hellman and 1024-bit RSA. They are
different mechanisms and depend on different underlying math.  Everything
you say above is about DH, which just does not apply when we're discussing
RSA.  You cannot "Factor a Prime"; by definition a prime's factors are 1
and itself (e.g. 11).

Yes, it is possible to create a DH-prime that allows easy solutions to the
discrete-log problem.  And yes, it's easy to create an RSA key that's
easily factored.  However, factoring a "good" 1024-bit RSA key is not "2
months" of effort.  c.f. https://en.wikipedia.org/wiki/RSA_numbers for a
list of numbers and references to their factoring efforts over the years.

Yes, 256-bit ECC is more secure than 1024-bit RSA (128-bit security vs
80-bit security).  I cannot comment on the performance difference; I've
been focusing on WalnutDSA which verifies orders of magnitude faster than
either RSA or ECDSA.

-derek

---

From: Rene Struik <[email-masked]>
Date: Thu, 9 Feb 2017 13:21:13 -0500

Hi Panos:

There seems to be some misunderstanding regarding computational 
complexities here (here: Special Number field Sieve (SNFS) vs. General 
Number Field Sieve (NFS)).

With the General Number Field Sieve, the complexity is conjectured to be 
LN[c,a], where

     a= 1/3 and c = (64/9)^{1/3}+o(1) and where

     LN[c,a]:=exp(c (log N)^a (log(log(N))^{1-a}).

With the Special Number Field Sieve, the conjectured complexity is 
LN[c,a], where

     a= 1/3 and c = (32/9)^{1/3}+o(1).

Note that if one ignores the o(1) term, then the asymptotic running time 
using the GNFS with N is about the same time required with the SNFS and 
N^2.

The paper you quoted exploits some potentially hidden structure in the 
method for producing N that results in being able to use the SNFS rather 
than the GNFS (thereby, explaining the relatively low running time). The 
paper's premises were already known in the '90s, where the only thing 
the paper added was using the best sieving methods known to the authors 
in 2016. The paper does not apply to parameters that were not concocted 
in a special way: to my knowledge, there are no results that would show 
otherwise.

(There are some other complexity results, with a=1/3 and c somewhere in 
between [(32/9)^{1/3}, (64/9)^{1/3}] as well, see, e.g., [1], which 
results in some scaling along [N,N^2] interval.)

Conclusion: your reference to the paper is misleading regarding 
state-of-the-art. {I do concur that elliptic curves outperform RSA, but 
that is another matter entirely.}

Rene

[1] DLP - the Number Field Sieve for Integers of Low Weight (Oliver 
Schirokauer, Math.Comp., 2010)

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Thu, 9 Feb 2017 21:02:38 +0000

Not sure why you mentioned that factoring only applies to DH. As you know in RSA n=p*q and pubk*prk=1 mod (totient(n))=1 mod (p-1)(q-1). Thus, if an attacker could factor n (find p and q in this case) and solve for prk. So, factoring big numbers (n in this case) equals to breaking RSA. 

It is right that the primes in the paper were special and good SFNS targets. My argument was not that all 1024-bit RSA can be broken in 2 months. What I was saying was what the paper points out which is that there are weak 1024-bit n have been deployed and still exist which makes them good SNFS targets. If someone chose to keep deploying 1024 RSA, he is opening himself up for trouble. 

I am sorry, if security is the goal here, I could never agree that weak security with 1024-bit RSA can be considered security. Instead ECDSA and EdDSA are the secure and efficient options.

+1 on WalnutDSA. Needs further analysis as it is pretty new. 

-----Original Message-----
From: Derek Atkins [mailto:[email-masked]] 
Sent: Thursday, February 09, 2017 12:38 PM
To: Panos Kampanakis (pkampana) <[email-masked]>
Cc: Derek Atkins <[email-masked]>; [email-masked]
Subject: RE: [Ace] Asymmetric signature performance

Hi,

On Thu, February 9, 2017 12:20 pm, Panos Kampanakis (pkampana) wrote:
> 1024-bit p was factored in 2 months. Also it explains that it is 
> possible to factor some primes used on the internet today. Going to 
> 1024 gives a false sense of security. Endorsing it in a standard to be 
> used for some years down the road makes me uncomfortable. 256-bit 
> ECDSA or EdDSA are more sufficient with good performance compared to RSA1024.

Please do not mix up 1024-bit Diffie-Hellman and 1024-bit RSA. They are different mechanisms and depend on different underlying math.  Everything you say above is about DH, which just does not apply when we're discussing RSA.  You cannot "Factor a Prime"; by definition a prime's factors are 1 and itself (e.g. 11).

Yes, it is possible to create a DH-prime that allows easy solutions to the discrete-log problem.  And yes, it's easy to create an RSA key that's easily factored.  However, factoring a "good" 1024-bit RSA key is not "2 months" of effort.  c.f. https://en.wikipedia.org/wiki/RSA_numbers for a list of numbers and references to their factoring efforts over the years.

Yes, 256-bit ECC is more secure than 1024-bit RSA (128-bit security vs 80-bit security).  I cannot comment on the performance difference; I've been focusing on WalnutDSA which verifies orders of magnitude faster than either RSA or ECDSA.

-derek

---

From: Mohit Sethi <[email-masked]>
Date: Fri, 10 Feb 2017 10:38:49 +0200

Hi Derek

A small comment on ECC performance inline.

> need to implement the hardware.
Regarding the performance of 160-bit ECDSA on our 8-bit platform. We 
experimented with a couple of different libraries and found that the 
signature operation took anywhere between 800 ms - 2000 ms. The exact 
numbers can be found in Tables 2,3,4,5 and 6 of the draft: 
https://tools.ietf.org/html/draft-ietf-lwig-crypto-sensors-01. Perhaps 
you could try some of those libraries on your platform and see if you 
get better performance results on your chosen platform.

Any other comments on the draft are also welcome.

Thanks
Mohit

---

From: Joona Kannisto <[email-masked]>
Date: Fri, 10 Feb 2017 09:51:30 +0000

Moi Mohit, 
One note on the timing constraints, if you use, for example, the Schnorr signature system you can precompute the group operation and do only one hash and one field operation with the fresh data. Similar optimization could be done for DSA, but it is more commonly mentioned in the Schnorr case. RSA does not allow this, as far as I know. 

So if the sleep cycle is longer than the pre-computation time the latency would not be an issue. Mostly the power budget issues remain. 

Performance figures (on x86 and P-256)  would show something in the ballpark of  35µsec for things you can precompute, and 5 µsec for things you cannot. 

This of course prevents using deterministic DSA variants (derive k like in eddsa). Also, there are more confidential bytes in memory on average. 

BR,
Joona Kannisto

> Mohit Sethi <[email-masked]> kirjoitti 10.2.2017 kello 10.38:
> 
> Hi Derek
> 
> Regarding the performance of 160-bit ECDSA on our 8-bit platform. We experimented with a couple of different libraries and found that the signature operation took anywhere between 800 ms - 2000 ms. The exact numbers can be found in Tables 2,3,4,5 and 6 of the draft: https://tools.ietf.org/html/draft-ietf-lwig-crypto-sensors-01. Perhaps you could try some of those libraries on your platform and see if you get better performance results on your chosen platform.
>

---

From: Derek Atkins <[email-masked]>
Date: Fri, 10 Feb 2017 14:48:22 -0500

Hi,

> get better performance results on your chosen platform.

We've been testing performance of signature validation, not signature
creation, since we believe that is the more common operation.

-derek