Supporting ChatChaPoly and SymCrypt

Hello,

I am the developer of ovpn-dco-win, the new network driver for OpenVPN. “DCO” stands for “data channel offload”, the driver does encryption/decryption in kernel and eliminates need of transferring packets between user and kernel space, which gives noticeable performance advantage.

At the moment driver support only AES-GCM crypto and uses CNG as crypto library. We would like to support chachapoly as well, but according to CNG documentation and bcrypt.h from SDK 19041, there is no support for chachapoly.

I stumbled across SymCrypt, which claims to be “the core cryptographic function library currently used by Windows”. SymCrypt has support for chachapoly and can be used in kernel mode. However I cannot find any mentioning of SymCrypt on MSFT website nor any documentation / code examples apart from library repository itself.

  • How is SymCrypt related to CNG?
  • Is it feasible to have chachapoly implementation in driver using any of MSFT crypto libraries?
  • If SymCrypt and CNG are different libraries, which one should I use?

I hope other folks who have real, actual, direct experience with SymCrypt will comment here.

The SymCrypt code int the repo doesn’t look to me like it even builds in kernel mode. There’s a comment that says “even though we build with the /kernel switch, does mean we run in kernel mode” — and the sources and dirs seem very user-mode focused. So…

I would recommend you not move from using a well designed, understood, supported kernel mode library to some mess you’d have to roll yourself.

If you really wanted to do this, your best approach would be to write your own crypto algorithm provider for CNG and load that. That’s easier said than done, as the example that MSFT provides in the Crypto Provder SDK is just a skeleton, and pretty much useless.

Peter

I have never heard of SymCrypt before, but I highly doubt that it is the real code used in Windows for anything. In acidemia, peer review and openness is highly valued. In the real world, posting the actual source for crypto algorithms to an open source website is like sending an Enigma machine express post to London and daring the allies to break it. They did break Enigma and captured machines helped a lot

Security by obscurity is no real security, but obscurity is some kind of security. The more effort it takes to find a flaw or exploit, the longer it will take until it will be found - if it ever is. Posting source code clearly decreases the barrier to finding any such flaw dramatically. The skills barrier for working from assembly code to working from C code is probably even bigger than the productivity gap

but I highly doubt that it is the real code used in Windows for anything

Sorry… if you had followed the link in the OP, you would have seen (a) the code is in a MSFT repro, (b) the docs for the code that MSFT provide indicate that the code form the primary basis for their encryption code. My review of their build procedures adds weight to their claim, as the code is clearly designed to be built via “Razzle” the MSFT internal build procedure that also uses sources and dirs files, like the old DDK.

Peter

And I did click the link. And I did read what you read. And I still say that it would be insanity for that to be actually true - but there is quite a bit of insanity floating about at the moment so it might even be true. It is still insanity to publicly distribute any security critical code of any kind.

We will have to agree to disagree, then.

Peter

@MBond2 said:
It is still insanity to publicly distribute any security critical code of any kind.

Security by obscurity is not security, it’s just obscurity.

That doesn’t mean you don’t try to keep secrets, but the code isn’t where the secrets should live.

Not speaking for my employer.

It depends which part is public.
Not making an algorithm public is a recipe for a lawsuit.

Giving out all of the code, on the other hand, I would agree is a bad idea.

And I did click the link. And I did read what you read. And I still say
that it would be insanity for that to be actually true - but there is quite
a bit of insanity floating about at the moment so it might even be true. It
is still insanity to publicly distribute any security critical code of any
kind.

Does every thread this year have to drift wildly?

Peter

Will it get worse if I provide an analogy with an ‘algorithm’ for making steel wool that has been kept secret for 50+ years with no patent? The only sort of think you could be sued for by not filing for a patent and also not divulging trade secrets is anti-trust. The ability to keep those things a secret seems much easier if you only make that steel wool in your basement versus having to interoperate with other systems

Mr. Bond: I JUST warned about thread drift. Your post is not helping the OP. Let’s make some effort to stay topic. Please?

I don’t want to have to start deleting tangential replies. But it DOES just take a single click, which is a lot easier than writing follow-ups like this one, you know?

Peter