Ed's already covered how to make use of the KDF.
With 2: the byte array is actually an encoding of an ASN.1 SEQUENCE
containing two INTEGER fields (r and s). This is the standard way to
present a DSA signature. Note if you need to encode your own on the
other side, integers in ASN.1 are big-endian and signed, much grief will
result if this is neglected.
Regards,
David
On 04/01/16 21:06, Jan Hammer wrote:
> Hi!
>
> Im exchanging keys between BouncyCastle C# and the Cryptovision C API,
> however I have some compatibility problems doing so:
>
> 1.:
> Cryptovision derives the key the following way, from the other partys
> public key and the own private key (the number of derivations can be
> chosen):
> ** This function calculates the common secret d1 * Q2 (= d1 * d2 * G)
> ** and derives the output key from the x-coordinate of the secret with
> ** the KDF2HMACSHA1 derivation function of the library.
>
> Using AgreementUtilities.GetBasicAgreement("ECDH") and =>
> CalculateAgreement() obviously leads to a different result.
> How does the CalculateAgreement function calculate the output and
> therefore is there a way to come to the same conclusion as on the
> Cryptovision part?
>
>
> 2.:
> Cryptovision computes the ECDSA signature according to ANSI X9.62, the
> parameters im getting are the signature_r and signature_s components.
> In BouncyCastle im using SignerUtilities.GetSigner("ECDSA") to compute
> and verify the signatures.
> So now I have the byte[] signature on the BouncyCastle side and the r
> and s components of the signature on the Cryptovision side,
> any information what the byte[] computed in BouncyCastle consists of
> (r/s, r+s components..?) or how these things can be put together?
>
> Any information will be highly appreciated!
>
> Thanks in advance and regards,
> Jan Hammer
>
