Showing results for

- Intel Community
- Software Development SDKs and Libraries
- Intel® Integrated Performance Primitives
- Cryptography: Signature generation with ECCP

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page

Highlighted
##

*msg *pointed
*pMsgDigest *falls outside the range of [1, 1-*n*]
*n *is the order of the elliptic curve base point *G*.

kdiamond

Beginner

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

05-22-2008
06:43 AM

12 Views

Cryptography: Signature generation with ECCP

Sorry for asking, but I need some clarification on IPP behavior during digital signature(DS) generation with ippsECCPSignDSA(). I'd greately appreciate any response on that matter 'coz it's really important to me.

The situation is following.

I'm using IPP to sign some data using ECDSA with SHA224. So, actual DS is being calculated over SHA224 hash of variable input data (that is a message digest).

1) ippsSHA224MessageDigest() is used to calculate hash value and that is Ok. No issues here.

2) Private key comes from PKCS#8 formatted file with the contents (Data Tag #n -data dump thatfollowed by parsed individual data fileds):

Data Tag #0 (version)

00

Data Tag #1 (privateKeyAlgorithm)

06 07 2A 86 48 CE 3D 02 01 30 81 C5 02 01 01 30

28 06 07 2A 86 48 CE 3D 01 01 02 1D 00 D7 C1 34

AA 26 43 66 86 2A 18 30 25 75 D1 D7 87 B0 9F 07

57 97 DA 89 F5 7E C8 C0 FF 30 3C 04 1C 68 A5 E6

2C A9 CE 6C 1C 29 98 03 A6 C1 53 0B 51 4E 18 2A

D8 B0 04 2A 59 CA D2 9F 43 04 1C 25 80 F6 3C CF

E4 41 38 87 07 13 B1 A9 23 69 E3 3E 21 35 D2 66

DB B3 72 38 6C 40 0B 04 39 04 0D 90 29 AD 2C 7E

5C F4 34 08 23 B2 A8 7D C6 8C 9E 4C E3 17 4C 1E

6E FD EE 12 C0 7D 58 AA 56 F7 72 C0 72 6F 24 C6

B8 9E 4E CD AC 24 35 4B 9E 99 CA A3 F6 D3 76 14

02 CD 02 1D 00 D7 C1 34 AA 26 43 66 86 2A 18 30

25 75 D0 FB 98 D1 16 BC 4B 6D DE BC A3 A5 A7 93

9F

Private Key Algorithm : ECDH-ECDSA Public/Private Key (1.2.840.10045.2.1)

Version : 1

Field ID : 1.2.840.10045.1.1

Prime-P :

00 D7 C1 34 AA 26 43 66 86 2A 18 30 25 75 D1 D7

87 B0 9F 07 57 97 DA 89 F5 7E C8 C0 FF

curve A :

68 A5 E6 2C A9 CE 6C 1C 29 98 03 A6 C1 53 0B 51

4E 18 2A D8 B0 04 2A 59 CA D2 9F 43

curve B :

25 80 F6 3C CF E4 41 38 87 07 13 B1 A9 23 69 E3

3E 21 35 D2 66 DB B3 72 38 6C 40 0B

Base :

04 0D 90 29 AD 2C 7E 5C F4 34 08 23 B2 A8 7D C6

8C 9E 4C E3 17 4C 1E 6E FD EE 12 C0 7D 58 AA 56

&n
bsp; F7 72 C0 72 6F 24 C6 B8 9E 4E CD AC 24 35 4B 9E

99 CA A3 F6 D3 76 14 02 CD

Order :

00 D7 C1 34 AA 26 43 66 86 2A 18 30 25 75 D0 FB

98 D1 16 BC 4B 6D DE BC A3 A5 A7 93 9F

Cofactor : 00000001

Data Tag #2 (privateKey)

30 21 02 01 01 04 1C 20 38 D9 30 37 2E 80 25 7E

B7 A3 89 F2 12 EB 74 4F C2 13 CB 04 E5 F2 CE 74

37 34 BE

Version : 1

Key :

20 38 D9 30 37 2E 80 25 7E B7 A3 89 F2 12 EB 74

4F C2 13 CB 04 E5 F2 CE 74 37 34 BE

