Hi,
I had a small patch lying around here for some while which properly implements the BCryptGetFipsAlgorithmMode function, behaving identically to the original implementation. Just one question is bugging me, regarding the test. To properly test the function, I'd have to write to a registry key in HKLM\System\CurrentControlSet\Control\Lsa. Is it safe to assume that the test has write access to this key?
Additionally, I noticed I put a small bug in the code, returning false for all registry values which are multiples of 256, which is a result of simply casting a registry DWORD value to a BOOLEAN. To my surprise, the original function - tested with WinXP and Win7 - has the same bug, so I wouldn't fix my implementation before sending in the patch if no one votes against it.
Regards Kai
To properly test the function, I'd have to write to a registry key in HKLM\System\CurrentControlSet\Control\Lsa. Is it safe to assume that the test has write access to this key?
If you need to do something that requires admin privileges, you should try to do it and check for an access denied error. If it fails with access denied, you should skip the test. (Ideally, you should try running your test with a limited account on Windows.)
I would be more worried about the fact that it's changing a global user preference. Maybe you should just read the key and verify that the API matches the value there.
Additionally, I noticed I put a small bug in the code, returning false for all registry values which are multiples of 256, which is a result of simply casting a registry DWORD value to a BOOLEAN. To my surprise, the original function - tested with WinXP and Win7 - has the same bug, so I wouldn't fix my implementation before sending in the patch if no one votes against it.
This is probably more depth than you should be putting into investigating native's behavior. If it's supposed to be a boolean, and the expected values are 1 and 0, you can assume it's one of those and not worry about what happens if it's 256 (unless you know a real application that sets that value).
If you need to do something that requires admin privileges, you should try to do it and check for an access denied error. If it fails with access denied, you should skip the test. (Ideally, you should try running your test with a limited account on Windows.)
Non-admin users lack the proper access rights to change anything in HKLM, so at least on modern systems with active UAC the test won't work.
I would be more worried about the fact that it's changing a global user preference. Maybe you should just read the key and verify that the API matches the value there.
It's worse, to fully test both OS variants, the test would have to delete and create subkeys, since Microsoft put the value under a subkey of the name of the former value since Vista. That's nothing I'd like to do on some unsuspecting user's machine.
This is probably more depth than you should be putting into investigating native's behavior. If it's supposed to be a boolean, and the expected values are 1 and 0, you can assume it's one of those and not worry about what happens if it's 256 (unless you know a real application that sets that value).
Yeah, that's what the documentation states, too. I tested this just out of curiosity.
I'll leave it with my current code for both the implemenation and the test, and submit the patch for reviewing.
On Fri, Sep 19, 2014 at 12:49 PM, Kai Blaschke kai.blaschke@kb-dev.net wrote:
If you need to do something that requires admin privileges, you should
try to do it and check for an access denied error. If it fails with access denied, you should skip the test. (Ideally, you should try running your test with a limited account on Windows.)
Non-admin users lack the proper access rights to change anything in HKLM, so at least on modern systems with active UAC the test won't work.
I would be more worried about the fact that it's changing a global
user preference. Maybe you should just read the key and verify that the API matches the value there.
It's worse, to fully test both OS variants, the test would have to delete and create subkeys, since Microsoft put the value under a subkey of the name of the former value since Vista. That's nothing I'd like to do on some unsuspecting user's machine.
This is probably more depth than you should be putting into
investigating native's behavior. If it's supposed to be a boolean, and the expected values are 1 and 0, you can assume it's one of those and not worry about what happens if it's 256 (unless you know a real application that sets that value).
Yeah, that's what the documentation states, too. I tested this just out of curiosity.
I'll leave it with my current code for both the implemenation and the test, and submit the patch for reviewing.
Kai, out of curiosity, is there an app that depends on being able to enable FIPS mode? --Juan
Kai, out of curiosity, is there an app that depends on being able to enable FIPS mode? --Juan
The only real-life implementation I know about using the flag and actually implementing FIPS is the MS .NET framework. Any application making use of functionality in the System.Security.Cryptography namespace will be limited to algorithms allowed in FIPS if the setting is enabled. You can try this by enabling FIPS on Windows and playing Terraria, for example. In this case, the application depends on FIPS mode being disabled.
Kai
On Tue, Sep 23, 2014 at 2:47 PM, Kai Blaschke kai.blaschke@kb-dev.net wrote:
Kai, out of curiosity, is there an app that depends on being able to
enable FIPS mode? --Juan
The only real-life implementation I know about using the flag and actually implementing FIPS is the MS .NET framework. Any application making use of functionality in the System.Security.Cryptography namespace will be limited to algorithms allowed in FIPS if the setting is enabled. You can try this by enabling FIPS on Windows and playing Terraria, for example. In this case, the application depends on FIPS mode being disabled.
I see. In that case, I think you could just leave it disabled all the time, no? I don't see any sense in pretending to enable FIPS mode, personally. --Juan
-
Juan Lang -
Kai Blaschke -
Vincent Povirk