Watson,
I don't understand why we are concerned with bad implementers.
because the world is full of implementation errors?
Another might relate to whether things like nonces might
provide a way for borked implementations to leak key bits
and if so, whether there are practical ways for susceptible
protocols to mitigate that, or bits of advice that should
be included in such protocol specs. (And finding some
susceptible protocols would be cool too if CFRG folks were
willing.)
As in leak a key via the bits of an IV? That's not borked but
deliberate. For signing quite a few covert channels are known in
ECDSA. This is rumored to be an issue in the Test Ban Treaty negotiations,
but good luck finding out about that!
In the TBT context the focus was exactly the opposite of what you
suggested, according to my recollection. The parties to the treaty
(the US and the Soviet Union) wanted to make sure that the signed
data being sent didn't have any covert exfiltration capabilities.
The easy countermeasure for some algorithms is to use nonces that are
implicit, incrementing with message number. That way
each peer enforces the algorithm on the other.
Many years ago we explored the issue of using sequence numbers in
ESP in lieu of random IVs. One problem is that, from a security
assurance perspective, the software (or hardware) that manages
sequence numbers is usually outside the perimeter that is evaluated
for crypto alg security. Thus, if one used an ESP sequence number
as an IV, an implementation would not qualify as FIPS 140-x
compliant, unless most (all) of the ESP implementation were part
of the evaluation. That was not desirable side effect of an
implicit IV design. There were other problems, some of which were
IPsec-specific, that also caused us to stick with random IVs. Finally,
for very high speed implementations (hardware) there are some
advantages to allowing a sender to choose it's own approach to IV
generation.
Steve
_______________________________________________
perpass mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/perpass
