[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bouncycastle-crypto-dev
Subject:    Re: [dev-crypto] ECIES parameters?
From:       David Hook <dgh () autochthonous ! org>
Date:       2013-11-26 4:50:42
Message-ID: 529428A2.8090508 () autochthonous ! org
[Download RAW message or body]


It shouldn't be an issue if the keys are correctly encoded. SEC and 
X9.62 laid out guidelines for this some years ago. If the keys aren't 
encoded correctly it may be a bit fiddly creating the parameters, but 
they should still work. The maths doesn't change.

Regards,

David

On 26/11/13 14:08, Uri Blumenthal wrote:
> On Nov 25, 2013, at 20:40 , David Hook <dgh@autochthonous.org> wrote:
> > At the moment it's still a matter of something like:
> > 
> > X9ECParameters params = \
> > ECNamedCurveTable.getByName(keyGenParams.getDomainParameters()); 
> > ECKeyPairGenerator kpGen = new ECKeyPairGenerator();
> One problem with this is that the program I’m talking about receives EC keys from \
> another application (based on Crypto++ and written in C++). 
> Or would it still work...?
> 
> > kpGen.init(new ECKeyGenerationParameters(new \
> > ECDomainParameters(params.getCurve(), params.getG(), params.getN(), \
> > params.getH(), params.getSeed()), new SecureRandom()));
> I see. This isn’t too bad - assuming the first two lines can work, or can be \
> replaced with something that can deal with imported ECC keys for secp256k1 curve... \
> 
> > It's like this because originally space considerations made it undesirable to \
> > consider a constructor on ECDomainParamaters that took an X9ECParameters object \
> > as it would have forced an application to drag in a large part of the ASN.1 \
> > library. I'm not sure about the merits of changing it now…
> > -)  Understandable.
> 
> > As for what's defined where, it's important to keep in mind the tests were \
> > written with what was handy at the time (and in the light of the above \
> > consideration as well).
> > -)
> 
> TNX!
> 
> 
> > On 25/11/13 08:50, Uri Blumenthal wrote:
> > > I’m trying to find a good (correct & easy :) way to configure/use Koblitz curve \
> > > secp256k1. 
> > > I’m looking at files:
> > > 
> > > bc-java/core/src/test/java/org/bouncycastle/crypto/test/ECIESTest.java, and
> > > bc-java/prov/src/test/java/org/bouncycastle/jce/provider/test/ECIESTest.java
> > > 
> > > The first file seems to define a good deal more than I think would be \
> > > necessary, because that curve is already supported and defined (somewhere :) in \
> > > the BouncyCastle code. 
> > > In the latter file, I could not figure out what “derivation” and “encoding” \
> > > parameters stand for. :-( 
> > > 
> > > Ideally, I’d like to make use of something like:
> > > 
> > > org.bouncycastle.asn1.sec.SECNamedCurves.getByName(“secp256k1”);
> > > 
> > > 
> > > Could anybody kindly point me at the right direction?
> > > 
> > > Thanks!
> > > 
> > 
> 


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic