We Keep Coding

Node.js encrypt RSA[XML]

I need to encrypt a string in Node.js using the key created in C# (XML format)
Public Key:
<RSAKeyValue><Modulus>mlDk9dIwcGJ+sS7kCOiG/xr/1RkM7v7/bUExalwSj7Q/Ul575l4cUGR1ZjC3BtEgmMZjW6xSRTCkgp0WMpdnXGmygV0mQbrAP32NTGoMoWgjTIevBbd+yOMfY8E87bUG0sYUA8+Wk55iEPk3O0Ua5FiLNWIqGTbrF2A5iSp1voc=</Modulus><Exponent>AQAB</Exponent></RSAKeyValue>
How can I do it?

You parse the XML using an XML parser, then retrieve the two base 64 values and decode those: the modulus and the public exponent. Then you generate a key using the two components for whatever library you are using.
I could not directly see if the number encoded is big- or little endian: Mickeysoft doesn't specify that, but the lack of reversal routines in other language implementations leads me to believe that the bytes represent a big endian encoding.
The fact that the leftmost byte of the modulus is an even value is probably a good indication as well as n = p * q, and if p & q are primes and thus odd, so the result of the calculation is then odd as well.

C# .net core encryption

I'm trying to use a public key of a user to encrypt a string in a sort of pgp fashion, but I keep getting the error:
bignum routines:BN_mod_inverse:no inverse
I've looked around and I cannot find anything specific as to what I'm doing wrong. I've looked around for .NET core information, but I cannot seem to find anything relevant.
I'm using the following code:
byte[] publicKey = Encoding.UTF8.GetBytes(key);
RSA rsa = RSA.Create();
RSAParameters RSAKeyInfo = new RSAParameters();
RSAKeyInfo.Modulus = publicKey;
RSAKeyInfo.Exponent = new byte[]{1,0,1};
rsa.ImportParameters(RSAKeyInfo);
var encrypted = rsa.Encrypt(Encoding.UTF8.GetBytes(user.challenge.text), RSAEncryptionPadding.Pkcs1);
It's entirely possible I'm going about this entirely wrong, so any thoughts or suggestions would be great!

Your overall structure (build RSAParameters, call ImportParameters, call Encrypt) is valid, which suggests that your error is in Modulus recovery.
If your Modulus is input as a string, it's likely encoded as (most to least)
Base64 (Convert.FromBase64String)
Hex (May need a manual parser)
UTF-8
UTF-8 is really unlikely, since the Modulus value can contain bytes whose value are 0 (and other invalid/unexpected UTF-8 sequences). While all even-length byte sequences encoded as hex can be validly decoded as Base64, it's extraordinarily unlikely that you'd misinterpret them given two or three different inputs.
Other noteworthy things:
RSA is IDisposable, you should put it in a using statement to ensure resources free up earlier when you are done with them.
The Exponent is usually 0x010001, but that isn't required. Unless you have a guaranteed constraint on it, you should be serializing it, too.
And if it is guaranteed to always be 0x010001, why make a new one each time? Save it as a static field and make the GC's job easier.
As Maarten said, RSA-ENC-PKCS1 is susceptible to a padding oracle attack, so (especially if your data is over the wire) you should use OAEP.
In the context of .NET, OaepSHA1 has the best support (all inbox providers). OAEP with a SHA-2 algorithm is only supported by RSACng (or the opaque RSA.Create() on Windows).

Custom Asymmetric Cryptography Algorithm

I want to use an asymmetric cryptography algorithm, but I need it have short Key Size(not like RSA which is at least 384).
I need it to be about around 20.
Is it possible?

That's a .NET restriction on the key size; RSA can be used with any key size. It just doesn't make sense to do so.
Think about it, with a 20-bit key you can brute force the it in 2^20 attempts and that's just too easy with today's computers.

