gh-libtom/libtomcrypt
Watch
1
0
Fork
You've already forked libtomcrypt
 0
Code Issues 42 Pull requests 17 Releases 9 Wiki Activity

ecc_test function is not working #295

New issue
Closed
opened 2017-09-20 11:27:19 -05:00 by hmnsh18 · 19 comments
hmnsh18 commented 2017-09-20 11:27:19 -05:00 (Migrated from github.com)

Hi All,
I ported the libtom crypt code with tom fast math library in embedded platform. I am successfully able to port the RSA logic and all the functionalities are running without any problem. However, I am facing a problem while running the ecc_test function. It is getting stuck in "hsm_sdk_ecc_map" function for the first curve itself.
I have observed that values in x,y,and z members of M[0] are 0. Initially there were some values in these variables but it got zero during the execution of for loop in the function "hsm_sdk_ecc_mulmod".
Does anyone have faced the similar problem? It would be great if someone can throw some pointers on the above scenario.

Hi All, I ported the libtom crypt code with tom fast math library in embedded platform. I am successfully able to port the RSA logic and all the functionalities are running without any problem. However, I am facing a problem while running the ecc_test function. It is getting stuck in "hsm_sdk_ecc_map" function for the first curve itself. I have observed that values in x,y,and z members of M[0] are 0. Initially there were some values in these variables but it got zero during the execution of for loop in the function "hsm_sdk_ecc_mulmod". Does anyone have faced the similar problem? It would be great if someone can throw some pointers on the above scenario.
karel-m commented 2017-09-20 11:34:24 -05:00 (Migrated from github.com)

What libtomcrypt version or git branch are you using?

What libtomcrypt version or git branch are you using?
hmnsh18 commented 2017-09-20 11:39:48 -05:00 (Migrated from github.com)

I am using "libtomcrypt-1.18.0-rc3" version and latest version of tom fast math.

I am using "libtomcrypt-1.18.0-rc3" version and latest version of tom fast math.
sjaeckel commented 2017-09-20 11:45:13 -05:00 (Migrated from github.com)

  1. Did you have to change anything in any of the libs? If yes, can you please provide the diffs

  2. Which configurations do you use?

1. Did you have to change anything in any of the libs? If yes, can you please provide the diffs 2. Which configurations do you use?
sjaeckel commented 2017-09-20 11:47:59 -05:00 (Migrated from github.com)

And what's these functions hsm_sdk_ecc_mulmod and hsm_sdk_ecc_map? Never heard of them.

And what's these functions `hsm_sdk_ecc_mulmod` and `hsm_sdk_ecc_map`? Never heard of them.
karel-m commented 2017-09-20 11:48:34 -05:00 (Migrated from github.com)

