Ticket #406 (closed defect: fixed)

Opened 3 years ago

Last modified 3 years ago

Not able to acquire a Cryptographic Service Provider on startup

Reported by: UveLokk Owned by: Joel
Priority: critical Milestone: Eraser 6.0.10
Component: Core Version:
Keywords: Cc:
Processor Architecture: i386 (32-bit) Blocked By:
Blocking: Operating System: Windows 7


Eraser crashes if "System cryptography: Use FIPS compliant algorithms for encryption, hashing and signing" in Local Security Settings is set to "Enabled".

Change History

comment:1 Changed 3 years ago by UveLokk

akismet didn't like that part:

Tested with Windows 7 Professional SP1 (32-bit) and Windows XP Professional SP3 (32-bit).

comment:2 Changed 3 years ago by Joel

This is indeed very interesting. This could be the cause of the weird Crypto API crashes I'm seeing. Let me go play it out in my test lab and see what I can come up with.

Thanks for reporting.

comment:3 Changed 3 years ago by Joel

  • Priority changed from major to critical
  • Milestone set to Eraser 6.0.10

comment:4 Changed 3 years ago by Joel

  • Owner set to Joel
  • Status changed from new to accepted
  • Summary changed from Eraser Crash & FIPS to Not able to acquire a Cryptographic Service Provider on startup

A similar problem affects the Guest user account (see the forum). I'll change this to be a little more generic.

comment:6 Changed 3 years ago by Joel

The situation with Windows XP and Windows 7 is slightly different. In the XP case, I've fixed it in r2563 (with accompanying behavioural change) for Eraser 6.0. I'll run the same test on Windows 7 now.

Eraser 6.2 would need a different set of changes so I'll get to that later.

Last edited 3 years ago by Joel (previous) (diff)

comment:7 Changed 3 years ago by Joel

As part of the changes made to the codebase to fix this bug, I went back to review the Crypto API documentation on MSDN. It turns out that we are calling CryptAcquireContext wrongly, which could have triggered the guest accounts not being able to run Eraser as well as the other spurious crashes at start up (see #comment:5)

I've fixed this in r2564 for Eraser 6.0.

comment:8 Changed 3 years ago by Joel

r2566 saw changes to the Eraser 6.2 codebase, ported from Eraser 6.0. There will be a few behavioural changes, however. I'll document them as I write the code.

In r2566:

  • The sleep time between polls is now variable between 2 and 5 seconds. The previous one tended to pick the same amounts of time since it would effectively make one loop double the time it took to gather entropy from all entropy sources.
  • Only push entropy to the PRNGs every 10 minutes

comment:9 Changed 3 years ago by Joel

r2567-r2568 saw some major fixes to the Entropy Poller.

  • Fixed the circular buffer which is the pool: the previous code always wrote new entropy to the start of the pool.
  • Every time the entropy pool wraps, mix the pool so that previous entropy is not wasted.
  • Fixed entropy poller registration: The plugins rewrite broke entropy source and entropy poller integration.
  • Rewrote the MixPool routine to use max/min instead of repeated ternary operators for clarity.

comment:10 Changed 3 years ago by Joel

  • Status changed from accepted to closed
  • Resolution set to fixed

r2569-r2571 added some performance improvements, especially for 64-bit platforms, for pool mixing and inversion (which is used when the circular buffer of the pool wraps around, and when snapshot of the pool is required respectively)

r2572 added support for lists of hash algorithms to be used in order of security/speed. This allows different systems to pick the most optimised hash algorithm available for the system. This allows the best combination of speed/security and FIPS compliance support. (Windows XP will fall back to the SHA1 Crypto API implementation, where as Vista+ will use the SHA512 CNG implementation)

Note: See TracTickets for help on using tickets.