There are several ways to have a short key size.
1. With RSA
A RSA public key consists in a big number n (the "modulus") and a (usually small) number e (the public exponent). e can be as small as 3, and in a closed setup (where you control key generation) you can force the use of a conventional e, the same for everybody. A typical size for n is 1024 bits (i.e. 128 bytes).
n is the product of two prime numbers (n = p*q). Knowledge of p and q is sufficient to rebuild the private key (nominally a value d which is a multiplicative inverse of e modulo p-1 and q-1). Assuming that n is known, knowledge of p alone is sufficient (if you know n and p, you can compute q with a simple division). For proper security, p and q should have similar sizes, so even by taking the smaller of the two, you still need to store about 512 bits or so -- that's 64 bytes).
It has also been suggested to select a small d (the "private exponent"). But this makes e essentially random, hence large; you can no longer use a conventional small value for e. This basically doubles the public key size. Also, forcing a small d can make the key weak (it has been shown to be the case when the size of d is no more than 29% of the size of n, but that does not prove in any way that a d of 30% the size of n is safe). This is generally considered to be a bad idea.
2. With DSA / Diffie-Hellman
DSA is a digital signature algorithm. Diffie-Hellman is a key exchange algorithm. Both are "asymmetric cryptographic algorithms" and you would use one or the other, or both, depending on your needs. In both cases, there is a public mathematical group (numbers modulo a big prime number p for the basic DSA and DH; elliptic curve variants use an elliptic curve as group); the public key is a group element, and the private key is the discrete logarithm of that element relatively to a conventional generator. In other words, a prime p and a number g modulo p are given (they can be shared by all key holders, even); a private key is a number x corresponding to the public key y = gx mod p. The private key is chosen modulo a small prime q. q is known and must be large enough so as to defeat the generic discrete logarithm algorithms; in practice, we want a 160-bit or more q.
This means that a private key fits in about 20 bytes. That's not 20 decimal digits, but closer.
3. With ANY cryptographic algorithm
When you generate a key pair, you do so with:
a deterministic procedure;
a source of random bits.
For instance, with RSA, you generate p and q by creating random odd numbers of the right size and looping until a prime number is found. For a given random source, the whole process is deterministic: given the same random bits, this will find the same primes p and q.
Hence you can develop a PRNG seeded by a secret key K and use it as random source for the key generation process. Whenever you need the private key, you run the key generation process again, using K as input. And voilà! Your private key, the one you need to store, is now K.
With RSA, this makes private key usage quite expensive (RSA key generation is not easy). However, with DSA / Diffie-Hellman, this would be very inexpensive: the private key is only a random number modulo q (the group order) which can be generated with much less cost than using the private key for a digital signature or an asymmetric key exchange.
This leads to the following procedure:
The "private key", as stored, is K.
The group parameters for DSA / Diffie-Hellman are hardcoded in the application; everybody uses the same group and that is not a problem. The group order is q, a known prime of at least 160 bits. If you use an elliptic curve variant, then q is a property of the curve, hence a given.
When you need to sign or to perform a key exchange (key exchange is used to emulate asymmetric encryption), you compute SHA-512(K), which yields a 512-bit sequence. You take the first half (256 bits), interpret it as a number (with big-endian or little-endian convention, as you wish, provided that you always use the same convention), and reduce it modulo q to get the private DSA key. Similarly, you use the second half of the SHA-512 output to get the private DH key.
The key generation is very slightly biased but this does not imply much security trouble. Note that if you need a DSA key and a DH key, then you can use the same group but you should not use the same private key (hence the use of both halves of the SHA-512 output).
How big should be K ? With a hash function such as SHA-512, K can be any arbitrary sequence of bits. However, K should be wide enough to defeat exhaustive search. A 1024-bit RSA key, or a 1024-bit DSA modulus (the p modulus for DSA), provide a security level which is very roughly equivalent to an 80-bit symmetric key. Similarly, a 160-bit group order for DSA/DH provides the same level. 80 bits are not that much; you cannot go lower than that if you want to be taken seriously. This means that K should be chosen among a space of at least 280 possible keys; in other words, if K is selected as uniformly random bytes, then it must be at least 10 bytes long. With decimal digits, you need at least 24 digits. Anything below that is intrinsically weak, and that's unavoidable.
Standard warning: if anything of the above is not obvious or crystal clear to you, then do not even think about implementing it. Implementation of cryptographic algorithm is tricky, especially since the deadliest errors cannot be tested (it is not because the program runs and appears to work properly that it does not contain security weaknesses).

You may want to consider using Elliptic Curve Cryptography, if you can find a standard implementation of it. It provides the same level of protection against brute force as RSA, with substantially shorter key lengths.
The standard disclaimer about cooking up your own cryptosystems applies here, of course.

How to create Encryption Key for Encryption Algorithms?

I want to use encryption algorithm available in .Net Security namespace, however I am trying to understand how to generate the key, for example AES algorithm needs 256 bits, that 16 bytes key, and some initialization vector, which is also few bytes.
Can I use any combination of values in my Key and IV? e.g. all zeros in Key and IV are valid or not? I know the detail of algorithm which does lots of xors, so zero wont serve any good, but are there any restrictions by these algorithms?
Or Do I have to generate the key using some program and save it permanently somewhere?
I want to store data in database after encryption, the secure profile data like username, password, phone number etc, and the key will be available to database user mentioned in connection string only, and to the administrator.