There are some ecc related issues (e.g. #108 #116) which we have decided not to fix in 1.18.

However, there is a branch pr/ecc-non-asn1-part related to #236 which contains some ecc fixes that are not included in 1.18. What regards ltc_ecc_mulmod it has a new/better handling of so called "point at infinity". Could you please try the pr/ecc-non-asn1-part branch?

It would also help if you can post a small failing C example demonstrating your problem.

There are some ecc related issues (e.g. #108 #116) which we have decided not to fix in 1.18. However, there is a branch `pr/ecc-non-asn1-part` related to #236 which contains some ecc fixes that are not included in 1.18. What regards `ltc_ecc_mulmod` it has a new/better handling of so called "point at infinity". Could you please try the `pr/ecc-non-asn1-part` branch? It would also help if you can post a small failing C example demonstrating your problem.
hmnsh18 commented 2017-09-20 11:53:38 -05:00 (Migrated from github.com)

Hi Stefan

Sorry for the misunderstanding. I have renamed the function

Originally these functions were ltc_ee_mulmod and ltc_ecc_map

The current configuration I am using is

#define LTC_ECC112
#define LTC__ECC128
#define LTC_ECC160
#define LTC_ECC192
#define LTC_ECC224
#define LTC_ECC256
#define LTC_ECC384
#define LTC_ECC521

/* ECC */
#define LTC_MECC

/* use Shamir's trick for point mul (speeds up signature verification) */
#define LTC_ECC_SHAMIR

/#define LTC_MECC_ACCEL/

/* do we want fixed point ECC /
/#define LTC_MECC_FP */

/#define LTC_ECC_TIMING_RESISTANT/

The size of fp_int I have selected is 4096 bits.

On Wed, Sep 20, 2017 at 10:18 PM, Steffen Jaeckel notifications@github.com
wrote:

And what's these functions hsm_sdk_ecc_mulmod and hsm_sdk_ecc_map? Never
heard of them.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/libtom/libtomcrypt/issues/295#issuecomment-330912416,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Aeplj-I37LG9GMbGyPmIGaXL5NAjrPa_ks5skUHCgaJpZM4PeI3p
.

Hi Stefan Sorry for the misunderstanding. I have renamed the function Originally these functions were ltc_ee_mulmod and ltc_ecc_map The current configuration I am using is #define LTC_ECC112 #define LTC__ECC128 #define LTC_ECC160 #define LTC_ECC192 #define LTC_ECC224 #define LTC_ECC256 #define LTC_ECC384 #define LTC_ECC521 /* ECC */ #define LTC_MECC /* use Shamir's trick for point mul (speeds up signature verification) */ #define LTC_ECC_SHAMIR /*#define LTC_MECC_ACCEL*/ /* do we want fixed point ECC */ /*#define LTC_MECC_FP */ /*#define LTC_ECC_TIMING_RESISTANT*/ The size of fp_int I have selected is 4096 bits. On Wed, Sep 20, 2017 at 10:18 PM, Steffen Jaeckel <notifications@github.com> wrote: > And what's these functions hsm_sdk_ecc_mulmod and hsm_sdk_ecc_map? Never > heard of them. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <https://github.com/libtom/libtomcrypt/issues/295#issuecomment-330912416>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/Aeplj-I37LG9GMbGyPmIGaXL5NAjrPa_ks5skUHCgaJpZM4PeI3p> > . >
hmnsh18 commented 2017-09-20 11:54:22 -05:00 (Migrated from github.com)

No, I have not changed any thing in the library. Just renamed the variables
and functions name.

On Wed, Sep 20, 2017 at 10:23 PM, Himanshu Singhal hmnsh18@gmail.com
wrote:

Hi Stefan

Sorry for the misunderstanding. I have renamed the function

Originally these functions were ltc_ee_mulmod and ltc_ecc_map

The current configuration I am using is

#define LTC_ECC112
#define LTC__ECC128
#define LTC_ECC160
#define LTC_ECC192
#define LTC_ECC224
#define LTC_ECC256
#define LTC_ECC384
#define LTC_ECC521

/* ECC */
#define LTC_MECC

/* use Shamir's trick for point mul (speeds up signature verification) */
#define LTC_ECC_SHAMIR

/#define LTC_MECC_ACCEL/

/* do we want fixed point ECC /
/#define LTC_MECC_FP */

/#define LTC_ECC_TIMING_RESISTANT/

The size of fp_int I have selected is 4096 bits.

On Wed, Sep 20, 2017 at 10:18 PM, Steffen Jaeckel <
notifications@github.com> wrote:

And what's these functions hsm_sdk_ecc_mulmod and hsm_sdk_ecc_map? Never
heard of them.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/libtom/libtomcrypt/issues/295#issuecomment-330912416,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Aeplj-I37LG9GMbGyPmIGaXL5NAjrPa_ks5skUHCgaJpZM4PeI3p
.

No, I have not changed any thing in the library. Just renamed the variables and functions name. On Wed, Sep 20, 2017 at 10:23 PM, Himanshu Singhal <hmnsh18@gmail.com> wrote: > Hi Stefan > > Sorry for the misunderstanding. I have renamed the function > > Originally these functions were ltc_ee_mulmod and ltc_ecc_map > > The current configuration I am using is > > > > #define LTC_ECC112 > #define LTC__ECC128 > #define LTC_ECC160 > #define LTC_ECC192 > #define LTC_ECC224 > #define LTC_ECC256 > #define LTC_ECC384 > #define LTC_ECC521 > > /* ECC */ > #define LTC_MECC > > /* use Shamir's trick for point mul (speeds up signature verification) */ > #define LTC_ECC_SHAMIR > > /*#define LTC_MECC_ACCEL*/ > > /* do we want fixed point ECC */ > /*#define LTC_MECC_FP */ > > /*#define LTC_ECC_TIMING_RESISTANT*/ > > The size of fp_int I have selected is 4096 bits. > > > > > > > On Wed, Sep 20, 2017 at 10:18 PM, Steffen Jaeckel < > notifications@github.com> wrote: > >> And what's these functions hsm_sdk_ecc_mulmod and hsm_sdk_ecc_map? Never >> heard of them. >> >> — >> You are receiving this because you authored the thread. >> Reply to this email directly, view it on GitHub >> <https://github.com/libtom/libtomcrypt/issues/295#issuecomment-330912416>, >> or mute the thread >> <https://github.com/notifications/unsubscribe-auth/Aeplj-I37LG9GMbGyPmIGaXL5NAjrPa_ks5skUHCgaJpZM4PeI3p> >> . >> > >
sjaeckel commented 2017-09-20 12:02:42 -05:00 (Migrated from github.com)

Just renamed the variables and functions name.

Exactly that's what I meant with "changes in the library".

Can you please either test with the original library or create a diff of the changes?

> Just renamed the variables and functions name. Exactly that's what I meant with "changes in the library". Can you please either test with the original library or create a diff of the changes?
hmnsh18 commented 2017-09-20 12:13:02 -05:00 (Migrated from github.com)

@karel-m
Thank you for the pointer.
I just cloned the branch "pr/ecc-non-asn1-part" and did a quick compare of the ecc files with RC3 branch. It seems to have many changes specially with respect to handling of point at infinity feature.
I will try to merge these changes and give it a try.
I have a one question, if it is a known issue, is there any specific reason why this feature was not considered for 1.18 release?

@sjaeckel
I can do the diff but I believe that will not be useful as it will contain the diff for so many files. I can try the testing with original library but it will take time because from starting only, I tried in my embedded platform. Moreover, if the issue is with respect to renaming of functions and library, RSA would also not have worked. I will give it a try to work with the original files.

@karel-m Thank you for the pointer. I just cloned the branch "pr/ecc-non-asn1-part" and did a quick compare of the ecc files with RC3 branch. It seems to have many changes specially with respect to handling of point at infinity feature. I will try to merge these changes and give it a try. I have a one question, if it is a known issue, is there any specific reason why this feature was not considered for 1.18 release? @sjaeckel I can do the diff but I believe that will not be useful as it will contain the diff for so many files. I can try the testing with original library but it will take time because from starting only, I tried in my embedded platform. Moreover, if the issue is with respect to renaming of functions and library, RSA would also not have worked. I will give it a try to work with the original files.
sjaeckel commented 2017-09-20 12:17:45 -05:00 (Migrated from github.com)

... one question, if it is a known issue, is there any specific reason why this feature was not considered for 1.18 release?

Because this feature will break ABI and API and we wanted 1.18 to be a drop-in replacement for 1.17.

I will give it a try to work with the original files.

good idea!

@karel-m does the issue sound familiar to you?

> ... one question, if it is a known issue, is there any specific reason why this feature was not considered for 1.18 release? Because this feature will break ABI **and** API and we wanted 1.18 to be a drop-in replacement for 1.17. > I will give it a try to work with the original files. good idea! @karel-m does the issue sound familiar to you?
karel-m commented 2017-09-20 12:53:51 -05:00 (Migrated from github.com)

IMO it is #108 (ECC public key validation stucks in ltc_ecc_map) which is fixem in my branch.

@hmnsh18 is there any special reason why you have chosen tomfastmath and not libtommath?

IMO it is #108 (ECC public key validation stucks in ltc_ecc_map) which is fixem in my branch. @hmnsh18 is there any special reason why you have chosen tomfastmath and not libtommath?
hmnsh18 commented 2017-09-20 23:12:17 -05:00 (Migrated from github.com)

Hi Karel,
My intention/requirement is try to avoid dynamic allocation as much as
possible. That is the main reason of going to tom fast math instead of lib
tom math. Also as mentioned in the documentation of tomfastmath,
"

  1. The new code is slightly messier and contains asm blocks.
  2. This uses xed not multiple precision integers.
  3. It is designed only for fast modular exponentiations [e.g. less
    exibility]."
    I found the above points good enough to make a decision to select
    tomfastmath over libtom math. Is there any constraint which I should be
    aware of using tomfast math for ECC functionality? All functionalities are
    supposed to work with tomfastmath right?

"IMO it is #108 https://github.com/libtom/libtomcrypt/issues/108 (ECC
public key validation stucks in ltc_ecc_map) which is fixem in my branch."
Which branch are you talking about here?

Regards
Himanshu

On Wed, Sep 20, 2017 at 11:23 PM, karel-m notifications@github.com wrote:

IMO it is #108 https://github.com/libtom/libtomcrypt/issues/108 (ECC
public key validation stucks in ltc_ecc_map) which is fixem in my branch.

