mirror of
https://github.com/yuzu-emu/mbedtls.git
synced 2024-11-22 12:55:38 +01:00
c9c32f3f63
We want to support alternative software implementations and we extend the ECDH context to enable this. The actual functional change that makes use of the new context is out of scope for this commit. Changing the context breaks the API and therefore it has to be excluded from the default configuration by a compile time flag. We add the compile time flag to the module header instead of `config.h`, because this is not a standalone feature, it only enables adding new implementations in the future. The new context features a union of the individual implementations and a selector that chooses the implementation in use. An alternative is to use an opaque context and function pointers, like for example the PK module does it, but it is more dangerous, error prone and tedious to implement. We leave the group ID and the point format at the top level of the structure, because they are very simple and adding an abstraction layer around them away does not come with any obvious benefit. Other alternatives considered: - Using the module level replacement mechanism in the ECP module. This would have made the use of the replacement feature more difficult and the benefit limited. - Replacing our Montgomery implementations with a new one directly. This would have prevented using Montgomery curves across implementations. (For example use implementation A for Curve448 and implementation B for Curve22519.) Also it would have been inflexible and limited to Montgomery curves. - Encoding the implementation selector and the alternative context in `mbedtls_ecp_point` somehow and rewriting `mbedtls_ecp_mul()` to dispatch between implementations. This would have been a dangerous and ugly hack, and very likely to break legacy applications. - Same as above just with hardcoding the selector and using a compile time option to make the selection. Rejected for the same reasons as above. - Using the PK module to provide to provide an entry point for alternative implementations. Like most of the above options this wouldn't have come with a new compile time option, but conceptually would have been very out of place and would have meant much more work to complete the abstraction around the context. In retrospect: - We could have used the group ID as the selector, but this would have made the code less flexible and only marginally simpler. On the other hand it would have allowed to get rid of the compile time option if a tight integration of the alternative is possible. (It does not seem possible at this point.) - We could have used the same approach we do in this commit to the `mbedtls_ecp_point` structure. Completing the abstraction around this structure would have been a much bigger and much riskier code change with increase in memory footprint, potential decrease in performance and no immediate benefit. |
||
|---|---|---|
| .. | ||
| mbedtls | ||
| .gitignore | ||
| CMakeLists.txt | ||