Thank you Janne. On Fri, Oct 15, 2021 at 3:57 PM Janne Johansson <[email protected]> wrote:
> > > > 3) Providers of public digital signatures offer software (a > > > > one-size-fits-all Java “blob”) that should add cryptography > capabilities > > > to > > > > the operating system. > > > > > > > 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. > > Yes. > > > 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. > > This is where you seem to be missing that LOTS AND LOTS of programs use > crypto from external libraries. > They call openssl, they use NSS/NSPR, programs link against > gnutls, java code use java libs, go code use go crypto and so on. > > > 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.) > > Those last subpoints work both ways. > > A brought-along crypto primitive can be controlled by > the person installing the program in ways you can't with the OS, > so it is, like so much else, a tradeoff. If you don't control the OS and > what > crypto primitives it has, bringing along your own might be "safer" than to > trust some OS to have a stable interface forever and ever. > > > -- > May the most significant bit of your life be positive. >
