On Thu, Dec 11, 2014 at 3:30 PM, Adam Langley a...@google.com wrote:
Thanks. So far that version is good to ~1B random tests. I'll leave it
going until Monday.
It's good for ~6B random tests.
Of course, that's not as compelling for 64-bit code as it would be for
32-bit, but I think we can
On Wed, Dec 10, 2014 at 10:05 AM, Andy Polyakov via RT r...@openssl.org wrote:
Patching went wrong for you. As you seem to operate in 1.0.2 context
attached is corresponding ecp_nistz256.pl.
Thanks. So far that version is good to ~1B random tests. I'll leave it
going until Monday.
Cheers
AGL
On Fri, Dec 5, 2014 at 6:33 AM, Andy Polyakov via RT r...@openssl.org wrote:
Attached. A little bit worse performance on some CPUs. I also took
opportunity to harmonize ecp_nistz256_from_mont by applying same pattern
for reduction. The patch is cumulative, i.e. is not incremental to
previously
Attached. A little bit worse performance on some CPUs. I also took
opportunity to harmonize ecp_nistz256_from_mont by applying same pattern
for reduction. The patch is cumulative, i.e. is not incremental to
previously posted one[s], and addresses both problems, originally
reported one and
Oops! Wrong patch! Correct one attached. If you feel like testing the
wrong one, go ahead, but there are some later non-essential adjustments.
diff --git a/crypto/ec/ecp_nistz256.c b/crypto/ec/ecp_nistz256.c
index bf3fcc6..33b07ce 100644
--- a/crypto/ec/ecp_nistz256.c
+++
Oops! Wrong patch! Correct one attached. If you feel like testing the
wrong one, go ahead, but there are some later non-essential adjustments.
diff --git a/crypto/ec/ecp_nistz256.c b/crypto/ec/ecp_nistz256.c
index bf3fcc6..33b07ce 100644
--- a/crypto/ec/ecp_nistz256.c
+++
Oops! Wrong patch! Correct one attached. If you feel like testing the
wrong one, go ahead, but there are some later non-essential adjustments.
diff --git a/crypto/ec/ecp_nistz256.c b/crypto/ec/ecp_nistz256.c
index bf3fcc6..33b07ce 100644
--- a/crypto/ec/ecp_nistz256.c
+++
thanks! Was away last week and so didn't have a chance to try fixing this.
I'll patch that it and run the tests against it.
I've run out of time tracking this down for today, but I got to the
point where setting the Jacobian coordinates:
X:
thanks! Was away last week and so didn't have a chance to try fixing this.
I'll patch that it and run the tests against it.
I've run out of time tracking this down for today, but I got to the
point where setting the Jacobian coordinates:
X:
thanks! Was away last week and so didn't have a chance to try fixing this.
I'll patch that it and run the tests against it.
I've run out of time tracking this down for today, but I got to the
point where setting the Jacobian coordinates:
X:
thanks! Was away last week and so didn't have a chance to try fixing this.
I'll patch that it and run the tests against it.
I've run out of time tracking this down for today, but I got to the
point where setting the Jacobian coordinates:
X:
2. When will RT2574 be integrated to protect our ECC keys in the
inevitable presence of software defects like this?
http://rt.openssl.org/Ticket/Display.html?id=2574user=guestpass=guest
Reportedly, Cryptography Research (i.e., Rambus) alleges to have broad
patents on techniques like this
On Wed, Dec 3, 2014 at 10:12 AM, Andy Polyakov via RT r...@openssl.org wrote:
Oops! Wrong patch! Correct one attached. If you feel like testing the
wrong one, go ahead, but there are some later non-essential adjustments.
diff --git a/crypto/ec/ecp_nistz256.c b/crypto/ec/ecp_nistz256.c
index
On Mon, Dec 1, 2014 at 3:23 PM, Andy Polyakov via RT r...@openssl.org wrote:
(Affects 1.0.2 only.)
In crypto/ec/asm/ecp_nistz256-x86_64.pl, __ecp_nistz256_sqr_montq,
under Now the reduction there are a number of comments saying
doesn't overflow. Unfortunately, they aren't correct.
Got math
On Tue, Dec 2, 2014 at 12:33 PM, Adam Langley a...@google.com wrote:
thanks! Was away last week and so didn't have a chance to try fixing this.
I'll patch that it and run the tests against it.
I've run out of time tracking this down for today, but I got to the
point where setting the Jacobian
(Affects 1.0.2 only.)
In crypto/ec/asm/ecp_nistz256-x86_64.pl, __ecp_nistz256_sqr_montq,
under Now the reduction there are a number of comments saying
doesn't overflow. Unfortunately, they aren't correct.
Got math wrong:-( Attached is not only fixed version, but even faster
one. On related
(Affects 1.0.2 only.)
In crypto/ec/asm/ecp_nistz256-x86_64.pl, __ecp_nistz256_sqr_montq,
under Now the reduction there are a number of comments saying
doesn't overflow. Unfortunately, they aren't correct.
Got math wrong:-( Attached is not only fixed version, but even faster
one.
Please
2. When will RT2574 be integrated to protect our ECC keys in the inevitable
presence of software defects like this?
http://rt.openssl.org/Ticket/Display.html?id=2574user=guestpass=guest
Timing attacks on ECC isn't a very high priority right now, given all the other
bigger easier to exploit
Thanks for the reply, Rich.
2. When will RT2574 be integrated to protect our ECC keys in the inevitable
presence of software defects like this?
http://rt.openssl.org/Ticket/Display.html?id=2574user=guestpass=guest
Timing attacks on ECC isn't a very high priority right now, given all the
1. Where's the security analysis? Does https://eprint.iacr.org/2011/633 apply?
2. When will RT2574 be integrated to protect our ECC keys in the
inevitable presence of software defects like this?
http://rt.openssl.org/Ticket/Display.html?id=2574user=guestpass=guest
These questions are not
(Affects 1.0.2 only.)
In crypto/ec/asm/ecp_nistz256-x86_64.pl, __ecp_nistz256_sqr_montq,
under Now the reduction there are a number of comments saying
doesn't overflow. Unfortunately, they aren't correct.
Let f be a field element with value
21 matches
Mail list logo
