Thank you Jeff, I managed to write the code related to the key agreement and validated that at least I got the same sharedSecret as in the example with Bouncy Castle. So now I've got the questions related to KeyDerivationAlgo and EncryptionAlgo.
1. According to Bouncy Castle compatability patch and java example as I understand I need to instantiate: DL_KeyDerivationAlgorithm_P1363<ECP::Point, true /*DHAES_MODE*/, P1363_KDF2< SHA256> > derieveAlgo; DL_EncryptionAlgorithm_Xor<HMAC<SHA256>, true /*DHAES_MODE*/, true /*BC_COMPAT*/> encAlgo; In the documentation they mention DEM2 from ISO 18033-2. Is the encAlgo definition above fully compatible with that? 2. One more thing that I'm missing right now - which params should I store in NameValuePairs? I guess for: - deriviation they should be at least: null sault, info string Android encoded in Ascii. - encryption algo: zero IV and no padding But I have no idea how to specify them properly or if I missed any of them. Documentation for NameValuePairs didn't help. Also I failed to find any examples/tests which specify KeyDerivationParameters or EncodingParameters. Any help would be appreciated. четверг, 3 марта 2016 г., 18:46:40 UTC+1 пользователь Jeffrey Walton написал: > > > string ephemeralPubKey64 = >> "BPhVspn70Zj2Kkgu9t8+ApEuUWsI/zos5whGCQBlgOkuYagOis7" >> "qsrcbQrcprjvTZO3XOU+Qbcc28FSgsRtcgQE="; >> StringSource ssECPoint(ephemeralPubKey64, true, new Base64Decoder >> ); >> >> DL_GroupParameters_EC<ECP> params(CryptoPP::ASN1::secp256r1()); >> ECP::Point point; >> >> if (!params.GetCurve().DecodePoint(point, ssECPoint, (size_t) >> ssECPoint.MaxRetrievable())) >> std::cerr << "Invalid decoding" << endl; >> >> ECIES<ECP>::PublicKey ephemeralPubKey; >> ephemeralPubKey.Initialize(params, point); >> >> ephemeralPubKey.ThrowIfInvalid(prng, 3); >> >> cout << "Public key appears to be valid" << endl; >> >> But still need to figure out how to pass it to Decryptor >> > > Decryptors use the private key; Encryptor's use the public key. > > Its not readily apparent... the way to work with an ephemeral public key > is detailed at "Ephemeral Key as (x,y)" under the ECDH page, > http://www.cryptopp.com/wiki/Elliptic_Curve_Diffie-Hellman#Ephemeral_Key_as_.28x.2Cy.29 > > . It applies to ECIES as well. > > The pain point in using ephemeral keys is they are meant for one run of > the protocol, so they don't lend themselves to manipulation outside of the > scheme objects. The static or long term keys are a different story. > > An ephemeral key is meant to be used by, for example, > SimpleKeyAgreementDomain, > which culminates in a call to Agree(...). Since the SimpleKeyAgreementDomain > does all the work, there's usually less support for importing and exporting > the ephemeral key. It can be done, but you have to understand the details. > > Jeff > -- -- You received this message because you are subscribed to the "Crypto++ Users" Google Group. To unsubscribe, send an email to [email protected]. More information about Crypto++ and this group is available at http://www.cryptopp.com. --- You received this message because you are subscribed to the Google Groups "Crypto++ Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