@hmnsh18 https://github.com/hmnsh18 is there any special reason why you
have chosen tomfastmath and not libtommath?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/libtom/libtomcrypt/issues/295#issuecomment-330930196,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Aeplj4GV37mCwN9Sd3AsN0E0JFpsgSZ5ks5skVEzgaJpZM4PeI3p
.

Hi Karel, My intention/requirement is try to avoid dynamic allocation as much as possible. That is the main reason of going to tom fast math instead of lib tom math. Also as mentioned in the documentation of tomfastmath, " 1. The new code is slightly messier and contains asm blocks. 2. This uses xed not multiple precision integers. 3. It is designed only for fast modular exponentiations [e.g. less exibility]." I found the above points good enough to make a decision to select tomfastmath over libtom math. Is there any constraint which I should be aware of using tomfast math for ECC functionality? All functionalities are supposed to work with tomfastmath right? "IMO it is #108 <https://github.com/libtom/libtomcrypt/issues/108> (ECC public key validation stucks in ltc_ecc_map) which is fixem in my branch." Which branch are you talking about here? Regards Himanshu On Wed, Sep 20, 2017 at 11:23 PM, karel-m <notifications@github.com> wrote: > IMO it is #108 <https://github.com/libtom/libtomcrypt/issues/108> (ECC > public key validation stucks in ltc_ecc_map) which is fixem in my branch. > > @hmnsh18 <https://github.com/hmnsh18> is there any special reason why you > have chosen tomfastmath and not libtommath? > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <https://github.com/libtom/libtomcrypt/issues/295#issuecomment-330930196>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/Aeplj4GV37mCwN9Sd3AsN0E0JFpsgSZ5ks5skVEzgaJpZM4PeI3p> > . >
hmnsh18 commented 2017-09-20 23:21:37 -05:00 (Migrated from github.com)

Hi Stefan,

"Because this feature will break ABI and API and we wanted 1.18 to be a
drop-in replacement for 1.17."
I am sorry but I didn't understand the statement. What do you mean by ABI?
If I understand it correctly, you do agree that this ECC feature should be
incorporated but because of compatibility issues it would have with
previous versions, this idea was dropped.

I am not sure how would I be able to send the code snippet because I
haven't written anything new. I am just using the in built test function
"ecc_test" to test the sanity of ECC functionality. I feel that this
function has no platform based dependency. Having said that, if this
function is working at someone's end then I must be doing something wrong.
I wanted to know whether this function has been tested by anyone and if
yes, have they faced the similar type of issue at their end?

Regards
Himanshu

On Thu, Sep 21, 2017 at 9:41 AM, Himanshu Singhal hmnsh18@gmail.com wrote:

Hi Karel,
My intention/requirement is try to avoid dynamic allocation as much as
possible. That is the main reason of going to tom fast math instead of lib
tom math. Also as mentioned in the documentation of tomfastmath,
"

  1. The new code is slightly messier and contains asm blocks.
  2. This uses xed not multiple precision integers.
  3. It is designed only for fast modular exponentiations [e.g. less
    exibility]."
    I found the above points good enough to make a decision to select
    tomfastmath over libtom math. Is there any constraint which I should be
    aware of using tomfast math for ECC functionality? All functionalities are
    supposed to work with tomfastmath right?

"IMO it is #108 https://github.com/libtom/libtomcrypt/issues/108 (ECC
public key validation stucks in ltc_ecc_map) which is fixem in my branch."
Which branch are you talking about here?

Regards
Himanshu

On Wed, Sep 20, 2017 at 11:23 PM, karel-m notifications@github.com
wrote:

