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.t...@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)
