[mdriley]

"EncryptData"

https://github.com/microsoft/omi/blob/e4d72481fa2f805148c9c8...

[isoprophlex]

This can't be real, I thought. This is just a stub in a random commit somewhere.

But no. Same code is on master branch atm.

What is this, a joke?

"Never attribute to humor, that which is adequately explained by incompetence"

[watermelon0]

At least it's fast. :D

[jamesfinlayson]

And properly SAL annotated too.

[haimez]

An encryption scheme with truly memcpy-like performance characteristics.

[cube00]

Let's hope memcpy hasn't been #defined

[dspillett]

I'm going to give some benefit of the doubt and assume¹ that is some sort of stub for dev/test, replaced by one of a selection of proper symmetric encryption options in any production use. Amusing anyway.

¹ Anyone with more spare time than I want to look deeper to confirm or contradict?

[formerly_proven]

It's used there: https://github.com/microsoft/omi/blob/e4d72481fa2f805148c9c8...

Also note that neither EncryptData nor DecryptData have any way of passing a key in their API. So it's very unlikely that these implementations could be conditionally compiled in place of a real implementation (but they're the only definition of these functions in the repository anyway).

[mulander]

It used to have actual Windows specific crypto code[1] which has been removed in the linked commit.

I assume this has been ported from Windows and later never implemented the ripped out components. That said, I don't know the windows API so apart from confirming that they exist in Windows docs[2] I can't assess how valid their usage was.

[1] - https://github.com/microsoft/omi/commit/edbe231042173018c529...

[2] - https://docs.microsoft.com/en-us/windows/win32/api/dpapi/nf-...

[dspillett]

> neither EncryptData nor DecryptData have any way of passing a key

There could have been other smells involved, like the key being held in some more global scope instead of being passed in via the call stack.