Please don't add my e-mail address in replying, I am subscribed to @misc (for more than a decade).
On Fri, Oct 15, 2021 at 11:14 AM Janne Johansson <[email protected]> wrote: > Den fre 15 okt. 2021 kl 11:01 skrev soko.tica <[email protected]>: > > 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. > > Please let me worry about the lawyer-speak. All I need is to properly understand what I am telling to other lawyers (more precisely, to Judges of Constitutional Court of Serbia). > > 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. > Thanks, but it is not of essential importance. Consider this "historical" part closed. > > 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. > > This is important. Thank you. Let me rephrase my wild guess: 3.1) An OS (OpenBSD or other) may have cryptography capabilities included in the kernel. 3.2) An OS that doesn't have cryptography capabilities included in the kernel may provide cryptography software, not being included in the kernel, fit and apt for use on the specific OS. 3.3) Forcing the blind use of proprietary java-crypto-one_size_fits_all-blob is technically possible, but it is a bad practice since: 3.3.1) it may downgrade crypto functionality existing in an OS as described under 3.1 and 3.2 3.3.2) it may compromise and expose to the attacks not only the digital signature, but the operating system itself 3.3.3) for a number of other reasons (updates, licensing issues, etc.) > > 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. > Again, let me worry about the lawyer-speak. Please. > > > 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) > Many thanks for this. How should I define that there is a need for completely inter-operable digital signatures? The ones that comply with the applicable standards, but completely free from imposition of any particular software of any specific software-producer? > -- > May the most significant bit of your life be positive. >
