#7390 has been merged, so there is nothing more this is waiting for

@tobhe basically I agree with your proposal. However, I'm not really familiar with that package and just realized there are two tests, whereas one explicitly requires hwrng. Wouldn't that require changes as well? Please elaborate on that. Furthermore, the pkg REAMDE needs adaptation.

Ping @tobhe?

@PeterKietzmann you're right. I think best would be to merge those tests as both can and should work for every device now.
For the readme: I don't think the "Choosing the right API" section is needed any longer, removing it would make it quite a short readme though.

ok, so i stitched the two old tests together and it is still working for me on 'native'.
I saw that in a recent commit @aabadie increased the hwrng test timeout to 200, readjustment may be necessary as the test now signes and verifies twice.

@tobhe thanks for the cleanup.

• I tried running the remaining test application which fails for samr21-xpro and nucleo-l073rz. Ideas? Which boards did you test with?
• I think the documentation of the pkg should still state that ECC_make_key and uECC_sign APIs expect the random module to be seeded with a high entopy, random seed
• The Micro-Ecc documentation states: "The filled-in values should be either truly random, or from a cryptographically-secure PRNG.". I would propose to make the SHA1PRNG a dependency of that package.

I tried running the remaining test application which fails for samr21-xpro and nucleo-l073rz. Ideas? Which boards did you test with?

I have tested this on the nucleo-f411re and on native because that's what i had at hand. Both ran without failures. I guess i could need some help for tests on further hardware here. Any details on what broke on the boards you tested?

I think the documentation of the pkg should still state that ECC_make_key and uECC_sign APIs expect the random module to be seeded with a high entopy, random seed

Right, i will look it up and fix it.

The Micro-Ecc documentation states: "The filled-in values should be either truly random, or from a cryptographically-secure PRNG.". I would propose to make the SHA1PRNG a dependency of that package.

Good idea, will do.

@tobhe thanks for the feedback!

• I got the same error on a nucleo-f411.
• The test fails to generate a key with uECC_make_key 16 times. In there it fails to uECC_generate_random_int.

* I got the same error on a nucleo-f411.

Indeed, i tested it again later yesterday and got the same error.
I also found the source of the problem and I think i may have fixed it, but as I am in Brussels right now i don't have any device at hand for testing

So, I tested it on a nucleo-f103rb and the test succeeds with the latest fix. @PeterKietzmann it would be nice if you could test and see if it works on your hardware now (whenever you find the time). I still want to look through the documentation and the test once more to see if it is consistent with the changes i made. Also I'd like to make the SHA1PRNG a dependency, but I don't know what I have to do to make this work. Is this just a FEATURES_REQUIRED in the Makefile?

@tobhe thanks for addressing. Did you amend your fix? Cause I can't see what the fix was...

I think we need to fix this warning:
micro-ecc/curve-specific.inc:544:59: warning: unused parameter ‘curve’ [-Wunused-parameter]

With boards, the test (make test) succeeds now which is nice! Unfortunately the board crashes afterwards. To see that just use term instead of test.

Same one nucleo-f401rb, nucleo-l073rz and samr21-xpro. Not on native.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

@tobhe will fix this PR before the stalebot closes it?

@tobhe will fix this PR before the stalebot closes it?

Now at least the closing is delayed by another 7 month ;-)

Once again a random ping

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.