Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for 16-bit processor #23

Closed
johb opened this issue Mar 2, 2015 · 9 comments
Closed

Support for 16-bit processor #23

johb opened this issue Mar 2, 2015 · 9 comments

Comments

@johb
Copy link

johb commented Mar 2, 2015

Hi,

would it be possible to port uECC to an 16 port processor (a MSP430)?

What must be changed in order to achieve this?

@johb
Copy link
Author

johb commented Mar 2, 2015

  • 16 Bit processor

@kmackay
Copy link
Owner

kmackay commented Mar 2, 2015

It is certainly possible. You basically need to add support for
uECC_WORD_SIZE == 2. There are all the #defines and typedefs at the top of
uECC.c that need to be defined correctly, and then there are a few
functions that are word-size-specific. The functions are
omega_mult()/vli_mmod_fast(), vli_nativeToBytes(), and vli_bytesToNative().
You can basically search for uECC_WORD_SIZE in uECC.c to see code that is
word-size-specific.

I recommend implementing asm versions of vli_add(), vli_sub(), vli_mult(),
and vli_square() to significantly improve performance.

Depending on what your timeline is, I can implement the necessary C code
and you can test it on your device. You would need to implement and asm
code since I have no way to test it.

On Mon, Mar 2, 2015 at 12:28 PM, Johannes notifications@github.com wrote:

  • 16 Bit processor


Reply to this email directly or view it on GitHub
#23 (comment).

@johb
Copy link
Author

johb commented Mar 3, 2015

Ok, i implemented the typedefs and the functions for the 160 bit curve based on the implementations for the 8 bit and 32 bit processor.
Sometimes i was not sure what to do- i added TODO at those places.
Can you have a look at it when you have some time? Would be great!

Link: https://github.com/johb/micro-ecc

@kmackay
Copy link
Owner

kmackay commented Mar 4, 2015

Some notes:

  • Yes, wordcount_t is unsigned
  • bitcount_t only needs to be an int16_t (since the largest supported curve
    is 256 bits).
  • uECC_N_WORDS_1 only needs to be 11 (and you can remove the last 0x0000
    from Curve_N_1)
  • Curve_P_3 is incorrect (the last 4 words should be 0x0001, 0x0000,
    0xFFFF, 0xFFFF)
  • In omega_mult(), unsigned or uint16_t are both fine (they should be the
    same on your platform). You should do vli_set(p_result+2, p_right) to
    multiply by 2^32 (since 2 words is 32 bits). Then vli_rshift(p_result + 2)
    to shift back one, and then p_result[1] = p_right[0] << 15 to get the last
    bit. The rest of the function looks fine.
  • Your vli_nativeToBytes() and vli_bytesToNative() look fine, but you have
    a copy-paste error (your vli_bytesToNative() implementation is named
    "vli_nativeToBytes").

On Tue, Mar 3, 2015 at 3:08 PM, Johannes notifications@github.com wrote:

Ok, i implemented the typedefs and the functions for the 160 bit curve
based on the implementations for the 8 bit and 32 bit processor.
Sometimes i was not sure what to do- i added TODO at those places.
Can you have a look at it when you have some time? Would be great!


Reply to this email directly or view it on GitHub
#23 (comment).

@johb
Copy link
Author

johb commented Mar 5, 2015

Ok, thank you.
I changed the things you mentioned. Now I'm testing it and it is always failing (signing and verifying). I used the test example and the fake_generator there.

(Lines are relating to my fork)
Verify fails because v != r (line 2451)

 /* Accept only if v == r. */
    return vli_equal(rx, r)

Sign fails at line 2275:

if(!g_rng((uint8_t *)k, sizeof(k)) || (l_tries++ >= MAX_TRIES))
        {
            return 0;
        }

The code is in the forked repo (I didn't commit the #define PLATFORM etc. macros because I hardcoded them for simplicity, but I think they aren't the reason for failing. I'll later change them.)

Do you have any ideas?

@kmackay
Copy link
Owner

kmackay commented Mar 5, 2015

If you are just using test_ecdsa.c for testing, you need to modify it so
that the fake RNG function is used (in my code it is only used if LPC11XX
is defined). That's probably why the signing is failing.

Your omega_mult() function has an error on line 906; it should be p_result[1]
= p_right[0] << 15;

On Thu, Mar 5, 2015 at 9:04 AM, Johannes notifications@github.com wrote:

Ok, thank you.
I changed the things you mentioned. Now I'm testing it and it is always
failing (signing and verifying). I used the test example and the
fake_generator there.

(Lines are relating to my fork)
Verify fails because v != r (line 2451)

/* Accept only if v == r. */
return vli_equal(rx, r)

Sign fails at line 2275:

if(!g_rng((uint8_t *)k, sizeof(k)) || (l_tries++ >= MAX_TRIES))
{
return 0;
}

The code is in the forked repo (I didn't commit the #define PLATFORM etc.
macros because I hardcoded them for simplicity, but I think they aren't the
reason for failing. I'll later change them.)

Do you have any ideas?


Reply to this email directly or view it on GitHub
#23 (comment).

@johb
Copy link
Author

johb commented Mar 5, 2015

Yeah, that's it!
I changed it to p_result[1]. (I removed the #ifdef LPC11XX already)

But sometimes (1 out of 4) the signing fails. I think that's because of the number_generator?

@kmackay
Copy link
Owner

kmackay commented Mar 6, 2015

Yes, signing only fails if the RNG doesn't generate a good value. I'm kind
of surprised it is failing so frequently though since it tries 16 times
(MAX_TRIES). It is more likely to fail with secp160r1 since even a true
random number generator will only create a good value for k about 50% of
the time. I guess you could try increasing the MAX_TRIES value.

On Thu, Mar 5, 2015 at 9:38 AM, Johannes notifications@github.com wrote:

Yeah, that's it!
I changed it to p_result[1].

But sometimes (1 out of 4) the signing fails. I think that's because of
the number_generator?


Reply to this email directly or view it on GitHub
#23 (comment).

@mervenator
Copy link

mervenator commented Feb 20, 2024

May I ask what happened to the fork that was created? The link to the fork is no longer valid, and I cannot find a 16-bit version of uECC on GitHub either... is the code still available somewhere? Would be great to finish the 16-bit version, and if possible add it to the uECC repo.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants