title: Trying to reconcile elliptic curve error
body: <p>I am trying to do the following:</p>
  
  <p>I have a piece of software which is using ECC to generate a standard Rijndael key (<em>NOT</em> AES... There is a difference: AES only supports key sizes of 128, 192, and 256 bits, while Rijndael  originally supported 160 and 224 bits.  This bit me at first when I was looking at the software.)  I have been able to determine that it does the following:</p>
  
  <p>It has several modes, but in the weakest mode, it uses ECC secp160r1 to generate a 160 bit key (hence the Rijndael and <em>NOT</em> AES).  I have been able to take "public" values and use the private key in my own software, and, using openssl calls, have been able to generate the same keys and decrypt the data I need to decrypt.</p>
  
  <p>In the best (strongest/hardest, what have you) mode, it pretty much does the same thing, however, it uses ECC sect571k1 to generate a key and takes only the first 32 bytes of the 72 it generates for a Rijndael 256 bit key (in this case, you could say AES256).</p>
  
  <p>However, in another mode, it APPEARS to do the same thing, but when I attempt to do the same thing as I have done before, I DON'T get the same shared secret.</p>
  
  <p>If you use the standard definitions for Alice and Bob:</p>
  
  <pre><code>da = Alice's secret key
  db = Bob's secret key
  Qa = Alice's public key
  Qb = Bob's public key
  S  = Shared secret
  </code></pre>
  
  <p>I Have:</p>
  
  <pre><code>daQb --&gt; The public value sent from Alice.
  db   --&gt; My "secret" key.
  Qb   --&gt; My "public" key.
  Sc   --&gt; The "correct" shared secret as computed by above program
  </code></pre>
  
  <p>I have checked that my Qb and the daQb are on the sect283k1 curve.  If I use
  sect283r1, things fail, and my points don't register on that curve using Openssl
  EC_POINT, EC_KEY, EC_GROUP functions (I would post the code now, but I don't have
  it in front of me.  As soon as I do, I'll try to post it here).  I have been able
  to reproduce, as I said, two other modes, and it seems to work properly.  However,
  in this mode, when I compute the key, I get Sw --> The "wrong" shared secret as computed
  by MY program.</p>
  
  <p>So, my question is this:  Do I have enough information to potentially determine if I may
  be using the wrong db?  I don't think that I am, because in the other two cases, I can
  get the db and it works fine.  Unfortunately, I don't have the source code for said program.  I am trying to create a tool that can work with the data generated by the original tool.</p>
  
  <p>I thought of trying to invert Qb and multiply the data by daQb, but all that really does is
  get me da, which, while interesting, doesn't lead me to a way I can use it on the shared secret I have to determine db, to check my work.</p>
  
  <p>The other thing I thought of is that maybe a similar curve to sect283k1 was used, but NOT sect283k1 (i.e. maybe some different G?  I'm not sure if it is possible to use another generator on that curve, but I didn't think there was but 1 generator per curve, but maybe that is wrong, and maybe another generator would produce different results... i.e. the correct results).</p>
  
  <p>At any rate, I've tried several things only to produce the same wrong key data using, presumably, the same data the other program is using.  Maybe someone with some far superior EC math knowledge (just about any would be better than my own, but I'm hoping for someone who can help me see what I'm missing) can show me a way I can reconcile what I get with what the other tool gets.</p>
  
  <p>Unfortunately, I can stop just before the Rijndael key is set and see what it will be set to.  I can find that part of the key and see the original data that came from an ECDH_compute_key operation (which appears to essentially be an EC_POINT_mul between daQb and db (If I know enough about Diffie-Hellman key exchange... I've verified this much anyway using some openssl calls), and I know a few other things, but I can't locate the Bignum/EC code that would help me see what went into the operation.  So I'm looking for another way to skin the cat.</p>
  
  <p>Thanks to anyone that can help.</p>