ktp.next() for keys

[m-temp]

As discussed in https://github.com/lowRISC/ot-sca/pull/115 and https://docs.google.com/document/d/1sZjASiUji_IT-t9jEFlK-kGc_Gw3mGfubNvpkM_IQT4/edit#heading=h.qd65x0y76b0e we should check the usage of key, text = ktp.next() in cw/capture.py

Default behavior is that ktp.next() returns const_key, random_plaintext. This default behavior can be changed with ctx.obj.ktp.fixed_key = False.

Afaik, we call ktp.next()[0] only once per function and use only the first call of the iterator to assign a constant key. For random keys we use ktp.next()[1]. Thus, I think we ware fine and can change the default behavior, but we should double check that and read the spec if the first call of the iterator still outputs a deterministic value. On the other hand, if we really rely on a constant non random value, we should use a constant and not a constant iterator.

[m-temp]

backlog: With ctx.obj.ktp.fixed_key = False the internal lfsr is iterated twice per ktp.next(). This must be taken into account when using the batch-mode and thus, the lfsr on device side.

Possible solutions:

• perform a dummy iteration on the device
• use ktp.next_key() and ktp.next_text() instead of ktp.next()[0] and ktp.next()[1]

[m-temp]

For otbn we are using the second solution. See https://github.com/lowRISC/opentitan/pull/17416 and https://github.com/lowRISC/ot-sca/pull/128 It's running smoothly, while the dummy iteration on the device creates a significant overhead.

[johannheyszl]

The behaviour/use of the host-side PRNG is hard to understand for reasons described here.

Latest host-side batch capture implementation: https://github.com/lowRISC/ot-sca/pull/197 Does not use ktp.next().

PRNG likely replaced in future, hence deprioritizing this issue.