Public key comes from the corresponding certificate and has a value (dump with leading OCTET STRING tag):

Public point Y

04 37 98 0C 00 84 16 D4 E8 81 31 DC C6 DF DD 9E

5C 72 77 FA 5F 67 63 F7 ED 72 68 9D F2 34 9A B4

0D A1 51 1C 9D 20 8C BF C3 1A 58 41 E2 72 2A 75

40 3A BA A1 46 18 CA 56 E1

I'm setting EC scheme domain parameters by

ippsECCPSet(Prime, A, B, GX, GY, Order, cofactor, (IppsECCPState *)pECC);

Then Public Key is being set by

ippsECCPSetPoint(PublicKeyX, PublicKeyY, (IppsECCPPointState *)pKeyPoint, (IppsECCPState *)pECC);

ippsECCPSetKeyPair(0, (IppsECCPPointState *)pKeyPoint, ippTrue, (IppsECCPState *)pECC);

Next step - generation and setting of ephemeral keys:

ippsECCPGenKeyPair(EphemeralPrivateKey, (IppsECCPPointState *)pEphemeralPublicKey, (IppsECCPState *)pECC, ippsPRNGen, pRND);

ippsECCPSetKeyPair(EphemeralPrivateKey, (IppsECCPPointState *)pEphemeralPublicKey, ippFalse, (IppsECCPState *)pECC);

Once again - everything is Ok until that point. No erroneous return codes or something...

3) Next step - DS calculation.

ippsECCPSignDSA(pMsgDigest, PrivateKey, NewSignX, NewSignY, (IppsECCPState *)pECC);

And THIS is a questionable one... From time to time I get ippStsMessageErr return code with a pretty clear description:

Indicates an error condition if the value of

by

where

So, to be more simple, as soon as Big Number in pMsgDigest becomes larger or equal to Order value (given a little bit earlier, in PrivateKey description)ippsECCPSignDSA() fails.

**** Note. I think that a correct text in the documentation should looks like* "*pMsgDigest *falls outside the range of [1, **n-1**]"

Could you please give me a reason of such range check? I really don't understand that and can't find any trace of that in any EC signature related documents/standarts. May be I'm too stupid or blind, but please, guide me to a proper source of information...

How could SIGNING data prevent DS algorithm to do its job? That is really beyond me understanding....

Could it be just a bad selection of EC scheme parameters?

7 Replies

Highlighted
##

Vladimir_D_Intel

Employee

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

05-27-2008
02:25 AM

12 Views

Hello,

there is comment from our expert:

Right, according to IPP implementationthe value (f) to be signed must be in 0<=f

This help us to provide more efficient code. We don't see any difference in result meaning between signing/verifying of 0<=f

Recommendationis touse f = F%r instead of F.

Regards,

Vladimir

Highlighted
##

*
*

Hi!

I have encountered described problem once again. This time with EC signature verification.

This time that issue became too urgent and important to ignore that.

Due to this fact I'm asking you to help me to use correct IPP crypto functions to overcome it.

I need to verifyEC digital signature. The signed data is constant in one of the cases, and its SHA256 message digest is always falls outside that range check, so ippsECCPVerifyDSA() always fails with

kdiamond

Beginner

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

10-06-2009
08:16 AM

12 Views

Quoting - Vladimir Dudnik (Intel)

Hello,

there is comment from our expert:

Right, according to IPP implementationthe value (f) to be signed must be in 0<=f

This help us to provide more efficient code. We don't see any difference in result meaning between signing/verifying of 0<=f

Recommendationis touse f = F%r instead of F.

Regards,

Vladimir

Hi!

I have encountered described problem once again. This time with EC signature verification.

This time that issue became too urgent and important to ignore that.

Due to this fact I'm asking you to help me to use correct IPP crypto functions to overcome it.

I need to verifyEC digital signature. The signed data is constant in one of the cases, and its SHA256 message digest is always falls outside that range check, so ippsECCPVerifyDSA() always fails with

ippStsMessageErr.

You mentioned something like "f = F%r instead of F". I'm sorry, but it's not clear for me what additional operations should be used prior toippsECCPVerifyDSA() to make it work properly. I believe - some big number arithmetic. Could you be so kind to give me a code fragment with a necessary function calls to do that? Any help would be much appreciated.

