If creating a key for hybrid cryptosystem, in my understanding the key should just be created from a cryptographic random number generator. Which is much simpler and faster.
If you want to protect data, take a look to ProtectedMemory or ProtectedData. I think to use SecureString to store an array of byte is not the idea of SecureString. And what it the benefit when the content of SecureString is unwrapped a few statements later?
The initialisation vector is part of the key. So I think you disclose information from the key. Instead of the comment "Possibly security critical" it should be fixed or thrown an exception.
I would suggest to use an authenticated encryption (AE) or authenticated encryption with associated data (AEAD) mode for AES. Take a look to System.Security.Cryptography.AesGcm
private readonly static Random local = new Random(GetCryptographicSeed());
private readonly static Random local = new Random(Guid.NewGuid().GetHashCode());
Cryptographic Message Syntax
You are copying some date from one array to get your parameter for your crypto system. Maybe the Cryptographic Message Syntax is something for you, instead of invent your own message syntax.
Using RsaPkcs1
As I know, you shouldn't use PKCS1 to pad the plaintext. You could use Optimal Asymmetric Encryption Padding (OAEP) see RsaOaepSha512
"In principle, usage of this [RSA with PKCS1v1.5 padding] padding format is encouraged neither for encryption nor for signature applications" See "1.4. Handling of legacy algorithms" in BSI TR-02102-1
The nuget package "Capgemini.Cauldron.Cryptography" came to my attention. With around 30k downloads I was curious and did take a look.
I really would like some feedback on my thoughts/ideas.
ZipAsBytes
Why are you try to compress data, that shouldn't be compressible? What do you want to archive?
Same samples:
https://github.com/Capgemini/Cauldron/blob/6a1cf11cbf38d68c18e7bb894d7df7e1d55a25e7/Shared/Cauldron.Cryptography/Aes.cs#L121
https://github.com/Capgemini/Cauldron/blob/6a1cf11cbf38d68c18e7bb894d7df7e1d55a25e7/Shared/Cauldron.Cryptography/KeyMaterial.cs#L59
https://github.com/Capgemini/Cauldron/blob/6a1cf11cbf38d68c18e7bb894d7df7e1d55a25e7/Shared/Cauldron.Cryptography/KeyMaterial.cs#L65
Creating a crypto key
If creating a key for hybrid cryptosystem, in my understanding the key should just be created from a cryptographic random number generator. Which is much simpler and faster.
https://github.com/Capgemini/Cauldron/blob/6a1cf11cbf38d68c18e7bb894d7df7e1d55a25e7/Shared/Cauldron.Cryptography/RsaAes.cs#L113
It would be just simpler to use for salt a cryptographic random number generator too.
https://github.com/Capgemini/Cauldron/blob/6a1cf11cbf38d68c18e7bb894d7df7e1d55a25e7/Shared/Cauldron.Cryptography/KeyMaterial.cs#L121
Use MD5 as standard hash
Why is the unsafe MD5 the standard hash? MD5 is cryptographically broken and unsuitable for further use.
https://github.com/Capgemini/Cauldron/blob/6a1cf11cbf38d68c18e7bb894d7df7e1d55a25e7/Shared/Cauldron.Cryptography/ExtensionsCryptography.cs#L22
Securing a byte array with SecureString
If you want to protect data, take a look to ProtectedMemory or ProtectedData. I think to use SecureString to store an array of byte is not the idea of SecureString. And what it the benefit when the content of SecureString is unwrapped a few statements later?
https://github.com/Capgemini/Cauldron/blob/6a1cf11cbf38d68c18e7bb894d7df7e1d55a25e7/Shared/Cauldron.Cryptography/ExtensionsCryptography.cs#L101
GC
Calling the GC is in most case a bad sign, maybe not here. But I don't how this in combination with OnDispose could help with security.
https://github.com/Capgemini/Cauldron/blob/6a1cf11cbf38d68c18e7bb894d7df7e1d55a25e7/Shared/Cauldron.Cryptography/KeyMaterial.cs#L74
Initialisation Vector
The initialisation vector is part of the key. So I think you disclose information from the key. Instead of the comment "Possibly security critical" it should be fixed or thrown an exception.
https://github.com/Capgemini/Cauldron/blob/6a1cf11cbf38d68c18e7bb894d7df7e1d55a25e7/Shared/Cauldron.Cryptography/KeyMaterial.cs#L60
Magic Numbers
The code would be easier to read if the magic numbers had descriptive variables.
For example:
https://github.com/Capgemini/Cauldron/blob/6a1cf11cbf38d68c18e7bb894d7df7e1d55a25e7/Shared/Cauldron.Cryptography/Aes.cs#L118
https://github.com/Capgemini/Cauldron/blob/6a1cf11cbf38d68c18e7bb894d7df7e1d55a25e7/Shared/Cauldron.Cryptography/RsaAes.cs#L119
Authenticated Encryption
I would suggest to use an authenticated encryption (AE) or authenticated encryption with associated data (AEAD) mode for AES. Take a look to System.Security.Cryptography.AesGcm
https://github.com/Capgemini/Cauldron/blob/6a1cf11cbf38d68c18e7bb894d7df7e1d55a25e7/Shared/Cauldron.Cryptography/Aes.cs#L94
This would break backwards combability but it maybe something for the next major version.
Random
For the Seed for Random you could just use
Guid.NewGuid().GetHashCode(). This would reduce the complexity and you have the same result.https://github.com/Capgemini/Cauldron/blob/6a1cf11cbf38d68c18e7bb894d7df7e1d55a25e7/Shared/Cauldron.Randomizer/Randomizer.cs#L21
Cryptographic Message Syntax
You are copying some date from one array to get your parameter for your crypto system. Maybe the Cryptographic Message Syntax is something for you, instead of invent your own message syntax.
Using RsaPkcs1
As I know, you shouldn't use PKCS1 to pad the plaintext. You could use Optimal Asymmetric Encryption Padding (OAEP) see RsaOaepSha512
"In principle, usage of this [RSA with PKCS1v1.5 padding] padding format is encouraged neither for encryption nor for signature applications" See "1.4. Handling of legacy algorithms" in BSI TR-02102-1