I am new to cryptography. I want to encrypt the connection string section and some other section in the web.config. I know this can be accomplished using RSACryptoServiceProvider.
But I am not sure about the Key which is being used by the default RSACryptoServiceProvider and the key size.
As per our organization security policy the key size should be 196 bit and we have to share the Key with security team which is used for encryption.
When we use the default encryption what will be key used internally by asp.net for encryption/decryption and the key size?
In-order to use a custom key which can be shared with security team do we need to create a custom class by inhering RSACryptoServiceProvider?
Also RSA Key Container is bit confusing. Is it a container for the Key or the Key itself
Please advice.
RSA key container files which are exported from aspnet_regiis.exe are indeed containers for the key. They are XML files. Actually, as RSA is public key crypto, the key container holds both the public key and private key (if you export both).
When you perform web.config or app.config encryption via aspnet_regiis.exe, and you do not specify a provider, it will use the value of "defaultProvider". See http://msdn.microsoft.com/en-us/library/zhhddkxy(v=vs.100).aspx. The encrypted output will list the provider name (so that you know how to decrypt it). It appears the default name of the default provider is "RsaProtectedConfigurationProvider". That crypto provider uses a key. The default key has a default name of "NetFrameworkConfigurationKey" (see http://blogs.msdn.com/b/mosharaf/archive/2005/11/17/protectedconfiguration.aspx). The key with that name will have a different value on every machine and is generated when .NET is installed.
A key length of 196 bits sounds like your security team expects you to be performing symmetric key encryption (not asymmetric PKC) of some sort. For example, people brag about their AES key lengths being 256 bits. The .NET 4.0 aspnet_regiis.exe command for creating a custom RSA crypto provider and key use a key size of 2048 bits (although 1024 is not uncommon from days of yore). I imagine the default RSA provider and default key use default values for key lengths. But to be sure, you might want to export the default key, and inspect it yourself. The -pc and -px switches and their associated options (like -size) are documented at http://msdn.microsoft.com/en-us/library/vstudio/k6h9cz8h(v=vs.100).aspx.
If you need to be very specific about a private key, which would be durable beyond a machine reimaging, and would be used by many nodes in a server farm, and which needs to be held in escrow by the security team, you probably want to invest the time in creating a non-default crypto provider of the RsaProtectedConfigurationProvider type (not inventing your own CSP class as an alternative to RsaProtectedConfigurationProvider).
One last thing to note, web.config XML encryption is performed in a multi step process. First, the encryption process generates a random symmetric key (which is short in comparison to an RSA key) which will be used to encrypt a plaintext corpus. The plaintext is encrypted with the symmetric key (after the corpus is normalized for whitespace, etc). Then, the symmetric key (which is short compared to the corpus) is encrypted using an RSA public key. If the whole plaintext corpus was encrypted with an RSA public key, it would take a long time to decrypt. So when you look at a block of encrypted XML in a web.config encrypted you will really see two things: an encrypted key section, and an encrypted data section. To decrypt the ciphertext, ASP.NET needs to first decrypt the encrypted symmetric key, and then use the decrypted key to decrypt the stuff you actually want as plaintext.
There is an example of the two-levels of encryption at "Problem with decrypting xml document". What is apparent (and perhaps troubling), is that the RSA crypto provider uses Triple DES in CBC mode for the symmetric crypto algorithm underlying the RSA PKC which you think is really providing the encryption. See this person's frustration around trying to change the symmetric algorithm to AES, for example, Change Microsoft Config File Encryption Method From TripleDES. Triple DES is only recommended for use until 2030 in very ideal scenarios (see http://en.wikipedia.org/wiki/Triple_DES#Security) by the algorithm's endorsers (NIST). NIST had a bake-off years ago for a replacement symmetric algorithm suite, which they have chosen and endorsed as AES (http://en.wikipedia.org/wiki/Advanced_Encryption_Standard). So to use AES-192 or AES-256, you would need to invent your own CSP class as an alternative to RsaProtectedConfigurationProvider, then make it available for creating providers and performing encrypt/decrypt operations from ASP.NET.
Here is another stack-overflow article which is relevant: ASP.NET Encryption - aspnet_regiis - Farm.
Here is a guide to creating/exporting RSA crypto providers and keys for spreading around in a farm, for example: http://msdn.microsoft.com/en-us/library/2w117ede(v=vs.100).aspx
Related
Problem
I want to sign and encrypt (effectively, obfuscate) some information ('token') on my server (a trusted environment) and send the cyphertext to a client machine (not quite trusted environment) to be read and verified by my client-side software. This type of the environment allows me to have a private key on the server for asymmetric signing, but I cannot 'hide' a secret key for symmetric signing on a client side.
Alternatives
I chose to use JWT as a standard and Nimbus JOSE+JWT library as an implementation for signing and encryption. Nimbus library provides two options for sign + encrypt: nest JWS into JWE or use JWE with authenticated encryption algorithm (A128CBC_HS256, A192CBC_HS384, or A256CBC_HS512). Algorithm Selection Guide for Nimbus states:
Encryption in JOSE is always authenticated, meaning that ciphertext’s integrity is protected from tampering. Authenticated encryption thus makes nesting an HMAC JWT inside a JSON Web Encryption (JWE) redundant; use just JWE encryption.
However, AxxxCBC_HSxxx encryption methods use only symmetric keys. Additionally, replacing direct JWE algorithm with RSA JWE algorithm should not help, because an abuser can generate CEK (consisting of encryption key and key for HMAC) themselves and encrypt it with a public key.
Question
Despite the quote about the redundancy of nested JWTs, I concluded, that for my case JWE+JWS nesting is the only workable approach. Am I right?
Clarifications
Every content encryption algorithms (AxxxGCM and AxxxCBC_HSxxx) use a symmetric key (CEK). This key is determined by the key encryption algorithm and its key management mode (random CEK, key agreement, direct key...).
You are right, contrary to the AxxxGCM algorithms, the AxxxCBC algorithms are not authenticated encryption algorithms.
However, the RFC7516 section 5.1 item 15. (specification for JWE) introduces a tag that allows to authenticate the cyphertext and protect the integrity of the protected header (that is why the AxxxCBC algorithm is used with the HSxxx).
This is confirmed by the table in the RFC7518 section 5.1. Details are given in the next section.
In any case, you will need 2 algorithms for JWE computation:
The key encryption algorithm: you mentioned you have an asymmetric key so I guess you will chose an RSA or an ECDH-ES algorithm depending on your key type.
The content encryption key: AxxxGCM or AxxxCBC_HSxxx algorithms. With the JWE specification both offer an authenticated encryption. Personally I prefer AxxxGCM algorithms because they are faster in my environment.
Answer
You indicated that you want sign and encrypt but you cannot hide a secret key on client side thus the signature will not be guaranteed.
If you only encrypt (JWE only), your server will not be able to verify the issuer of the token.
I need a way to allow multiple people encrypting various files but only one party been able to read them all. I wrote a program in Go by following various online examples but at some point I got the following error:
Error from encryption: crypto/rsa: message too long for RSA public key size
Is RSA the wrong way to go? Is it ok if I break the file into multiple chunks and encrypt them? Is there an asymmetric block cipher that I can easily use?
I read the discussion here and it is said that RSA is not the proper way to go.
Can you also provide with an example?
If you need public key asymmetric encryption for data larger than the key size you need to use hybrid encryption. Essentially this is how HTTPS works.
Hybrid encryption is where the data is encrypted with symmetric key encryption such as AES and that key is encrypted with asymmetric key encryption such as RSA or EC (Elliptic Curve) Cryptography.
Do not break the file into multiple chunks and encrypt them.
So I ended up using GPG and my service has one unique private key and I share the public one with my users.
I would like to use RSA encryption on a large file (>25 MB).
Is it possible or are there limitations using a Public Key/Private Key for a large app?
I am exposing a public key to clients and not allowing anyone but the recipient to view the contents with the private key. So the business case makes sense although it will be slower than symmetrical encryption.
Thanks,
RSA cannot encrypt a payload larger than its key size (minus some overhead for padding). To bypass this limitation you'll need to generate a symmetric key, use that to encrypt the larger file, then encrypt the symmetric key itself with RSA (with OAEP or PKCS1v1.5 padding).
Cryptographic Message Syntax (CMS) and PKCS7 (CMS's predecessor) support this use case already so there's no need to invent your own protocol.
I am planning on file encryption during file transfer from physical storage to physical storage as my final year project at my high school.
My question is, can AES Encryption and RSA Digital Signature Scheme be used as file encryption? Currently I am focusing on text files (.doc, .txt).
I've got the following protocol in mind:
the file will be encrypted using AES Encryption
the private key from RSA Encryption will be the signature for the file
the public key will verifies the signature during decryption
I am not sure about the bit sizes of the keys to use, either 256 bit AES and 1024 bit RSA.
Most of the time AES and RSA are used together in the following way:
create an asymmetric key pair and keep the private key confidential and the public key in a trusted keystore
create a symmetric data encryption key and encrypt the data with it (e.g. using AES-CBC and a random IV)
encrypt the symmetric data encryption key using the public key of the key pair
create a signature with a private key (if possible, using a separate key pair), using e.g. PKCS#1 using the SHA-256 hash algorithm
store the encrypted data (+IV), the encrypted key and the signature
To verify
retrieve the data etc.
verify the signature using the public key from the trust store
decrypt the symmetric key using the private key (protected by a password, stored on an USB stick or smart card etc)
decrypt the data
You will need some way to store the data. It's best to use a common format for this such as Cryptographic Message Syntax. For key sizes see http://www.keylength.com/ e.g. using the NIST or ECRYPT II recommendations. I would suggest matching sizes, e.g. AES-128 bits, RSA 3072 bits and SHA-256 for the signature.
I need to implemented security for client-server communication. I have implemented the following hybrid cryptosystem
To encrypt a message addressed to Alice in a hybrid cryptosystem, Bob does the following:
Obtains Alice's public key.
Generates a fresh symmetric key for the data encapsulation scheme.
Encrypts the message under the data encapsulation scheme, using the symmetric key just generated.
Encrypt the symmetric key under the key encapsulation scheme, using Alice's public key.
Send both of these encryptions to Alice.
To decrypt this hybrid ciphertext, Alice does the following:
uses her private key to decrypt the symmetric key contained in the key encapsulation segment.
uses this symmetric key to decrypt the message contained in the data encapsulation segment.
I am using RSA For a public-key cryptosystem, and AES for symmetric-key cryptosystem. Every thing works fine, but I am not sure how to handle AES initialization vector. Currently, I am concatenating the AES key and initialization vector encrypting it with the public key and sending that to server.
I just wanted to get some opinions about this approach. How this problem is solved by other communication protocols SSL etc.
Thanks.
You don't encrypt the IV. Bundle it with the encrypted key and send it (in the clear) to the recipient.
Standards for this do exist. This scheme is called "KeyTransRecipientInfo" in CMS (upon which S/MIME is based), and PGP offers a similar mode. TLS also includes the initialization vector as a parameter in the key encryption algorithm identifier, using the same ASN.1 syntax as CMS. A robust, open-source library to perform this operation is available for many, many platforms.
At the very least, studying the CMS specification might help avoid some of the many pitfalls in a home-brew implementation. See §6.1 and §6.2.1 of RFC 3369.
I've done the same thing, and I handled it the same way - concatenate the AES key with the IV and encrypt them both.
You could also just send the key and use the key itself to generate an IV - for example by using the first 128 bits of a hash of the key as the IV. That should be OK security-wise as long as you are generating a new AES key for each session and not re-using the same AES key over and over with the same IV.
There is no reason to encrypt the IV - you can send that in the clear. Just make sure you pick a new one each time (the same way you do the AES key).
That said, it is often convenient to package the AES key and IV together. Encryption of 16 bytes ain't that expensive.