You really ought to do this the correct way :)
1) Use a securely generated random IV
2) Use a securely generated random key
3) Don't use ECB mode - EVER
AesManaged aes = new AesManaged();
aes.GenerateKey();
aes.GenerateIV();
The code above will correctly and securely generate a random IV and random key for you.

Sounds like you need to read into the Rfc2898DeriveBytes class.
Rfc2898DeriveBytes.GetBytes();
It has a method(above) that allows you to tailor the size of byte arrays that are fed into the .Key and .IV properties on a symmetric encryption algorithm, simply by feeding an int value. The MS official 70-536 book suggests doing this pro-grammatically by dividing the KeySize property / 8.
I.e TripleDes or AESManaged. Whatever you use, the algorithm itself will have some pre-reqs that will need meeting first. I.e satisfying the key size conditions. The RunTime will automatically fill the properties and fields and etc the best and most strongest values for you. But the IV and Key needs to come from you. This how you can do the following:
RijndaelManaged myAlg = new RiRijndaelManaged();
byte[] salt = Encoding.ASCII.GetBytes("Some salt value");
Rfc2898DeriveBytes key = new Rfc2898DeriveBytes("some password", salt);
myAlg.Key = key.GetBytes( myAlg.KeySize / 8);
myAlg.IV = key.GetBytes( myAlg.BlockSize / 8);
// myAld should now fully set-up.
Above you can see what I mean by doing it pro-grammatically, as it should pretty much
do it all for you, without you even really having to bat an eye-lid as to meeting it's pre-reqs.
The Microsoft 70-536 book states that the .Key properties expect the byte arrays you supply
to them in bytes and not bits. The RFC class works in bytes where as an algorithms KeySize property works in bits. 1 byte = 8 bits. Can you see where this is going ... ?
This should give you an idea as to why the above sample peice of code is done the way it is! I studied it and it makes pretty darn good sense to me!
The above answer should allow you to create your algorithm object with supplied password and a static salt value that can be hard code at both ends. Only thing you need to do is worry about how you going to make sure that the byte arrays stored at .Key and .IV are safely transported to a recipient so that can successfully decrypt the message you encrypted. By safely reconstructing the same algorithm object.
OBTW:
AESManaged has a keysize req': 128Bits = 16 Bytes !!!
(8*8 = 64, 64Bit / 8bits per Byte = 8 Bytes) Therefore
64*2 = 128Bit, 8*2, ==> 16bytes key size !
256Bit = 32Bytes !!!!
According to the 70-536 official training kit book, Aes is limited to having keysize of 128bits in size. 256bits,192 and 128 key size for example can be used with the Rijndael class.
You could on the other hand completely forget all that crap and simply use .GenerateKey and GenerateIV methods instead to save you all the hassle of sorting out a pre-shared and agreed password and static salt values. Your only concern is figuring out a way of storing and retrieving the key and IV byte arrays. Binary Formatter? .

If you are using encryption to exchange data then you will need a key exchange protocol, but you don't make one yourself instead use one off-the-shelf like TLS or SSL.
If you use encryption to store data then you generate the IV using CryptGenRandom (or its .net equivalent RandomNumberGenerator.GetBytes) and save it along the document (in clear, no need to protect the IV). You never write down the key, the key is provided by the user. Usualy you derive the key from a password phrase using CryptDeriveKey, or its .Net equivalent PasswordDeriveKey.CryptDeriveKey.
Update
To store a secret in the database that is available only to the user and an administrator you need to use 3 keys:
one to encrypt the data with (call it the DK key)
one user key to encrypt the DK key (call it UK)
one administrator key to encrypt the DK key (call it AK)
In theory you encrypt the data with DK and then encrypt the DK with UK and save it, and encrypt the DK with AK and save it. This way the user can use again the UK to decrypt the DK and then decrypt the data, and the administrator can use the AK to decrypt the DK and then decrypt the data. The big problem is the fact that the system is always automated, so the system needs access to the administrator's key which means is not truly a persnal key of the administrator, but instead is a system key (it cannot be used for purposes of non-repudiation for instance).
As a heads up, knowledge of what IV is or how to use AES from C# and how cryptography algorithm work will get you exactly 0 (zero) traction in solving this kind of problems. The issue is never what IV and key to use, the issue is always key provisioning. For actual crypto operations, just use the built-in support from the database, see Cryptography in SQL Server. I can easily argue that the only facility you need is TDE (Transparent Data Encryption) to protect against accidental loss of media.

