Taking #47 further
Facade supporting more than one CryptoProvider per process
( More cheap AI writing ... )
Section: Decoupling CryptoProvider for Greater Flexibility
Introduction to the Change
In a recent update, the internal architecture of the library has seen a significant shift. Previously, a singleton pattern was used for the CryptoProvider via the CryptoImpl class, which was responsible for crypto-related functionalities. Now, the CryptoProvider is passed explicitly to functions and methods that require cryptographic operations, effectively decoupling it from the CryptoImpl class.
Here's a brief overview of what has changed:
The CryptoImpl class has been removed, and its responsibilities are now passed directly to the CryptoProvider.
All key functions and methods that relied on CryptoImpl now require an explicit CryptoProvider argument.
The Oprf class no longer includes a getGroup method tied to CryptoImpl; it's replaced by a function that takes a CryptoProvider.
The Code Changes
The changes in the code reflect this new design philosophy. For example, the getKeySizes function previously had an optional crypto parameter that defaulted to CryptoImpl.provider. Now, it requires an explicit CryptoProvider:
- export function getKeySizes(id: SuiteID, crypto = CryptoImpl.provider): { Nsk: number; Npk: number }
+ export function getKeySizes(id: SuiteID, crypto: CryptoProvider): { Nsk: number; Npk: number }
Similarly, functions like validatePrivateKey, validatePublicKey, randomPrivateKey, and derivePrivateKey now explicitly require a CryptoProvider:
- export async function randomPrivateKey(id: SuiteID, crypto: CryptoProvider = CryptoImpl): Promise<Uint8Array>
+ export async function randomPrivateKey(id: SuiteID, crypto: CryptoProvider): Promise<Uint8Array>
Benefits of the Change
Simplifies Codebase: This approach simplifies the codebase by removing the need for a separate CryptoImpl class to manage the crypto provider.
Enhanced Flexibility: By passing the CryptoProvider explicitly, the internal code now has more flexibility in choosing or even changing the cryptographic backend.
Easier Testing: With the crypto functionalities decoupled from a singleton class, it becomes easier to write unit tests that mock the CryptoProvider.
Forward Compatibility: This change is a step toward supporting multiple crypto providers in a single application without risking inconsistencies.
Considerations
While this approach enhances flexibility, it also makes it the developer's responsibility to manage the CryptoProvider instances correctly. This is not an issue for the facade API, which will serve as the public API and handle these concerns transparently.
Conclusion
By removing the CryptoImpl class and requiring an explicit CryptoProvider, the internal code is now both more flexible and easier to manage. This change is particularly beneficial for future extensions and for developers who wish to use different crypto providers for different tasks.
Taking #47 further Facade supporting more than one CryptoProvider per process
( More cheap AI writing ... )
Section: Decoupling CryptoProvider for Greater Flexibility
Introduction to the Change
In a recent update, the internal architecture of the library has seen a significant shift. Previously, a singleton pattern was used for the
CryptoProvidervia theCryptoImplclass, which was responsible for crypto-related functionalities. Now, theCryptoProvideris passed explicitly to functions and methods that require cryptographic operations, effectively decoupling it from theCryptoImplclass.Here's a brief overview of what has changed:
CryptoImplclass has been removed, and its responsibilities are now passed directly to theCryptoProvider.CryptoImplnow require an explicitCryptoProviderargument.Oprfclass no longer includes agetGroupmethod tied toCryptoImpl; it's replaced by a function that takes aCryptoProvider.The Code Changes
The changes in the code reflect this new design philosophy. For example, the
getKeySizesfunction previously had an optionalcryptoparameter that defaulted toCryptoImpl.provider. Now, it requires an explicitCryptoProvider:Similarly, functions like
validatePrivateKey,validatePublicKey,randomPrivateKey, andderivePrivateKeynow explicitly require aCryptoProvider:Benefits of the Change
Simplifies Codebase: This approach simplifies the codebase by removing the need for a separate
CryptoImplclass to manage the crypto provider.Enhanced Flexibility: By passing the
CryptoProviderexplicitly, the internal code now has more flexibility in choosing or even changing the cryptographic backend.Easier Testing: With the crypto functionalities decoupled from a singleton class, it becomes easier to write unit tests that mock the
CryptoProvider.Forward Compatibility: This change is a step toward supporting multiple crypto providers in a single application without risking inconsistencies.
Considerations
While this approach enhances flexibility, it also makes it the developer's responsibility to manage the
CryptoProviderinstances correctly. This is not an issue for the facade API, which will serve as the public API and handle these concerns transparently.Conclusion
By removing the
CryptoImplclass and requiring an explicitCryptoProvider, the internal code is now both more flexible and easier to manage. This change is particularly beneficial for future extensions and for developers who wish to use different crypto providers for different tasks.