.net framework AND Unix code for encryption/decryption.

[tfoxusenet]

Hi, I need to encrypt/decrypt some data for my C# application that can
also be read on a unix system, and need a quick, simple, cross-platform
solution I can embed in my own code that doesn't require dependencies
on outside applications.

I don't know much about encryption. What I would like to do is come up
with an encryption/decryption code that will work with my C#/.NET
framework windows code (there are a number of cryptographic functions
built into the .net framework) AND a unix program (could be perl,
python, shell, C, etc). One requirement is that it should run on
virtually any unix system without installing additional software.

AES, DES, public key, anything is really fine, but it should be a
simple solution.

I have tried experimenting with a lot of code out there, but I am
unfamiliar enough with the process that I can't get it to work, e.g., I
create an encrypted file with my C# app, try to decrypt it using a PERL
or python scrip on the other end, and, I can't get it to work.

If you have code in both C# on the .net side and on the unix side that
would be greatly appreciated!

Thanks!

[Gabriel Magaña]

IMO, you should try harder... The algorithms you mention are all standard
and _should_ work. I say you should try harder because there could be
secondary issues like character set problems when you move encrypted data
across platforms... Encrypted files could be treated like text file when
you move them to *NIX and could have, for example, have CR/LF <--> LF
translation mistakenly applied.

For example, you could encrypt a file, take an MD5 checksum, transmit the
file, and take the MD5 checksum of it on the target platform. If the MD5
checksum matches, then you had no transmission problems, if there is a
problem decrypting the file, then the problem for sure is in the
encryption/decryption methods.

I think you have to make a better effort at diagnosing the problem. A
library that can encrypt/decrypt using standard algorithms should not care
where the data came from.

[Li-fan Chen]

Hi Gabriel,

All security library writers seek to consume and produce cipher text others
can use. (Text protected by encryption ciphers are all "serialized " and
"deserializ ed" around published block and streaming serialization rules and
standards. I am too lazy to look up the exact word here, hence the
wordiness. My bad.)

Things to look out for: 1) check endieness at the very worst; 2) look for
and address any other type of encoding the sender/receiver of the
cipher-text may have introduced.

Best personal regards,
-- Li-fan
--
Li-fan Chen
Software analyst/developer, Entrepreneur
Markham, Ontario, Canada
"Gabriel Magaña" <no*****@no-spam.com> wrote in message
news:uz******** ******@TK2MSFTN GP10.phx.gbl...

IMO, you should try harder... The algorithms you mention are all standard
and _should_ work. I say you should try harder because there could be
secondary issues like character set problems when you move encrypted data
across platforms... Encrypted files could be treated like text file when
you move them to *NIX and could have, for example, have CR/LF <--> LF
translation mistakenly applied.

For example, you could encrypt a file, take an MD5 checksum, transmit the
file, and take the MD5 checksum of it on the target platform. If the MD5
checksum matches, then you had no transmission problems, if there is a
problem decrypting the file, then the problem for sure is in the
encryption/decryption methods.

I think you have to make a better effort at diagnosing the problem. A
library that can encrypt/decrypt using standard algorithms should not care
where the data came from.