Closed vsoftco closed 4 years ago
Why? OQS_randombytes is needed by implementations within liboqs, but in my mind there's no need for OQS to provide an RNG to consuming applications, who ought to have their own RNG if they need it.
@dstebila What if we want to switch the randombytes algorithm in the wrapper to use e.g. NIST-KAT? That's extremely useful for e.g. testing. So maybe not export all functions in rand.h, but at least the algorithm switching ones?
If you think it's better to keep the rand.h opaque to the liboqs consumers, then I agree, we should not wrap it. The only worry I have now is that currently there's no "direct" way of changing the liboqs PRNg from the wrapper language. We can probably discuss this in more detail during our next meeting.
Ah, good point. I guess we have said that the functions in rand.h
are part of the public API.
Is this something you actually want to do in your tests? Or just hypothetical in case someone wants it? If the latter, then I'd be inclined to wait until someone asks for it. But if you do intend to use it, then go ahead.
@dstebila Not sure at this point, so I think I'll implement them as an "optional" module, outside of the main oqs wrapper
done via PR #19
We should also provide wrapping support for OQS_randombytes etc. from <oqs/rand.h>. I'm currently implementing this for the C++/Go wrappers.