Trying to encrypt a string

  • Thread starter Thread starter toupeira23
  • Start date Start date
T

toupeira23

Hello,

I'm trying to encrypt passwords in my app. After discovering that
there's no simple function to do this, I wrote a wrapper class which
decodes a string using UTF8, encrypts it with TripleDES and returns a
Base64-encoded string. The decryption function does the reverse, i.e.
Base64-decodes the string, decrypts it with the same Key and IV, and
encodes it again with UTF8. The problem is that after decrypting, the
8th character is not the same as it was before, e.g. in the example
below "testtest" changes to "testtesC". It's always on the 8th
character, all others are correctly decrypted. And the really strange
thing is, if you enable the commented-out code in Main(), it works
correctly! I've tried recreating the TripleDESCryptoServiceProvider on
every encrypt/decrypt, but that doesn't help.

Can anybody explain what's going on? Is this a(nother) bug in .NET
itself?

Here's the code I'm using:

using System;
using System.Text;
using System.Security.Cryptography;

public sealed class Crypto
{
private static TripleDESCryptoServiceProvider des;
private static TripleDESCryptoServiceProvider DES
{
get {
if (des == null) {
des = new TripleDESCryptoServiceProvider();
des.Key = Encoding.UTF8.GetBytes("0123456789012345");
des.IV = Encoding.UTF8.GetBytes(System.Environment.MachineName);
}
return des;
}
}

public static string Encrypt(string text)
{
try {
if (text == "")
return "";
byte[] bytes = Encoding.UTF8.GetBytes(text);
ICryptoTransform encryptor = DES.CreateEncryptor();
return Convert.ToBase64String(encryptor.TransformFinalBlock(bytes,
0, bytes.Length));
} catch (Exception e) {
Console.WriteLine(e.ToString());
return "";
}
}

public static string Decrypt(string text)
{
try {
if (text == "")
return "";
byte[] bytes = Convert.FromBase64String(text);
ICryptoTransform decryptor = DES.CreateDecryptor();
return Encoding.UTF8.GetString(decryptor.TransformFinalBlock(bytes,
0, bytes.Length));
} catch (Exception e) {
Console.WriteLine(e.ToString());
return "";
}
}

public static void Main()
{
string test = "testtest";

/*
Console.WriteLine(Encrypt(test));
Console.WriteLine(Decrypt(Encrypt(test)));
*/

string encrypted = Encrypt(test);
Console.WriteLine(encrypted);
string decrypted = Decrypt(encrypted);
Console.WriteLine(decrypted);
}
}


thanks,
markus
 
By the way, this is on Windows 2000 with .NET 1.1.4322. I've also tried
on Windows 2003 (with same .NET version), and the result is "tesG?",
but with the commented-out code it works, too.
 
I'm trying to encrypt passwords in my app. After discovering that
there's no simple function to do this, I wrote a wrapper class which
decodes a string using UTF8, encrypts it with TripleDES and returns a
Base64-encoded string. The decryption function does the reverse, i.e.
Base64-decodes the string, decrypts it with the same Key and IV, and
encodes it again with UTF8. The problem is that after decrypting, the
8th character is not the same as it was before, e.g. in the example
below "testtest" changes to "testtesC". It's always on the 8th
character, all others are correctly decrypted. And the really strange
thing is, if you enable the commented-out code in Main(), it works
correctly! I've tried recreating the TripleDESCryptoServiceProvider on
every encrypt/decrypt, but that doesn't help.
Click to expand...

<snip>

I think you're ending up with an entire block of data, even though you
weren't submitting an entire block. I strongly recommend using
CryptoStreams instead of the transforms directly - that *should* sort
you out, I believe.

Jon
 
Hello,

I'm trying to encrypt passwords in my app. After discovering that
there's no simple function to do this, I wrote a wrapper class which
decodes a string using UTF8, encrypts it with TripleDES and returns a
Base64-encoded string. The decryption function does the reverse, i.e.
Base64-decodes the string, decrypts it with the same Key and IV, and
encodes it again with UTF8. The problem is that after decrypting, the
8th character is not the same as it was before, e.g. in the example
below "testtest" changes to "testtesC". It's always on the 8th
character, all others are correctly decrypted. And the really strange
thing is, if you enable the commented-out code in Main(), it works
correctly! I've tried recreating the TripleDESCryptoServiceProvider on
every encrypt/decrypt, but that doesn't help.

Can anybody explain what's going on? Is this a(nother) bug in .NET
itself?

Here's the code I'm using:
Click to expand...

Your posted code worked on my machine (XP, Framework 1.1) with a slight
necessary change:
des.IV = Encoding.UTF8.GetBytes(System.Environment.MachineName);
Click to expand...

This only works if MachineName is the right size. The IV has to be the
same size as the algorithm's block size, which here is 64 bits, so I
guess your machine name is 8 bytes. Try with some other fixed 8 bytes
and see if that helps (I used Encoding.UTF8.GetBytes("01234567")).
 
