Re: Question about cryptography software compatibility on OpenBSD

I agree with Janne. Almost always it is more of a compliance topic than
a technical topic.

I did work for <unnamed org> where we provided crypto/digital signature
stuff to government and institutions I won't name, and e.g. the
constraint for choosing an operating system for a platform was almost
always certification, e.g. at least EAL4 ... certified hardware to
certified software, everything in a chain. So if you are ready to take a
bunch of cash approach a hardware manufacturer and a certification
authority and get your whole platform certified, then you can sell it to
big corps and govs - thats sad, but the way you have to go.

Good luck!


On 15.10.21 11:14, Janne Johansson wrote:
> Den fre 15 okt. 2021 kl 11:01 skrev soko.tica <soko.tica@gmail.com>:
>> Hello list,
>> I have a question about cryptography software compatibility on OpenBSD.
>> I have a wild guess about the answer, but I need it to be more reliable.
>> The target audience are lawyers, since I want to launch a legal battle in
> Then you need lawyer-speak, not answers from technical people.
> Those two overlap very little.
>
>> My wild guess is as follows:
>> 1) OpenBSD includes cryptography capabilities/software in its kernel.
> yes, some.
>
>> 2) Most other operating systems had not included cryptography
>> capabilities/software in its kernel.
> Depends on when "had" is in time. Nowadays, they probably all do.
>
>> 3) Providers of public digital signatures offer software (a
>> one-size-fits-all Java "blob") that should add cryptography capabilities to
>> the operating system.
> No, they don't add it to the OS, they expose crypto functionality to
> other programs. Big difference.
>
> I know of no OS that would reach out to java in order to get crypto
> inside the kernel, and if it's not in the kernel, then any other
> random program would not necessarily pick up that there is a bad/evil
> blob installed somewhere that gives you poor crypto unless it actively
> looks for it, so just by adding java-crypto-something in a folder it
> might not be used by anything else that doesn't specifically ask for
> exactly this.
>
>> 4) OpenBSD doesn't allow such technically inferior software to meddle with
>> its superior cryptography capabilities included in kernel.
> Value added statement, and mostly irrelevant to court cases I guess.
>
>> 5) The proper technical solution would be that providers of public digital
>> signatures offer digital signatures adjusted to OpenBSD technical
>> solutions, including offering software not being under the minimal
>> cryptography standards of OpenBSD. (A side note, hash function of all
>> offered public digital signatures in Serbia are SHA-1.)
>> Am I somewhere wrong in my wild guess?
> Yes, you are assuming too much in the last part.
>
> It is not impossible for other OSes to have
> better,faster,more-formally-verified,more-legal-where-I-am-located
> crypto routines in their OSes which might be a preferred solution
> somewhere.
> While openbsd has the crypto it requires for its needs, those needs
> are not guaranteed to (always) overlap with all the other requirements
> that are set in different places around the world. One example could
> be russian computers wanting certain algorithms like GOST in various
> forms, or US computers needing FIPS-140 validation even if that in
> certain cases lowers the overall security (hard to get fixes and
> patches into such a setup)
>