Re: Encrypt and Decrypt in C#
- From: Helge Jensen <helge.jensen@xxxxxxx>
- Date: Wed, 19 Oct 2005 16:24:42 +0200
SP wrote:
>>There are several things I am not too happy about in that code:
>
>
> It was one of those things that once it worked and it was being used then I
> did not want to change it. You make some valid points and I do have some
> comments and questions inline.
It wasn't that bad, it was just that when I got started looking at the
code more and more things kept drawing my attention...
>> - It uses DES-encryption
> Can you explain why DES is not the best choice.
DES is not "secure". it's keys are 56-bits, modern CPU's can brute force
DES faster than you can change the keys, custom hardware can do it in
minutes. Rinjdael (now AES) have longer key-lengths and generally
considered much more resistant to attacks.
>> - It is designed with the keys in the code
>
> How can you decrypt without the keys in your code somewhere. I place the
> keys in one place and they are encrypted by an obfuscator. How do you avoid
> placing the keys in your code?
The keys were actually duplicated, as the strings "1234...".
To avoid having the keys in the code, either prompt for them, have them
on disk or use any other means of input. Even if you know them to be
constant, have them in a file or something, so you can provide different
keys to different people.
BTW: an obfuscator will not really help against any, even just slightly,
qualified attacker.
>> - It uses a constant IV
>
> Is it better to use an encrypted and unknown IV or a random but known IV?
> You suggested above to use a random IV and store it in clear text.
The IV isn't secret, it's used to seed the encryption. No secrecy is
lost by transferring it it clear-text, nor is any secrecy gained by
obscuring it or "encrypting" it.
Choosing a random IV gives you non-deterministic cryptography -- that
is, multiple encryptions of the same clear is encrypted to different
cipher-texts.
>> - It doesn't come with a test (I know, that's a cheap-shot ;)
>
> I did not provide the unit tests. They are in a separate class. Of course it
> is easy to test.
Good, cryptographic code should almost always be unit-tested, it's
really hard to debug by inspecting the encrypted data ;)
>> - It converts data, to and from Base64
>
> Originally it was to be a license key so it may of needed to be typed in.
En/De-cryption should be a separate concen from what format the
input-data is in. If you need to Base64 convert somewhere, just do it on
the in/output of the de/en-cryption.
>> - It duplicates the code for creating the en/de-cryption keys
>
> Because I do not provide the Encrypt function in the Release build, only the
> Decrypt.
That doesn't prevent you from having a separate function for creating
the en/de-cryption keys. (http://c2.com/cgi/wiki?OnceAndOnlyOnce)
>> - It only works for strings with a valid ASCII-encoding
>> - It only works for keys with a valid ASCII-encoding
>> - It uses the ascii-encoding of key-strings as keys
>
> I knew that the text going in was ASCII but do not want to change anything
> at this point.
Fine, note that valud ASCII-text is encoded exactly the same in ASCII
and UTF8.
Using the ascii-encoding of key-strings directly as keys is frowned upon
since at dramatically reduces the used keyspace. Hashing the keys
removes this problem.
--
Helge Jensen
mailto:helge.jensen@xxxxxxx
sip:helge.jensen@xxxxxxx
-=> Sebastian cover-music: http://ungdomshus.nu <=-
.
- References:
- Re: Encrypt and Decrypt in C#
- From: SP
- Re: Encrypt and Decrypt in C#
- From: Helge Jensen
- Re: Encrypt and Decrypt in C#
- Prev by Date: Re: Config Setting Scope
- Next by Date: Re: passing parameters to a thread function
- Previous by thread: Re: Encrypt and Decrypt in C#
- Next by thread: Re: return keyword - invalid error message
- Index(es):
Relevant Pages
|