This only works if MachineName is the right size. The IV has to be the
same size as the algorithm's block size, which here is 64 bits, so I
guess your machine name is 8 bytes. Try with some other fixed 8 bytes
and see if that helps (I used Encoding.UTF8.GetBytes("01234567")).
Click to expand...

You're right, that was it! Why can't they just say so in the docs?
*grumble*

Anyway, thanks a lot!


greetings,
markus
 
Jon said:
I think you're ending up with an entire block of data, even though you
weren't submitting an entire block. I strongly recommend using
CryptoStreams instead of the transforms directly - that *should* sort
you out, I believe.
Click to expand...

<snip>

For the sake of posterity: please ignore the answer given above.
Larry's answer is correct. (Note: you can use the GenerateIV method to
generate a random one.)

Jon
 
Hello,

I'm trying to encrypt passwords in my app. After discovering that
there's no simple function to do this, I wrote a wrapper class which
decodes a string using UTF8, encrypts it with TripleDES and returns a
Base64-encoded string. The decryption function does the reverse, i.e.
Base64-decodes the string, decrypts it with the same Key and IV, and
encodes it again with UTF8. The problem is that after decrypting, the
8th character is not the same as it was before, e.g. in the example
below "testtest" changes to "testtesC". It's always on the 8th
character, all others are correctly decrypted. And the really strange
thing is, if you enable the commented-out code in Main(), it works
correctly! I've tried recreating the TripleDESCryptoServiceProvider on
every encrypt/decrypt, but that doesn't help.

Can anybody explain what's going on? Is this a(nother) bug in .NET
itself?

Here's the code I'm using:
[snip code]

thanks,
markus
Click to expand...

A thought - why are you decrypting passwords?

When the user enters a password just encrypt it and see if it matches
with the stored encrypted version. If the encrypted versions match
then the plaintext versions would have matched (assuming a reasonable
encryption scheme).

rossum


The ultimate truth is that there is no ultimate truth
 
Possibly because he needs to use the credentials for something. For example,
creating an app that cache's user credentials in the registry to access a
service on the web.

If you want to give end users a way to cache username and password, but have
to retrieve it back to text to pass it from your application.


--
(e-mail address removed).<Remove This Before Emailing>

Network & Software Integration
www.n-sv.com

"Helping put the pieces of your IT puzzle together"


rossum said:
Hello,

I'm trying to encrypt passwords in my app. After discovering that
there's no simple function to do this, I wrote a wrapper class which
decodes a string using UTF8, encrypts it with TripleDES and returns a
Base64-encoded string. The decryption function does the reverse, i.e.
Base64-decodes the string, decrypts it with the same Key and IV, and
encodes it again with UTF8. The problem is that after decrypting, the
8th character is not the same as it was before, e.g. in the example
below "testtest" changes to "testtesC". It's always on the 8th
character, all others are correctly decrypted. And the really strange
thing is, if you enable the commented-out code in Main(), it works
correctly! I've tried recreating the TripleDESCryptoServiceProvider on
every encrypt/decrypt, but that doesn't help.

Can anybody explain what's going on? Is this a(nother) bug in .NET
itself?

Here's the code I'm using:
[snip code]

thanks,
markus
Click to expand...

A thought - why are you decrypting passwords?

When the user enters a password just encrypt it and see if it matches
with the stored encrypted version. If the encrypted versions match
then the plaintext versions would have matched (assuming a reasonable
encryption scheme).

rossum


The ultimate truth is that there is no ultimate truth
Click to expand...
 
rossum said:
Hello,

I'm trying to encrypt passwords in my app. After discovering that
there's no simple function to do this, I wrote a wrapper class which
decodes a string using UTF8, encrypts it with TripleDES and returns a
Base64-encoded string. The decryption function does the reverse, i.e.
Base64-decodes the string, decrypts it with the same Key and IV, and
encodes it again with UTF8. The problem is that after decrypting, the
8th character is not the same as it was before, e.g. in the example
below "testtest" changes to "testtesC". It's always on the 8th
character, all others are correctly decrypted. And the really strange
thing is, if you enable the commented-out code in Main(), it works
correctly! I've tried recreating the TripleDESCryptoServiceProvider on
every encrypt/decrypt, but that doesn't help.

Can anybody explain what's going on? Is this a(nother) bug in .NET
itself?

Here's the code I'm using:
[snip code]

thanks,
markus
Click to expand...

A thought - why are you decrypting passwords?

When the user enters a password just encrypt it and see if it matches
with the stored encrypted version. If the encrypted versions match
then the plaintext versions would have matched (assuming a reasonable
encryption scheme).

rossum


The ultimate truth is that there is no ultimate truth
Click to expand...
Possibly because he needs to use the credentials for something. For example,
creating an app that cache's user credentials in the registry to access a
service on the web.

If you want to give end users a way to cache username and password, but have
to retrieve it back to text to pass it from your application.


--
(e-mail address removed).<Remove This Before Emailing>

Network & Software Integration
www.n-sv.com

"Helping put the pieces of your IT puzzle together"
Click to expand...
Yes, that is a valid point. Only the final consumer of the password
does not need the plain text version.

Top posting changed to avoid confusion.

rossum
 
Back
Top