Simulation does not work

[wwwweb]

The simulation of ecc_tb currently (v1.4.6, commit 7778) does fail but does partly work in a previous commit (see below).

First, the nbopcodes in ecc_configure has to be set to 1024 as the current code produces more than 512 RAM entries.

Changing nothing more in the source code except for above and configuring ecc_vec_in stimuli file, the following is observed

• with the checked-in sim/ecc_vec_in.txt (nn=21), returned error is that the point lies not on curve
• with some generated nn=256/384/512 stimuli, the point lies on curve but the oucome is not the expected outcome (assertion is raised).

Tested also with nn_dynamic set to false and the according nn values.

The last commit that the sim with n=21 is working for me is 13dc (the one before version 1.4.0). There, also the nbopcodes does not need to be changed. But this commit fails for nn=256 with R_STATUS shows STATUS_ERR_UNKNOWN_REG and mismatch on point coordinates.

Using QuestaSim 2023 and compile without VHDL 2008 option.

(Not tested synthesis yet as I am new to the project and first want to get sim running.)

[kkhalfallah]

Dear "wwwweb", Thanks for your interest in IPECC.

1. For the nn = 21 case : I have recently made change to the code of the Montgomery multipliers that makes them no longer support the small values of nn (values such that numbers manipulated inside the IP count only two ww-bit limbs) although the documentation still says that they are supported, and altough I still use a small default test vector in ecc_vec_in.txt so as to provide the user of the IP a fast first simulation... Hence, I will either change the specification of the IP, or try to fix the bug (I have simulated again right now and I confirm you that there are errors in the Montgomery multipliers with small values such as nn=21).
2. Regarding numbers of cryptographic sizes (nn = 256/384/512). Did you generate your test vectors using the script generate-tests.sage ? (folder sage/ of the repository). If this is the case, please check the value of parameter named NN_LIMIT_COMPUTE_Q (there is a small paragraph underneath the definition of the parameter that explains its purpose, I would encourage you to read it). By default this parameter is set to 64 which means that for nn > 64, the value of parameter q (order of the curve) generated by the script is deliberately wrong (set to 1). This is for performance reason during our automatic runtime tests... :| Now, the problem is that in the default version of ecc_customize.vhd, we set blinding = 96 to encourage hardware security, and furthermore (and for the same reason) parameter hwsecure is set to TRUE, meaning the countermeasures set in ecc_customize.vhd cannot be altered at runtime (or during simulation in your case). In brief, it is likely that you are simulating a [k]P computation with scalar blinding forced on, but with a wrong order (of value 1) of the curve. Obviously in this case the result can't be right. And at the same time it would explain why the output point is still on the curve even though it does not correspond to what is expected from the test vector file (because, according to what you're telling me, the IP does not reject you with a message "output point is not on the curve"). Now if this is actually the situation, you can:

• either set blinding = 0 in ecc_customize.vhd
• or set hwsecure to FALSE in ecc_customize.vhd and force nbbld=0 in the test-vector (there's also a boolean parameter named only_kp_and_no_blinding in generate-tests.sage that might be of interest)
• or increase the value of NN_LIMIT_COMPUTE_Q in generate-tests.sage (make it e.g 600 for a comfortable margin) if you don't need to generate too many test vectors or you're not afraid of waiting too long for Sage to compute the order of your test curves. The time it takes Sage to compute the order of a 512-bit curve on my machine is approx. half of a minute.

Please let me know it this helps!

Best regards, Karim

[kkhalfallah]

And besides, thanks for mentioning the 1024 opcodes situation... I was aware of it and intend to fix it in a new release very soon.

[kkhalfallah]

You're using QuestaSim : does it mean you intend to target an Intel-Altera device?

[wwwweb]

Thanks for your response! Yes, I am using sage according to your documentation. I now tried with NN_LIMIT_COMPUTE=600, nn=256 and sim is currently running beyond the point it exited before. I should have read the doc more carefully. What is the smallest nn that is supposed to work currently (would be useful to have a minimum length sim for fast IP evaluation)?

As the checked-in sage-configuration does not work with the checked-in ecc_customize, it might be a good idea to mention it in the doc or to check-in a consistent state. In any case, a warning from the sage script would be nice, if NN_LIMIT_COMPUTE < nn. This might avoid confusion from more newbies like me who like to use things out-of-the-box and may categorize that under "nice idea but doesn't work" if it, well, doesn't work :-) .

Maybe you can replace the checked-in nn=21 ecc_vec_in by some working version with greater nn; maybe even files for different greater common nn as it takes some time to generate these stimuli as you wrote. This would give fast confidence by a smoke test sim, that it works in general (which was your intention for the nn=21 stimuli as I understand). And it does not force the user to install sage for this first test. (I personally never used sage before and it took me some time to get it running as it is not part of current Ubuntu LTS version due to former missing python 3.12 support; so it needs to be installed in other awkward Unix ways.)

To not only complain, I have to say, the project looks to be in a good state. The vhd sources are well commented, sim output is pleasingly verbose and the pdf doc is detailed. Thanks for your effort!

I target a Xilinx US+. Only using QuestaSim as this expensive license is lying around and needs to be used.

[kkhalfallah]

Hi,

You're absolutely right in everything you said, and I intend to take in account your remarks as they all seem pertinent to me.

1/ First, to answer your question, the smallest value of nn for which [k]P computation will work as it is is nn = 29, but that depends of your configuration or more precisely it depends on the value of the parameter ww which is used throughout the RTL code. By definition ww is the bitwidth of the limbs of large numbers as they fit in the IP's internal memory of large numbers (ecc_fp_dram.vhd). ww also matches the bitwidth of the input operands to the multipliers inside the design. Parameter ww is not really customizable, rather I derivate it from the technology. This is done by function set_ww() in ecc_utils.vhd. For Xilinx 7-series & UltraScale devices, multipliers offer a max 17-bit input, so I could have set ww = 17 but for the sake of simulation readability I chose ww = 16 instead. Now in present code release, the IP will work for large numbers of at least 3 limbs (however it's supposed to work with 2 limbs, this is the bug and I intend to fix it very soon as I'm currently working on it). Knowing that the number of limbs of large numbers is given by (see doc ipecc.pdf pp. 87-88) w = ceil( (nn + 4) / ww), this explains the value of 29 I gave you just above (this is the first value of nn for which w = 3).

2/ Now I could change the specification of the IP and publish that it only supports configs for which w >= 3 but that would be taking the lazy path (although it's not always the worst one to take :) ), and actually not only I would like to support the w = 2 situation back again, but also I plan to support the w = 1 situation one day. This way the IP would act like a true "cryptographic oracle", supporting any hardware configuration set by user.

3/ What I'm gonna do in the immediate is to set a 29-bit test vector as default. I will also set a default value of NN_LIMIT_COMPUTE_Q to 0 and define it as meaning "no-limit on nn to compute the order of curve".

May I be as bold as to ask you the context of your interest in the IP? Are you an academic or an engineer? Are you targeting a product or is it for a PhD thesis or similar research work? Obviously I understand that using a cryptographic implementation can reflect a sensitive context, so in this case ignore the question and simply forget I asked :-)

Best regards, Karim

[wwwweb]

Thanks again.

Regarding my context, I write you an email to the address mentioned in README.