On 1/7/21 11:31 AM, Simon Glass wrote:
Hi Alex,

On Thu, 7 Jan 2021 at 09:44, Alex G. <mr.nuke...@gmail.com> wrote:



On 1/7/21 6:35 AM, Simon Glass wrote:
Hi Alexandru,

On Wed, 30 Dec 2020 at 14:00, Alexandru Gagniuc <mr.nuke...@gmail.com> wrote:

Add a test to make sure that the ECDSA signatures generated by
mkimage can be verified successfully. pyCryptodomex was chosen as the
crypto library because it integrates much better with python code.
Using openssl would have been unnecessarily painful.

Signed-off-by: Alexandru Gagniuc <mr.nuke...@gmail.com>
---
   test/py/tests/test_fit_ecdsa.py | 111 ++++++++++++++++++++++++++++++++
   1 file changed, 111 insertions(+)
   create mode 100644 test/py/tests/test_fit_ecdsa.py


This test looks fine but the functions need full comments. I do think
it might be worth putting the code in test_vboot, particularly when
you get to the sandbox implementation.

test_vboot seems to be testing the bootm command, while with this test

It also runs fit_check_sign to check the signature.

Hmm, it backends on tools/check_fit_sign. Would be an interesting execrise to extend it ecdsa signatures, but that would take significantly more effort than the simple test I am proposing here.

I'm only looking to test the host-side (mkimage). In the next series, I
won't have a software implementation of ECDSA, like RSA_MOD_EXP. I will
use the ROM on the stm32mp. So there won't be somthing testable in the
sandbox.

I'm not sure that is a good idea. With driver model you'll end up
creating a ECDSA driver I suppose, so implementing it for sandbox
should be possible. Is it a complicated algorithm?

A software implementation of ECDSA is outside the scope of my project.

Without that, I'm not even sure how fit_check_sign could work?

It uses the ops->verify in ecdsa-libcrypto, does it not?


[..]

Regards,
Simon

Reply via email to