# Why programming languages don't provide simple encryption methods?

In c#, there is a namespace called System.Security.Cryptography and there are many classes in this namespace, which help developers encrypt and decrypt data. However, always they take byte[] array and they return byte[] array. So, as a developer, you have to always write a library to get the clear-text, turn it into byte of arrays, encrypt it, then turn the cipher array into an string, and return it.

I've talked to some other PHP and Java developers, and they told me that they have to undergo the same process there too. I haven't seen those languages though.

My question is, why frameworks like .NET framework, don't provide an straightforward mechanism for encryption and decryption? I mean, from the point of view of a developer, cryptography means a black box into which you pass a string, and from which you will get an string, without the need to get into the complexity of creating streams like CryptoStream and without the need to converting strings into bytes of arrays, etc.

For example, look at this simple encryption example, taken from Microsoft's MSDN:

    static byte[] EncryptStringToBytes(string plainText, byte[] Key, byte[] IV)
{
// Check arguments.
if (plainText == null || plainText.Length <= 0)
throw new ArgumentNullException("plainText");
if (Key == null || Key.Length <= 0)
throw new ArgumentNullException("Key");
if (IV == null || IV.Length <= 0)
throw new ArgumentNullException("Key");
byte[] encrypted;
// Create an Rijndael object
// with the specified key and IV.
using (Rijndael rijAlg = Rijndael.Create())
{
rijAlg.Key = Key;
rijAlg.IV = IV;

// Create a decrytor to perform the stream transform.
ICryptoTransform encryptor = rijAlg.CreateEncryptor(rijAlg.Key, rijAlg.IV);

// Create the streams used for encryption.
using (MemoryStream msEncrypt = new MemoryStream())
{
using (CryptoStream csEncrypt = new CryptoStream(msEncrypt, encryptor, CryptoStreamMode.Write))
{
using (StreamWriter swEncrypt = new StreamWriter(csEncrypt))
{

//Write all data to the stream.
swEncrypt.Write(plainText);
}
encrypted = msEncrypt.ToArray();
}
}
}

// Return the encrypted bytes from the memory stream.
return encrypted;

}


This is just not simple and easy, and I think there should be a class in .NET Framework like TripleDesCryptoHelper with two methods as follow:

public string Encrypt(string clearText)
{
// Doing the cryptography stuff here
return cipherText;
}

public string Decrypt(string cipherText)
{
// Doing the cryptography stuff here
return clearText;
}

-
If you are free in the choice of your cryptographic algorithms, you can use NaCl (nacl.cace-project.eu/index.html) for your C, C++ and Python projects. Its secure, fast and resistant against timing attacks. –  j.p. Jan 3 '12 at 12:52
Can anyone provide examples of security failures that resulted from the lack of ease of use of Encryption libraries? –  Ethan Heilman Jan 3 '12 at 16:08
@EthanHeilman in my opinion, any library that does not provide integrity checks/authentication by default for encryption is already luring users into a pretty sweet trap, and if you use e.g. "AES" algorithm in Java, it will default to "AES/ECB/PKCS5Padding" and ECB is not what you want. Besides, security requirements change in time, and once you've introduced a default setting, you cannot change it afterwards without breaking everything. –  owlstead Jan 3 '12 at 19:46
@EthanHeilman Look at some encryption questions/answers on stackoverflow. Most of them have huge holes, such as no authentication(hello padding oracle) or constant IVs. –  CodesInChaos Feb 7 '13 at 15:40
I am asking for serious failures in security that results in physical or financial damage. Such examples would make the case for simple easy to use packaged encryption in much the same way that firms which did not salt their passwords and had massive password exposures helped the security community "raise the bar" on password hashing standards. –  Ethan Heilman Feb 20 '13 at 16:05

It's not nearly as simple as you imagine. When you encrypt a string, what character set is it in? What characters are permissible in the output? There are too many unusual combinations of code requirements and security requirements for a "one size fits all" to make sense.

But if you think one size does fit all, sit down and write it. It should take you an hour or so. You'll have it forever, can share it with other people, and this problem will be solved. I think you'll find everyone needs it to be a little different and you'll be right back where we are.

Here's a function to set the character set. Here's a function to switch between hex and base64. Here's a function to add padding. Here's a function to add a checksum. Here's a function to set the key in hex. Here's a function to set the key in base64. And so on, and so on, and so on.

Fundamentally, encryption is not easy. Threat models differ. Requirements differ. One simple "this encrypts" interface is much more likely to be used to disastrous results than good ones.

There's also the attractive nuisance issue -- things that are neither easy nor safe probably should not look easy and safe.

-
You are right. I never said that one-fit-all solution is a good one. But I said that frameworks could include both the easy version as well as the sophisticated one. For example, concatenating strings is possible both via StringBuilder class, and string.Format() method. The second one is more handy when it comes to simple placeholders. –  Saeed Neamati Jan 3 '12 at 14:31
String concatenation does not change in time. Crypto requirements do, and you cannot change defaults afterwards, because all the old code will break. Currently I would e.g. default to AES in EAX mode, but most frameworks may not even support that, and maybe you want to switch over later to single pass encryption/authentication (once that frickin patent finally expires) –  owlstead Jan 3 '12 at 19:51
"Frameworks could include both the easy version as well as the sophisticated one." The problem there is that there isn't one single "sophisticated" crypto scheme that a library could include by default. There are, as David Schwartz said, varying needs for varying applications of cryptography. –  Joe Z. Jan 15 '13 at 3:48
Let's not forget that cryptography is restrained or even illegal in many countries, and as such limits the distribution of the language if included. –  nightcracker Feb 8 '13 at 21:02

I've seen some libraries that offer simplified cryptography methods, but as that was a long time ago (like 15-20 years) because they only handled ASCII strings, with your choice of Base64 or Hex output. But as David pointed out things are much more complicated. Most systems handle Unicode and different character encodings.

There probably are simplified libraries for some systems that make it easier to do simple string cryptography. And those would be useful for working on "school assignments" and modeling simple scenarios like on here, but for actual work they wouldn't be useful anymore.

Say you wanted to encrypt email. Sure, it is just plain text right? But what if the email supports international character sets? How about binary attachments? Well, now it is a combination of "plain text" and binary data. What should the system output when it is done? Hexadecimal would be a bad choice because it takes a lot more bytes to represent the same data. So go with Base64 output? That makes since, but if you are writing it to a file, or streaming it through another mechanism then you want it as regular binary data to take up less space (base 64 adds like a 30% size overhead if I remember correctly).

What you will most likely do is create a mid to high level layer for each specific cryptography application you are creating. Chances are you will probably reuse some of that between applications too.

-