IMO it is #108 https://github.com/libtom/libtomcrypt/issues/108 (ECC
public key validation stucks in ltc_ecc_map) which is fixem in my branch.

@hmnsh18 https://github.com/hmnsh18 is there any special reason why
you have chosen tomfastmath and not libtommath?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/libtom/libtomcrypt/issues/295#issuecomment-330930196,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Aeplj4GV37mCwN9Sd3AsN0E0JFpsgSZ5ks5skVEzgaJpZM4PeI3p
.

Hi Stefan, "Because this feature will break ABI *and* API and we wanted 1.18 to be a drop-in replacement for 1.17." I am sorry but I didn't understand the statement. What do you mean by ABI? If I understand it correctly, you do agree that this ECC feature should be incorporated but because of compatibility issues it would have with previous versions, this idea was dropped. I am not sure how would I be able to send the code snippet because I haven't written anything new. I am just using the in built test function *"ecc_test"* to test the sanity of ECC functionality. I feel that this function has no platform based dependency. Having said that, if this function is working at someone's end then I must be doing something wrong. I wanted to know whether this function has been tested by anyone and if yes, have they faced the similar type of issue at their end? Regards Himanshu On Thu, Sep 21, 2017 at 9:41 AM, Himanshu Singhal <hmnsh18@gmail.com> wrote: > Hi Karel, > My intention/requirement is try to avoid dynamic allocation as much as > possible. That is the main reason of going to tom fast math instead of lib > tom math. Also as mentioned in the documentation of tomfastmath, > " > 1. The new code is slightly messier and contains asm blocks. > 2. This uses xed not multiple precision integers. > 3. It is designed only for fast modular exponentiations [e.g. less > exibility]." > I found the above points good enough to make a decision to select > tomfastmath over libtom math. Is there any constraint which I should be > aware of using tomfast math for ECC functionality? All functionalities are > supposed to work with tomfastmath right? > > "IMO it is #108 <https://github.com/libtom/libtomcrypt/issues/108> (ECC > public key validation stucks in ltc_ecc_map) which is fixem in my branch." > Which branch are you talking about here? > > Regards > Himanshu > > > > On Wed, Sep 20, 2017 at 11:23 PM, karel-m <notifications@github.com> > wrote: > >> IMO it is #108 <https://github.com/libtom/libtomcrypt/issues/108> (ECC >> public key validation stucks in ltc_ecc_map) which is fixem in my branch. >> >> @hmnsh18 <https://github.com/hmnsh18> is there any special reason why >> you have chosen tomfastmath and not libtommath? >> >> — >> You are receiving this because you were mentioned. >> Reply to this email directly, view it on GitHub >> <https://github.com/libtom/libtomcrypt/issues/295#issuecomment-330930196>, >> or mute the thread >> <https://github.com/notifications/unsubscribe-auth/Aeplj4GV37mCwN9Sd3AsN0E0JFpsgSZ5ks5skVEzgaJpZM4PeI3p> >> . >> > >
buggywhip commented 2017-09-21 00:20:29 -05:00 (Migrated from github.com)

FWIW, as I scroll all this on my small screen I saw TFM and a key size 4096, max being 2048.

Sent fm iTouch

On Sep 20, 2017, at 9:21 PM, hmnsh18 notifications@github.com wrote:

Hi Stefan,

"Because this feature will break ABI and API and we wanted 1.18 to be a
drop-in replacement for 1.17."
I am sorry but I didn't understand the statement. What do you mean by ABI?
If I understand it correctly, you do agree that this ECC feature should be
incorporated but because of compatibility issues it would have with
previous versions, this idea was dropped.

I am not sure how would I be able to send the code snippet because I
haven't written anything new. I am just using the in built test function
"ecc_test" to test the sanity of ECC functionality. I feel that this
function has no platform based dependency. Having said that, if this
function is working at someone's end then I must be doing something wrong.
I wanted to know whether this function has been tested by anyone and if
yes, have they faced the similar type of issue at their end?

Regards
Himanshu

On Thu, Sep 21, 2017 at 9:41 AM, Himanshu Singhal hmnsh18@gmail.com wrote:

Hi Karel,
My intention/requirement is try to avoid dynamic allocation as much as
possible. That is the main reason of going to tom fast math instead of lib
tom math. Also as mentioned in the documentation of tomfastmath,
"

  1. The new code is slightly messier and contains asm blocks.
  2. This uses xed not multiple precision integers.
  3. It is designed only for fast modular exponentiations [e.g. less
    exibility]."
    I found the above points good enough to make a decision to select
    tomfastmath over libtom math. Is there any constraint which I should be
    aware of using tomfast math for ECC functionality? All functionalities are
    supposed to work with tomfastmath right?

"IMO it is #108 https://github.com/libtom/libtomcrypt/issues/108 (ECC
public key validation stucks in ltc_ecc_map) which is fixem in my branch."
Which branch are you talking about here?

Regards
Himanshu

On Wed, Sep 20, 2017 at 11:23 PM, karel-m notifications@github.com
wrote:

IMO it is #108 https://github.com/libtom/libtomcrypt/issues/108 (ECC
public key validation stucks in ltc_ecc_map) which is fixem in my branch.

@hmnsh18 https://github.com/hmnsh18 is there any special reason why
you have chosen tomfastmath and not libtommath?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/libtom/libtomcrypt/issues/295#issuecomment-330930196,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Aeplj4GV37mCwN9Sd3AsN0E0JFpsgSZ5ks5skVEzgaJpZM4PeI3p
.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

FWIW, as I scroll all this on my small screen I saw TFM and a key size 4096, max being 2048. Sent fm iTouch > On Sep 20, 2017, at 9:21 PM, hmnsh18 <notifications@github.com> wrote: > > Hi Stefan, > > "Because this feature will break ABI *and* API and we wanted 1.18 to be a > drop-in replacement for 1.17." > I am sorry but I didn't understand the statement. What do you mean by ABI? > If I understand it correctly, you do agree that this ECC feature should be > incorporated but because of compatibility issues it would have with > previous versions, this idea was dropped. > > I am not sure how would I be able to send the code snippet because I > haven't written anything new. I am just using the in built test function > *"ecc_test"* to test the sanity of ECC functionality. I feel that this > function has no platform based dependency. Having said that, if this > function is working at someone's end then I must be doing something wrong. > I wanted to know whether this function has been tested by anyone and if > yes, have they faced the similar type of issue at their end? > > Regards > Himanshu > > > On Thu, Sep 21, 2017 at 9:41 AM, Himanshu Singhal <hmnsh18@gmail.com> wrote: > > > Hi Karel, > > My intention/requirement is try to avoid dynamic allocation as much as > > possible. That is the main reason of going to tom fast math instead of lib > > tom math. Also as mentioned in the documentation of tomfastmath, > > " > > 1. The new code is slightly messier and contains asm blocks. > > 2. This uses xed not multiple precision integers. > > 3. It is designed only for fast modular exponentiations [e.g. less > > exibility]." > > I found the above points good enough to make a decision to select > > tomfastmath over libtom math. Is there any constraint which I should be > > aware of using tomfast math for ECC functionality? All functionalities are > > supposed to work with tomfastmath right? > > > > "IMO it is #108 <https://github.com/libtom/libtomcrypt/issues/108> (ECC > > public key validation stucks in ltc_ecc_map) which is fixem in my branch." > > Which branch are you talking about here? > > > > Regards > > Himanshu > > > > > > > > On Wed, Sep 20, 2017 at 11:23 PM, karel-m <notifications@github.com> > > wrote: > > > >> IMO it is #108 <https://github.com/libtom/libtomcrypt/issues/108> (ECC > >> public key validation stucks in ltc_ecc_map) which is fixem in my branch. > >> > >> @hmnsh18 <https://github.com/hmnsh18> is there any special reason why > >> you have chosen tomfastmath and not libtommath? > >> > >> — > >> You are receiving this because you were mentioned. > >> Reply to this email directly, view it on GitHub > >> <https://github.com/libtom/libtomcrypt/issues/295#issuecomment-330930196>, > >> or mute the thread > >> <https://github.com/notifications/unsubscribe-auth/Aeplj4GV37mCwN9Sd3AsN0E0JFpsgSZ5ks5skVEzgaJpZM4PeI3p> > >> . > >> > > > > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub, or mute the thread. >
karel-m commented 2017-09-21 02:39:49 -05:00 (Migrated from github.com)

