Multiplication and pairing issues

[liorko87]

Hello,

I'm using bilinear map at MIRACL. When I'm multiply two elements it takes me more time then doing pairing of two elements. Isn't suppose to be the opposite?

The multiplication done by using this function : G1 PFC::mult(const G1& w,const Big& k)

The pairing is done by using this function : GT PFC::pairing(const G2& x,const G1& y)

Thank you for your answer
Lior

[mcarrickscott]

More details needed. The multiplication is not of "two elements", it is of
a point in G1 by a scalar big number.

But you are right. I would certainly expect the multiplication in G1 to be
faster than the pairing....

Which pairing? BN curve? Are any of the elements involved subject to
pre-computation?

What are the values of w, k, x and y?

For example if x or y is the point-at-infinity the pairing will be very
fast :)

Mike

On Wed, Nov 2, 2016 at 12:59 PM, liorbiu notifications@github.com wrote:

Hello,

I'm using bilinear map at MIRACL. When I'm multiply two elements it takes
me more time then doing pairing of two elements. Isn't suppose to be the
opposite?

The multiplication done by using this function : G1 PFC::mult(const G1&
w,const Big& k)

The pairing is done by using this function : GT PFC::pairing(const G2&
x,const G1& y)

Thank you for your answer
Lior

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#34, or mute the thread
https://github.com/notifications/unsubscribe-auth/ACm8jiBxwYfUV8SnANs0axSkCtH2TJ--ks5q6IlAgaJpZM4KnNPI
.

[liorko87]

I'm using cp_pair where k=2 and G1 and G2 are enc types.
To get access to the multiplication and pairing I'm using PFC object and init it by using PFC pfc(AES_SECURITY)
The G1 element generated by using pfc.hash_and_map(tmp_g1, (char*)Inputs[i].c_str());, where inputs is vector of strings.

[mcarrickscott]

Well I tested here with the ake.cpp program, compiled to use cp_pair at the
AES =80 level.

Some rough timings indicate that the multiplication is 3-4 times faster
than the pairing. So I cannot replicate your results. In your
multiplication, what value are you using for the multiplier k?

However using the CP curves with embedding degree 2, multiplication in G1
(which is 512 bits) will take a lot more time than for example an MNT
curve, where G1 is just 160 bits.

Mike

On Wed, Nov 2, 2016 at 1:45 PM, liorbiu notifications@github.com wrote:

I'm using cp_pair where k=2 and G1 and G2 are enc types.
To get access to the multiplication and pairing I'm using PFC object and
init it by using PFC pfc(AES_SECURITY)
The G1 element generated by using pfc.hash_and_map(tmp_g1,
(char*)Inputs[i].c_str());, where inputs is vector of strings.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#34 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACm8jhF9LagoaLd7t7zfLsycFWZc8C8uks5q6JQBgaJpZM4KnNPI
.

[liorko87]

Hello Mike,

Thank you for your reply. The pairing stage is done by using constant G2 token for all the pairings. We are changing only G1 during the pairing. It could be the reason for doing the pairing faster then encryption?

[mcarrickscott]

Well it depends on what exactly you are doing, and I don't know what
exactly you are doing.

However if the same G2 is being used in all cases, then you should
precompute on G2, using pfc.precomp_for_pairing(g2).

And if you are doing that, then the pairing would be significantly faster.

But then again I don't know exactly what you are doing, so I am just
guessing...

Mike

On Sun, Nov 6, 2016 at 8:36 AM, liorbiu notifications@github.com wrote:

Hello Mike,

Thank you for your reply. The pairing stage is done by using constant G2
token for all the pairings. We are changing only G1 during the pairing. It
could be the reason for doing the pairing faster then encryption?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#34 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACm8jvvkkJr20-oEX45IAt5mjs6IUwIoks5q7ZFxgaJpZM4KnNPI
.

[liorko87]

We noticed the following phenomenon. Consider the following three settings:

1. Doing N pairings with a fresh set of inputs in G1,G2 for each pairing.
2. Doing N pairings that all have the same G2 input.
3. The same as 2, and in addition we called pfc.precomp_for_pairing(g2) before doing the pairings

The performance in setting 2 was much better than in 1. Going to setting 3 didn't improve over setting 2. So we assume that preprocessing is done implicitly by MIRACL. Is this indeed the case?

[mcarrickscott]

No, pre-processing for the pairing is not done implicitly.

There must be an explicit call to pfc.precomp_for_pairing()

To investigate further I would need to see a copy of your test program.

Mike

On Mon, Nov 7, 2016 at 11:57 AM, liorbiu notifications@github.com wrote:

We noticed the following phenomenon. Consider the following three settings:

1. Doing N pairings with a fresh set of inputs in G1,G2 for each pairing.
2. Doing N pairings that all have the same G2 input.
3. The same as 2, and in addition we called pfc.precomp_for_pairing(g2)
   before doing the pairings

