|P is for Practical|
No, but if you have requirements that you need to meet as well (customer only uses MS products, legal will not allow anything with GNU in it, key size limitations, implementation limitations (netscape and poor initial seed selection, anyone?), strength of cipher used, and so on), then those should be evaluated first, or at least balanced with the desire to use the XYZ API.
A problem being well understood does not preclude a solution from having flaws in either design or implementation, nor does it preclude other requirements from limiting your solution set. If you have no requirements other than that0 you can transform it into and out of a secure1 form, then ignore my post.
That is all that I am saying.
1 - any definition of "secure" brings along with it other baggage, which I would also consider as requrements.
(minor) 0 - Added missing word.