Generate a random letters / hex code in a specific length.
This function (taken from here) return a random key in a specific length:
private static string CreateSalt(int size)
{
//Generate a cryptographic random number.
RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider();
byte[] buff = new byte[size];
rng.GetBytes(buff);
// Return a Base64 string representation of the random number.
return Convert.ToBase64String(buff);
}

Use System.Security.Cryptography.RandomNumberGenerator to generate random bytes:
var rnd = new System.Security.Cryptography.RandomNumberGenerator.Create();
var key = new byte[50];
rnd.GetBytes(key);

It really depends on what you ned to do with the key.
If the key is to be generated by the computer (and can be any random value) I generally take a SHA256 of a couple GUIDs. This is about as random as you're going to get without a hardware random number generator.
You can use keys with all 0s but obviously it won't be very secure.

AES output, is it smaller than input?

I want to encrypt a string and embed it in a URL, so I want to make sure the encrypted output isn't bigger than the input.
Is AES the way to go?

It's impossible to create any algorithm which will always create a smaller output than the input, but can reverse any output back to the input. If you allow "no bigger than the input" then basically you're just talking isomorphic algorithms where they're always the same size as the input. This is due to the pigeonhole principle.
Added to that, encryption usually has a little bit of padding (e.g. "to the nearest 8 bytes, rounded up" - in AES, that's 16 bytes). Oh, and on top of that you're got the issue of converting between text and binary. Encryption algorithms usually work in binary, but URLs are in text. Even if you assume ASCII, you could end up with an encrypted binary value which isn't ASCII. The simplest way of representing arbitrary binary data in text is to use base64. There are other alternatives which would be highly fiddly, but the general "convert text to binary, encrypt, convert binary to text" pattern is the simplest one.

Simple answer is no.
Any symmetric encryption algorithm ( AES included ) will produce an output of at minimum the same but often slightly larger. As Jon Skeet points out, usually because of padding or alignment.
Of course you could compress your string using zlib and encrypt but you'd need to decompress after decrypting.
Disclaimer - compressing the string with zlib will not guarantee it comes out smaller though

What matters is not really the cipher that you use, but the encryption mode that you use. For example the CTR mode has no length expansion, but every encryption needs a new distinct starting point for the counter. Other modes like OFB, CFB (or CBC with ciphertext stealing) also don't need to be padded to a multiple of the block length of the cipher, but they need an IV. It is unclear from your question if there is some information available from which an IV could be derived pseudorandomly an if any of these modes would be appropriate. It is also unclear if you need authentication, or if you need semantic security> i.e. is it a problem if you encrypt the same string twice and you get the same ciphertext twice?

If we are talking about symetric encription to obtain the original encrypted string from a cyphered one it is not possible. I think that unless you use hashes (SHA1, SHA256...) you will never obtain a cyphered string smaller than the original text. The problem with hashes is that they are not the solution for retrieving the original string because they are one way encryption algorithms.

When using AES, the output data will be rounded up to have a specific length (e.g a length divisible trough 16).
If you want to transfer secret data to another website, a HTTP post may do better than embedding the data into the URL.

Also just another thing to clarify:
Not only is it true that symmetric encryption algorithms produce an output that is at least as large as the input, the same is true of asymmetric encryption.
"Asymmetric encryption" and "cryptographic hashes" are two different things.
Asymmetric encryption (e.g. RSA) means that given the output (i.e. the ciphertext), you can get the input (i.e. the plaintext) back if you have the right key, it's just that decrypting requires a different key than the key used for encrypting. For asymmetric encryption, the same "pigeonhole principle" argument applies.
Cryptographic hashes (e.g. SHA-1) mean that given the output (i.e. the hash) you can't get the input back, and you can't even find a different input that hashes to the same value (assuming the hash is secure). For cryptographic hashes, the hash can be shorter than the input. (In fact the hash is the same size regardless of the length of the input.
And also one more thing: In any secure encryption system the ciphertext will be longer than the plaintext. This is because there are multiple possible ciphertexts that any given plaintext could encrypt to (e.g. using different IVs.) If this were not the case then the cipher would leak information because if two identical plaintexts were encrypted, they would encrypt to identical ciphertexts, and an adversary would then know that the plaintexts were the same.