The performance in setting #2 #2
was much better than in #1 #1.
Going to setting #3 #3 didn't
improve over setting #2 #2. So we
assume that preprocessing is done implicitly by MIRACL. Is this indeed the
case?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#34 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACm8jtKNlrcpJAxOfT3q0CsPcWAmhGxNks5q7xI-gaJpZM4KnNPI
.

[liorko87]

We defined G2 token like this :

G2 token;
m_pfc.hash_and_map(token,(char*)"CommonToken");

The code of the pairing is done by running this loop. My test program measure the times this loop was executed.

high_resolution_clock::time_point t1 = high_resolution_clock::now();
    for(auto idx = 0; idx<m_inputs.size();idx++)
    {
        GT encrypted = m_pfc.pairing(token,m_inputs[idx]);
    }

    high_resolution_clock::time_point t2 = high_resolution_clock::now();
    auto duration = duration_cast<milliseconds>( t2 - t1 ).count();

When we used pfc.precomp_for_pairing() the program was actually a bit slower, so we assumed that pre-processing was done behind the scenes.

When m_inputs is an array of elements ofG1 and token is a constant element of G2. When we used different G2 element, the code was much slower.

[mcarrickscott]

Try this program..

---

#include
#include
#define MR_PAIRING_CP // AES-80 security
#define AES_SECURITY 80

#include "pairing_3.h"

#define ITERS 1000

int main()
{
PFC pfc(AES_SECURITY); // initialise pairing-friendly curve

int i,j,iterations;
double elapsed;
clock_t start;
G2 g2[ITERS];
G1 gk,g1[ITERS];
GT gt;
Big k[ITERS];

for (i=0;i<ITERS;i++)
{
pfc.random(g2[i]);
pfc.random(g1[i]);
pfc.random(k[i]);
}

start=clock();

iterations=0;
do {
// pfc.random(g1);
gt=pfc.pairing(g2[iterations],g1[iterations]);
iterations++;
elapsed=(clock()-start)/(double)CLOCKS_PER_SEC;
} while (iterations<ITERS);

elapsed=1000.0*elapsed/iterations;
cout << "Without precomputation, variable G2 " << iterations << "

pairings " << elapsed << " ms per pairing" << endl;

start=clock();

iterations=0;
do {
// pfc.random(g1);
gt=pfc.pairing(g2[0],g1[iterations]);
iterations++;
elapsed=(clock()-start)/(double)CLOCKS_PER_SEC;
} while (iterations<ITERS);

elapsed=1000.0*elapsed/iterations;
cout << "Without precomputation, fixed G2 " << iterations << " pairings

" << elapsed << " ms per pairing" << endl;

pfc.precomp_for_pairing(g2[0]);

start=clock();

iterations=0;
do {
// pfc.random(g1);
gt=pfc.pairing(g2[0],g1[iterations]);
iterations++;
elapsed=(clock()-start)/(double)CLOCKS_PER_SEC;
} while (iterations<ITERS);

elapsed=1000.0*elapsed/iterations;
cout << "With precomputation, fixed G2 " << iterations << " pairings "

<< elapsed << " ms per pairing" << endl;

start=clock();

iterations=0;
do {
gk=pfc.mult(g1[iterations],k[iterations]);
iterations++;
elapsed=(clock()-start)/(double)CLOCKS_PER_SEC;
} while (iterations<ITERS);

elapsed=1000.0*elapsed/iterations;
cout << iterations << " G1 muls " << elapsed << " ms per mul" << endl;

return 0;

}

---

On my computer the output is (very much as I would expect it)

Without precomputation, variable G2 1000 pairings 2.145 ms per pairing
Without precomputation, fixed G2 1000 pairings 2.148 ms per pairing
With precomputation, fixed G2 1000 pairings 1.044 ms per pairing
1000 G1 muls 0.823 ms per mul

Mike

On Tue, Nov 8, 2016 at 1:48 PM, liorbiu notifications@github.com wrote:

We defined G2 token like this :

G2 token;
m_pfc.hash_and_map(token,(char*)"CommonToken");

The code of the pairing is done by running this loop. My test program
measure the times this loop was executed.

high_resolution_clock::time_point t1 = high_resolution_clock::now();
for(auto idx = 0; idx<m_inputs.size();idx++)
{
GT encrypted = m_pfc.pairing(token,m_inputs[idx]);
}

high_resolution_clock::time_point t2 = high_resolution_clock::now();
auto duration = duration_cast<milliseconds>( t2 - t1 ).count();

When we used pfc.precomp_for_pairing() the program was actually a bit
slower, so we assumed that pre-processing was done behind the scenes.

When m_inputs is an array of elements ofG1 and token is a constant
element of G2. When we used different G2 element, the code was much
slower.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#34 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACm8jhvpq9CSA3J_LA3Fm-LTKa7DAb_yks5q8H2ugaJpZM4KnNPI
.