Encryption Problem

[Bob]

Hi
Problem. Generate valuable 'plain' data on Mach A. Need to write encrypted
version to CD which gets inputed to database on mach B.
Want the data to be encrypted in the table so it cannot be eyeballed to see
data.
'Plain' data gets inputted by application to Mach B, if valid match Mach B
takes action.
So...
Problem is that RijndaelManaged is too smart for the job seeing that gives a
unique encryption for the same plain data each time it is invoked.
ie I can't encrypt the plain text input on Machine B and compare it to the
database string that was originally generated on Mach A because they are two
different strings.
Obviously sequentially decrypting each item in the database table for a
match check is out of the question.
I realise I am asking for a weakened algorithm here but it is only the
viewing of the data by personnel of low end skills that I am trying to
protect against.

TIA
Bob

 

[Bob]

Hmmm,
From reading it appears that I need a hash. say MD5. But isn't there a
finite possibility that two different inputs may yield the same hash?
Thanks
Bob

 

[Jon Skeet [C# MVP]]

From reading it appears that I need a hash. say MD5. But isn't there a
finite possibility that two different inputs may yield the same hash?

Yes, in the same way that there's a finite possibility that you'll be
hit by a meteorite instead of getting this post.

However, you need to understand that you can't decrypt a hash - it's
one way. Do you actually need to decrypt the data on machine B?

Note that even with Rijndael I believe you'll get the same result if
you make sure you use the same IV and key both times.

 

[Marcus Andrén]

Hmmm,
From reading it appears that I need a hash. say MD5. But isn't there a
finite possibility that two different inputs may yield the same hash?
Thanks
Bob

The chance of collision (two strings having the same hash value) is
quite small when using a resonably large hash. The chance of two
single hashes colliding when using MD5 is 1 in 2^128. The chance of
course grows when you have several hashes, but it remains extremly
small.

What you are doing sounds like storing encrypted passwords which is a
very common use of hashing.

 

[Bob]

Hi Jon & Marcus,
Thank you for your replies,
The MD5 permutations are far greater than the permutations of the 20 digit
input number I am dealing with.
I didn't understand the scope of the MD5.
I can ensure uniqueness with an index on the database field. So the initial
insert will fail if I do get a 'meteror strike'
With regard to the Rijndael,
It does generate different results for the same input data each time it
encrypts, of course they all decrypt back to the correct input data. I had
sailed happily down the development stream with the Rijndael until this rock
appeared.
regards
Bob

 

[Jon Skeet [C# MVP]]

Thank you for your replies,
The MD5 permutations are far greater than the permutations of the 20 digit
input number I am dealing with.
I didn't understand the scope of the MD5.
I can ensure uniqueness with an index on the database field. So the initial
insert will fail if I do get a 'meteror strike'
Right.

With regard to the Rijndael,
It does generate different results for the same input data each time it
encrypts, of course they all decrypt back to the correct input data. I had
sailed happily down the development stream with the Rijndael until this rock
appeared.

Even with the same key and IV? That surprises me. Changing the test
program from MSDN to use the same key and IV each time gives me the
same encrypted data each time...