Need help

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Need help

Ranadheer Gundreddy - TollPlus

We have a requirement to use Elliptic Curve Cryptography. We need to hash the data with SHA256 and then sign the data. We have chosen to Bouncy Castle C# API to implement the same.

Here is the technical requirements to follow.  

 

Language: C#

Hashing: using SHA256  

Signing:

Cryptography: Elliptic Curve Cryptography Curve : p-128 (secp128r1)

Algorithm: ECDSA

 

We have developed a sample code and able to sign the data but we are facing the following issues.

• We are not able to validate the data after signing.

• We need the signed data in 32 byte length but receiving in 38 byte length.

 

Can you please help us to resolve the above issues. Thanks in Advance.

Please check the attached source code in C# for you reference. Kindly get back to us at the earliest possible.

 

Thanks

Ranadheer

 

 


Sign and Verify the Signature.txt (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need help

Lothar Kimmeringer-4


Am 31.08.2016 um 09:57 schrieb Ranadheer Gundreddy - TollPlus:
> We have a requirement to use Elliptic Curve Cryptography. We need to hash
>  the data with SHA256 and then sign the data. We have chosen to Bouncy Castle
>  C# API to implement the same.

Congratulations ;-)

> We have developed a sample code and able to sign the data but we are facing the following issues.
>
> • We are not able to validate the data after signing.
>
> • We need the signed data in 32 byte length but receiving in 38 byte length.

First, I'm using BC Java, so I can't provide fixed code for your problem but
what I can see is that you don't get 38 bytes of data but 38 bytes of
DER-encoded data:

     // Generate the Sequence
     DerSequence myDerSeq = myAsn1Value.ReadObject() as DerSequence;
[...]
     // Singature Value
     var signValue = myDerSeq[1].GetEncoded();

GetEncoded returns the DER-data including the type-definition and
length-information. I haven't checked the ASN.1-format for
EC-signature-data but 6 additional bytes isn't that surprising.

Since I don't know the actual ASN.1-structure for a signature I
can't come up with the correct code to extract the signature bytes
but why do you need to extract the data this way?

Also, when recreating the the ASN.1-structure for verifying the
signature, you're using DERIntegers for the signature-data and I
bet body parts of your collegues that the signature-data is something
else, e.g. an Octet String. With the wrong type in the data structure
the part in BouncyCastle will most likely complain about this.

Personally I think the concept of frankensteining signature data (take
the parts from the original block and stitch them together again) should
be rethought. In case you're forced to exchange signature data this way
(loosing security features that are within the signature data itself BTW)
check the actual ASN.1-structure of that data (you can do that e.g.
using ASN1Dump - if that exists in C#) in order to know how to do it.

> Kindly get back to us at the earliest possible.

Kindly check
https://www.bouncycastle.org/donate/index.cgi
for letting others debug your code.  ;-)


Cheers, Lothar

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Need help

Ranadheer Gundreddy - TollPlus
Hi Lothar,

Appreciate your quick response. We have checked your suggestion and able to
get the required data. Thank you for your help.

Thanks
Ranadheer

-----Original Message-----
From: Lothar Kimmeringer [mailto:[hidden email]]
Sent: Wednesday, August 31, 2016 4:43 PM
To: [hidden email]; [hidden email]
Subject: Re: [dev-crypto] Need help



Am 31.08.2016 um 09:57 schrieb Ranadheer Gundreddy - TollPlus:
> We have a requirement to use Elliptic Curve Cryptography. We need to
> hash  the data with SHA256 and then sign the data. We have chosen to
> Bouncy Castle  C# API to implement the same.

Congratulations ;-)

> We have developed a sample code and able to sign the data but we are
facing the following issues.
>
> . We are not able to validate the data after signing.
>
> . We need the signed data in 32 byte length but receiving in 38 byte
length.

First, I'm using BC Java, so I can't provide fixed code for your problem but
what I can see is that you don't get 38 bytes of data but 38 bytes of
DER-encoded data:

     // Generate the Sequence
     DerSequence myDerSeq = myAsn1Value.ReadObject() as DerSequence; [...]
     // Singature Value
     var signValue = myDerSeq[1].GetEncoded();

GetEncoded returns the DER-data including the type-definition and
length-information. I haven't checked the ASN.1-format for EC-signature-data
but 6 additional bytes isn't that surprising.

Since I don't know the actual ASN.1-structure for a signature I can't come
up with the correct code to extract the signature bytes but why do you need
to extract the data this way?

Also, when recreating the the ASN.1-structure for verifying the signature,
you're using DERIntegers for the signature-data and I bet body parts of your
collegues that the signature-data is something else, e.g. an Octet String.
With the wrong type in the data structure the part in BouncyCastle will most
likely complain about this.

Personally I think the concept of frankensteining signature data (take the
parts from the original block and stitch them together again) should be
rethought. In case you're forced to exchange signature data this way
(loosing security features that are within the signature data itself BTW)
check the actual ASN.1-structure of that data (you can do that e.g.
using ASN1Dump - if that exists in C#) in order to know how to do it.

> Kindly get back to us at the earliest possible.

Kindly check
https://www.bouncycastle.org/donate/index.cgi
for letting others debug your code.  ;-)


Cheers, Lothar


Loading...