Использование криптографического API и реверс-инжиниринг программного обеспечения

Я столкнулся с дилеммой, когда вклад людей с большим опытом в этой области был бы очень ценным. Рассматривая настольное программное обеспечение, которое должно выполнять некоторые общие криптографические задачи, такие как AES и проверка цифровой подписи, — каковы компромиссы между использованием библиотеки с открытым исходным кодом, такой как crypto ++, против собственных API в каждой ОС? Вещи, которые волнуют меня:

• Возможность взломать программное обеспечение. В ситуации, когда кто-то захочет перепроектировать / взломать программные вызовы ОС, будет намного легче отследить, таким образом, злоумышленник сможет быстрее определить места в коде, где происходят какие-либо криптографические вещи, и получить отправную точку для проверки сборки. Принимая во внимание, что использование криптографических библиотек с открытым исходным кодом, если бы код был встроен, было бы сложнее обнаружить. С другой стороны, скорее всего, злоумышленник может исправить код где-то еще, чтобы замкнуть путь, который выполняет любые проверки и т. Д., Так что, возможно, это не имеет значения.
• Недавно выявленное предотвращение угроз. Любые недостатки безопасности в алгоритмах будут направлены на обновления ОС (в случае использования нативного API), когда, как и в случае библиотек с открытым исходным кодом, потребуется новый выпуск программного обеспечения, а в худшем случае это может занять больше времени для сопровождающего. библиотека для обновления, чем для обновления ОС.

Может быть, есть другие важные аспекты при принятии этого решения?