Thank you in advance.

Highlighted
##

Hi

To fulfill the requirements mentioned by the expert you can for example:

1) replace the value to be signed by its reduction mod order:

ippsMod_BN(hash,order,reducedhash);

and sign and verify the reduced one

(it works fine for me)

or

2) use >224bit curve (if hash has to be 224bit)

or

3) use <224bit hash (if curve has to be 224bit)

Andrzej Chrzeszczyk

achrzesz2

New Contributor I

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

10-08-2009
12:50 AM

12 Views

To fulfill the requirements mentioned by the expert you can for example:

1) replace the value to be signed by its reduction mod order:

ippsMod_BN(hash,order,reducedhash);

and sign and verify the reduced one

(it works fine for me)

or

2) use >224bit curve (if hash has to be 224bit)

or

3) use <224bit hash (if curve has to be 224bit)

Andrzej Chrzeszczyk

Highlighted
##

I haven't mentioned one more possibility:

4) use 224bit curve with larger order than yours

Andrzej Chrzeszczyk

achrzesz2

New Contributor I

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

10-08-2009
01:17 AM

12 Views

4) use 224bit curve with larger order than yours

Andrzej Chrzeszczyk

Highlighted
##

*I haven't mentioned one more possibility:*

4) use 224bit curve with larger order than yours

Andrzej Chrzeszczyk

Thank you for an answer.

1st variant is a solution in my case. We have predefined signature scheme with fixed public key and message digest algorithm so we can't change or choose anything.

But taking a hashmodulus solves an issue.

Still I can't understand why that operation couldn't be hidden from the user and performed INSIDE ippsECCPVerifyDSA() if necessary. That step (hash value reduction)is a very confusing one and is noncompliant to any existing technicalspecification. I suggest you (IPP team)to think about that.

kdiamond

Beginner

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

10-08-2009
01:50 AM

12 Views

Quoting - achrzesz2

4) use 224bit curve with larger order than yours

Andrzej Chrzeszczyk

Thank you for an answer.

1st variant is a solution in my case. We have predefined signature scheme with fixed public key and message digest algorithm so we can't change or choose anything.

But taking a hashmodulus solves an issue.

Still I can't understand why that operation couldn't be hidden from the user and performed INSIDE ippsECCPVerifyDSA() if necessary. That step (hash value reduction)is a very confusing one and is noncompliant to any existing technicalspecification. I suggest you (IPP team)to think about that.

Highlighted
##

Thank you for an answer.

1st variant is a solution in my case. We have predefined signature scheme with fixed public key and message digest algorithm so we can't change or choose anything.

But taking a hashmodulus solves an issue.

Still I can't understand why that operation couldn't be hidden from the user and performed INSIDE ippsECCPVerifyDSA() if necessary. That step (hash value reduction)is a very confusing one and is noncompliant to any existing technicalspecification. I suggest you (IPP team)to think about that.

Dear Andrzej,

It seems that are not related to Intel, so, of course, I directed my suggestion not to you personally... :)

Thanx once again.

kdiamond

Beginner

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

10-08-2009
01:53 AM

12 Views

Quoting - kdiamond

Thank you for an answer.

1st variant is a solution in my case. We have predefined signature scheme with fixed public key and message digest algorithm so we can't change or choose anything.

But taking a hashmodulus solves an issue.

Still I can't understand why that operation couldn't be hidden from the user and performed INSIDE ippsECCPVerifyDSA() if necessary. That step (hash value reduction)is a very confusing one and is noncompliant to any existing technicalspecification. I suggest you (IPP team)to think about that.

Dear Andrzej,

It seems that are not related to Intel, so, of course, I directed my suggestion not to you personally... :)

Thanx once again.

Highlighted
##

Glad to hear

I think that the issue is the performance.

If the curve has more bits than the hash, then the apriopriate reducing is superfluous

Andrzej Chrzeszczyk

achrzesz2

New Contributor I

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

10-08-2009
02:30 AM

12 Views

I think that the issue is the performance.

If the curve has more bits than the hash, then the apriopriate reducing is superfluous

Andrzej Chrzeszczyk

For more complete information about compiler optimizations, see our Optimization Notice.