Elliptic Curve Cryptography with Sjcl in Js and Openssl in Ruby

Elliptic curve cryptography with SJCL in JS and OpenSSL in Ruby

It looks like you're using ElGamal in your javascript code. I couldn't really find any implementation for ruby, alternatives are using Crypto++ or libgcrypt and writing some glue code.

Ps: instead of that kstr = line, you can simply write kstr = ar.pack 'N*'

Why is the ECC-DH Symmetric Key Of This Site Different From OpenSSL

I've managed to work it out now with working symmetric keys on client (JSBN-EC) and on server OpenSSL Ruby

I found out that my problem actually lies in the code itself. After fixing it, I've ended up with a symmetric key on OpenSSL Ruby as follows:

#Ruby: OpenSSL
...
...
symm_key = ec.dh_compute_key(point)
symm_key.unpack('B*').first.to_i(2) #Converts to binary, then to integer
#--> 6922380353406615622038660570577625762884344085425862813095878420328

While on the client side using JSBN-EC

#Javascript: JSBN-EC
...
...
var curve = get_curve();
var P = new ECPointFp(curve,
curve.fromBigInteger(server_pub_key_x),
curve.fromBigInteger(server_pub_key_y));
var a = client_priv_key;
var S = P.multiply(a);

console.log('SYMM_KEY X: '+S.getX().toBigInteger().toString());
//--> 6922380353406615622038660570577625762884344085425862813095878420328
console.log('SYMM_KEY Y: '+S.getY().toBigInteger().toString());
//--> 14426877769799867628378883482085635535383864283889042780773103726343

Therefore from the looks of it, the symmetric key that matches the Ruby OpenSSL value is the X value of the JSBN-EC symmetric key

6922380353406615622038660570577625762884344085425862813095878420328
==
6922380353406615622038660570577625762884344085425862813095878420328

I don't know what the Y value is now for. Looks like I won't need it. Cheers! :)

SJCL key generation

I found the mistake: ecc.elGamal is no standard sjcl function. I have to compile the sjcl.js file manually with additional functionality included. blog.peramid.es

How to get X and Y coordinates of an EC Point in Rust?

You might want to look at the method affine_coordinates

use openssl::{bn::*, ec::*, nid::Nid};

pub fn print_pub_key(key: &EcKey<openssl::pkey::Private>) -> () {
    let group: EcGroup = EcGroup::from_curve_name(Nid::SECP256K1).unwrap();
    let mut ctx: BigNumContext = BigNumContext::new().unwrap();
    let public_key = key.public_key();
    let mut x = BigNum::new().unwrap();
    let mut y = BigNum::new().unwrap();
    public_key
        .affine_coordinates_gfp(group.as_ref(), &mut x, &mut y, &mut ctx)
        .expect("extract coords");

    println!("{}, {}", x, y);
}

fn main() {
    let group: EcGroup = EcGroup::from_curve_name(Nid::SECP256K1).unwrap();
    let key = EcKey::generate(&group).unwrap();
    print_pub_key(&key);
}

Note that affine_coordinates_gfp and affine_coordinates_gf2m seem to give back the same coordinate in your chosen group.

How to get range of finite field and coefficients used in elliptic curve cryptography from a certificate with OpenSSL?

There are three ways to represent EC parameters within certificates. I'll discuss the most commonly used ones: explicit parameters and named curves.

Explicit EC (domain) parameters are exactly what the name implies: they are values directly put in the certificate. The application that reads in the public key can directly create a full EC public key out of the domain parameters and the value of W, the public point.

Named curves however only identify a previously specified set of domain parameters. They are normally simply represented as strings in software. However in certificates and other ASN.1 DER objects they are represented by ASN.1 OID's. OID's are unique strings of the form 1.2.3 etc. that first represent a registration office, then an organization etc.

If you put your Google certificate in ASN.1 parse you will find one of these OID's, already helpfully transformed into a String:

openssl asn1parse -in google_ec.cer

will yield:

...
251:d=3  hl=2 l=  19 cons: SEQUENCE          
253:d=4  hl=2 l=   7 prim: OBJECT            :id-ecPublicKey
262:d=4  hl=2 l=   8 prim: OBJECT            :prime256v1
...

A quick search will find RFC 5480, which refers to the secp256r1 (see 2.4.2) or NIST P-256 elliptic curve. The latter two define all the parameters of the curve, except W of course. Often it is easier to find these curve parameters from existing software though as the standards may not represent them in a useful format for your specific runtime environment.

---

Related Topics