Open m-temp opened 1 year ago
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:
ktp.next_key()
and ktp.next_text()
instead of ktp.next()[0]
and ktp.next()[1]
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.
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.
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()
incw/capture.py
Default behavior is that
ktp.next()
returnsconst_key, random_plaintext
. This default behavior can be changed withctx.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 usektp.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.