"IMO it is #108 (ECC public key validation stucks in ltc_ecc_map) which is fixem in my branch."

Which branch are you talking about here?

pr/ecc-non-asn1-part

"Because this feature will break ABI and API and we wanted 1.18 to be a drop-in replacement for 1.17."

I am sorry but I didn't understand the statement.
What do you mean by ABI? If I understand it correctly, you do agree that this ECC feature should be incorporated but because of compatibility issues it would have with previous versions, this idea was dropped.

The thing is that planned ECC enhancements have an impact on backwards compatibility, therefore they were not included in 1.18. When talking about #108 (please read the discussion there) it is fixed in pr/ecc-non-asn1-part but not in planned 1.18, although @sjaeckel wanted to backport the fix I was against as it is IMO a waste of time, because pr/ecc-non-asn1-part is expected to be fine-tuned and merged shortly after 1.18 is released, please read the discussion in #236.

To your other questions:

1/ ecc_test from 1.18 release candidate should pass with both libtomcrypt / tomfastmath (it is regularly tested so please check out your custom modifications).

2/ libtomcrypt libtommath vs. tomfastmath - a trouble you might experience with tomfastmath is max. num size limit (FP_MAX_SIZE is by default 2048 - try to increase it), which you can sometimes hit without any obvious error. I mean you can get CRYPT_OK for some operation which in fact failed and returned a bogus result. IMO libtommath is better choice if you prefer avoiding surprises.

3/ ECC & "point at infinity" - it is unlikely that you hit this issue by running ecc_test, on the other hand this corner case might happen in real life use.

> > "IMO it is #108 (ECC public key validation stucks in ltc_ecc_map) which is fixem in my branch." > Which branch are you talking about here? `pr/ecc-non-asn1-part` > > "Because this feature will break ABI *and* API and we wanted 1.18 to be a drop-in replacement for 1.17." > I am sorry but I didn't understand the statement. > What do you mean by ABI? If I understand it correctly, you do agree that this ECC feature should be incorporated but because of compatibility issues it would have with previous versions, this idea was dropped. The thing is that planned ECC enhancements have an impact on backwards compatibility, therefore they were not included in 1.18. When talking about #108 (please read the discussion there) it is fixed in `pr/ecc-non-asn1-part` but not in planned 1.18, although @sjaeckel wanted to backport the fix I was against as it is IMO a waste of time, because `pr/ecc-non-asn1-part` is expected to be fine-tuned and merged shortly after 1.18 is released, please read the discussion in #236. To your other questions: 1/ `ecc_test` from 1.18 release candidate should pass with both libtomcrypt / tomfastmath (it is regularly tested so please check out your custom modifications). 2/ ~~`libtomcrypt`~~ `libtommath` vs. `tomfastmath` - a trouble you might experience with tomfastmath is max. num size limit (`FP_MAX_SIZE` is by default 2048 - try to increase it), which you can sometimes hit without any obvious error. I mean you can get `CRYPT_OK` for some operation which in fact failed and returned a bogus result. IMO `libtommath` is better choice if you prefer avoiding surprises. 3/ ECC & "point at infinity" - it is unlikely that you hit this issue by running `ecc_test`, on the other hand this corner case might happen in real life use.
sjaeckel commented 2017-09-21 03:51:38 -05:00 (Migrated from github.com)

2/ libtomcrypt vs. tomfastmath - a trouble you might experience with tomfastmath is max. num size limit (FP_MAX_SIZE is by default 2048 - try to increase it), which you can sometimes hit without any obvious error. I mean you can get CRYPT_OK for some operation which in fact failed and returned a bogus result. IMO libtomcrypt is better choice if you prefer avoiding surprises.

a/ I guess you meant libtommath not libtomcrypt.

b/ the 2048 statement is only half correct. The default size of an mpi in tfm is 4096+some margin which allows to do multiplications of up to 2048 bit wide numbers, thereby limiting the size of PK operations to 2048 bits.

