point compressing and decompressing

[GoogleCodeExporter]

What steps will reproduce the problem?
1. I make point compressing and decompressing
2. I am using Montgomery reduction

What is the expected output? What do you see instead?
I expect to have in Y coordinate just 1 or 0, but, I have had 0 and another 
number greater than zero

What version of the product are you using? On what operating system?
Relic 0.3.0; Ubuntu 11.04

Please provide any additional information below.
I want Montgomery reduction because is faster than the basic reduction. 
Moreover, I want X coordinate in full size and the Y coordinate be one bit long 
to save space. Would I need to use basic reduction?

Original issue reported on code.google.com by dio...@gmail.com on 29 Jul 2011 at 6:05

[GoogleCodeExporter]

I confirm point compression works when Montgomery reduction is configured. What 
happens is that y is compressed to a single bit which is incorrectly 
interpreted when you print the point or just the y-coordinate. However, it 
works as expected if you just test the lowest significant bit (as it's done in 
ep_upk()). This number greater than zero is actually 2^n mod p, or 1 in 
Montgomery representation.

Is this counter-intuitive and would it be better if the semantics was 
compatible with Montgomery reduction, with the price that directly examining 
the memory for the y-coordinate would now be inconsistent with intuition?

Original comment by dfaranha on 29 Jul 2011 at 11:57

[GoogleCodeExporter]

Original comment by dfaranha on 30 Jul 2011 at 12:29

• Changed state: Accepted

[GoogleCodeExporter]

Oh, I see. It seen better this manner.

I needed to swap:
  fp_zero(ecTmp->y);
  fp_add_dig(ecTmp->y,1);
by
  fp_zero(ecTmp->y);
  fp_set_bit(ecTmp->y,0,1);

Now, the program works, thanks!

Original comment by dio...@gmail.com on 1 Aug 2011 at 12:53

[GoogleCodeExporter]

Great! I will consider this as fixed and close the issue.

Original comment by dfaranha on 1 Aug 2011 at 5:49

• Changed state: Verified