Simple Encryption and Decryption

  • Thread starter Thread starter Xarky
  • Start date Start date
X

Xarky

Hi,
I would like to enrypt and decrypt a simple line of text, with a
private(symmetric) key.

I have tried searching in the System.Cryptography class, but I can't
find a simple way of doing this job.

Can someone recommend me an easy way on how to do it.
Thanks in Advance
 
Xarky said:
Hi,
I would like to enrypt and decrypt a simple line of text, with a
private(symmetric) key.

I have tried searching in the System.Cryptography class, but I can't
find a simple way of doing this job.

Can someone recommend me an easy way on how to do it.
Thanks in Advance

There is a Microsoft way to do this. However you can also do it
naively, since every character is representable by an ascii number,
your line of text evaluates to a line of numbers, on which you can
let loose some algorithm to scramble it.
 
Zach said:
There is a Microsoft way to do this. However you can also do it
naively, since every character is representable by an ascii number,
your line of text evaluates to a line of numbers, on which you can
let loose some algorithm to scramble it.

No, *not* every character is representable by an ascii number. ASCII
has no Unicode values over 127, whereas there are *loads* of Unicode
characters over 127...
 
Jon Skeet said:
No, *not* every character is representable by an ascii number. ASCII
has no Unicode values over 127, whereas there are *loads* of Unicode
characters over 127...

Oh dear, the OP is talking about "a simple line of text".
 
Xarky,

Check out any of the classes that derive from
System.Security.Cryptography.SymmetricAlgorithm.

Regards,
Joakim
 
Zach said:
Oh dear, the OP is talking about "a simple line of text".

So are you 100% positive that a "simple line of text" can't contain any
non-ASCII characters? That's a view which is very much biased towards
the English-speaking world.

Basically, assuming that ASCII is good enough for text files is a
recipe for disaster unless you have specifications which you can
guarantee won't change to allow "real" text. (It's usually good enough
for header names, but not always header values, for instance.)

There are perfectly good ways of encrypting text without making such
assumptions - just using UTF-8 instead of ASCII to convert the text
data into binary data would be my suggestion.
 
DalePres said:

Unfortunately that makes the same mistake that Zach did - assuming that
all text is ASCII.

I suggest using UTF-8 instead. Just use Encoding.UTF8.GetBytes instead
of Encoding.ASCII. (I'm also not sure why you're using Encoding.ASCII
in one place and manually creating an instance of ASCIIEncoding in
another.)

Also note that the call to Substring at the end isn't required if you
do things properly - don't assume that the decrypted data is the same
length as the encrypted data, but read the whole of the stream instead.
(Also don't assume that a single call to Stream.Read will do everything
you want it to. See http://www.pobox.com/~skeet/csharp/readbinary.html
for more on this.)
 
Thanks for the good ideas.

DalePres

Jon Skeet said:
Unfortunately that makes the same mistake that Zach did - assuming that
all text is ASCII.

I suggest using UTF-8 instead. Just use Encoding.UTF8.GetBytes instead
of Encoding.ASCII. (I'm also not sure why you're using Encoding.ASCII
in one place and manually creating an instance of ASCIIEncoding in
another.)

Also note that the call to Substring at the end isn't required if you
do things properly - don't assume that the decrypted data is the same
length as the encrypted data, but read the whole of the stream instead.
(Also don't assume that a single call to Stream.Read will do everything
you want it to. See http://www.pobox.com/~skeet/csharp/readbinary.html
for more on this.)
 
Again, thanks for the feedback on my article. I've updated it based on your
suggestions.

DalePres
 
Hi,
First of all thanks for all your replies, but I think I was not clear
in my query.

What I have to encrypt is users passwords. These are to be stored in
an XML file. The password to be used both for encrypting and decrypting
is to be kept as a constant string.
 
To encrypt passwords. exctract the SHA-256 hash for the password using the
methods in the example I already gave you. Of course, you could use other
hash methods available in the framework, but the example I gave you uses
SHA-256 and is secure enough to last the next few years. Alternatives are
MD5, SHA-1 (now obsolete), SHA-384, or SHA-512.

To store the results in an XML file, use the Convert.ToBase64String method.
To convert back to the hash, use the Convert.FromBase64String method. Then
to validate the password in code, the user should type in the password, your
code creates a SHA-256 hash from what the user types in and then compares it
to the stored hash.


HTH

DalePres
 
DalePres said:
To encrypt passwords. exctract the SHA-256 hash for the password using the
methods in the example I already gave you. Of course, you could use other
hash methods available in the framework, but the example I gave you uses
SHA-256 and is secure enough to last the next few years. Alternatives are
MD5, SHA-1 (now obsolete), SHA-384, or SHA-512.

When you say that SHA-1 is now obsolete - the attacks recently have
reduced the strength of it, but for most purposes it may well still be
good enough.

From http://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html

<quote>
They can find collisions in SHA-1 in 2^69 calculations, about 2,000
times faster than brute force. Right now, that is just on the far edge
of feasibility with current technology. Two comparable massive
computations illustrate that point.

In 1999, a group of cryptographers built a DES cracker. It was able to
perform 2^56 DES operations in 56 hours. The machine cost $250K to
build, although duplicates could be made in the $50K-$75K range.
Extrapolating that machine using Moore's Law, a similar machine built
today could perform 2^60 calculations in 56 hours, and 2^69
calculations in three and a quarter years. Or, a machine that cost
$25M-$38M could do 2^69 calculations in the same 56 hours.
</quote>

I suspect most apps don't really need to anticipate that level of
attack.
 
Back
Top