> 2/ `libtomcrypt` vs. `tomfastmath` - a trouble you might experience with tomfastmath is max. num size limit (`FP_MAX_SIZE` is by default 2048 - try to increase it), which you can sometimes hit without any obvious error. I mean you can get `CRYPT_OK` for some operation which in fact failed and returned a bogus result. IMO `libtomcrypt` is better choice if you prefer avoiding surprises. a/ I guess you meant `libtommath` not `libtomcrypt`. b/ the 2048 statement is only half correct. The default size of an mpi in tfm is 4096+some margin which allows to do multiplications of up to 2048 bit wide numbers, thereby limiting the size of PK operations to 2048 bits.
karel-m commented 2017-09-21 04:38:28 -05:00 (Migrated from github.com)

I guess you meant libtommath not libtomcrypt.

yes, updated

> I guess you meant libtommath not libtomcrypt. yes, updated
sjaeckel commented 2017-09-26 08:32:10 -05:00 (Migrated from github.com)

@hmnsh18 any update on this?

@hmnsh18 any update on this?
sjaeckel commented 2017-10-03 08:09:01 -05:00 (Migrated from github.com)

Please re-open if you have further questions/comments.

Please re-open if you have further questions/comments.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
develop
archive/20260923T145428Z-rescue/illiliti/static
archive/20260923T145428Z-rescue/afonsojanu/fix/pss-decode-siglen-check
archive/20260923T145428Z-rescue/joshbuddy/win64
pr/pqc1
archive/20260923T151904Z-recovered/pr/pqc1
archive/20260923T151904Z-recovered-3/pr/pqc1
archive/20260923T151904Z-recovered-2/pr/pqc1
archive/20260923T145428Z-rescue/MarekKnapek/serpent-accelerated
pr/sm2
pr/xsalsa20-hsalsa20
no-struct-padding
archive/20260923T145428Z-rescue/tags/actions/runs/24841441691
archive/20260923T145428Z-rescue/tags/actions/runs/24821326727
archive/20260923T145428Z-rescue/tags/actions/runs/24769074231
archive/20260923T145428Z-rescue/tags/actions/runs/24762001029
archive/20260923T145428Z-rescue/tags/actions/runs/24646701081
archive/20260923T145428Z-rescue/tags/actions/runs/24646842340
archive/20260923T145428Z-rescue/tags/actions/runs/24595690628
archive/20260923T145428Z-rescue/tags/actions/runs/24590716227
archive/20260923T145428Z-rescue/tags/actions/runs/24590979385
x509_import
appveyor/sha-ni
ci/develop
debug-wycheproof-failures
turboshake
appveyor/aesni
ci/x509_import
wip/pr/477
remove-prng-registry
pr/macro-LTC_NO_WIN32_BCRYPT
fix-perl-cryptx-99
appveyor/msvc2012
fix-alignment
archive/20260923T145428Z-rescue/assarbad/premake4-vs-project-generation
fix-622
regression-test-for-546
archive/20260923T145428Z-rescue/cntrump/pr_swiftpm_support
timing-benchmark
fix-b64-zero-length-array
openssh-privkey
archive/20260923T145428Z-rescue/FredeJ/visualstudio_solution
travis-test
streams-functions_in_separate_files
streams-enforce-call-policy
pr/autotools
master
feature/gcm_file
feature/eccAddA
v1.18.2
v1.18.1
v1.18.0
v1.18.0-rc5
v1.18.0-rc4
v1.18.0-rc3
v1.18.0-rc2
v1.18.0-rc1
1.17
1.16
1.15
1.14
1.13
1.12
1.11
1.10
1.09
1.08
1.07
1.06
1.05
1.04
1.03
1.02
1.01
1.00
0.99
0.98
0.97b
0.97a
0.97
0.96
0.95
0.94
0.93
0.92
0.91
0.90
0.89
0.88
0.87
0.86
0.85
0.84
0.83
0.82
0.81
0.80
0.79
0.78
0.77
0.76
0.75
Labels
Clear labels   
bug

   
duplicate

   
enhancement

   
feature

   
help wanted

   
improve API

   
invalid

   
needs documentation

   
not-planned
This ticket is not planned to be implemented and/or fixed from the core team.

  
rtfm

   
stale

   
support

   
wishlist
No labels
bug
duplicate
enhancement
feature
help wanted
improve API
invalid
needs documentation
not-planned
rtfm
stale
support
wishlist
Milestone
Clear milestone
No items
No milestone
v1.18.0
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
gh-libtom/libtomcrypt#295
No description provided.