471,618 Members | 1,529 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,618 software developers and data experts.

.net framework AND Unix code for encryption/decryption.

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!

Feb 16 '06 #1
2 2261
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.
Feb 16 '06 #2
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
"deserialized" 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**************@TK2MSFTNGP10.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.

Feb 16 '06 #3

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by Ralph Freshour | last post: by
1 post views Thread by D. Alvarado | last post: by
4 posts views Thread by Harold Crump | last post: by
4 posts views Thread by John Smith | last post: by
2 posts views Thread by sushant.bhatia | last post: by
25 posts views Thread by eggie5 | last post: by
9 posts views Thread by Betikci Boris | last post: by
9 posts views Thread by Alan M Dunsmuir | last post: by
reply views Thread by leo001 | last post: by
1 post views Thread by ZEDKYRIE | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.