Encryption for a log and Unicode Characters...? Yikes!

[Guest]

Hello everyone... This may sound really stupid, but it is something I have
been working on all day and haven't found a solution yet.

If you go into Notepad and try the keystroke ALT+4, you get a nice little
diamond. Infact, you can do this all the way up to 127 showing different
characters including those similar with the ASCII table for letters and
numbers.

"Oh," I thought, "this could be the simple way for very simple encoding of
our log files." We are looking for an efficient way of encoding log files in
real time. Doing simple subtractions and additions on the character value to
offset them would be confusing for most novices to figure out upon
inspections of the log file (we are not looking for anything ultra secure
here).

But when I run my program and it starts logging the file, I get nice little
boxes instead of the images. Even in debug mode those characters (var =
"☺" will turn to boxes as well before even going out to the file.

I tried using the System.Text.Encoding stuff, but I get confused while
working with it.... perhaps this is not the correct thing to use.

Does anyone know how I can preserve those characters and put them to a log
file? Or is there a simpler way to encode my log file in real time? (
Rijndael and
TripleDES algs make our log files way to large).

Thank you all for reading this.

 

[daniel.manges]

If you just want something simple, it is easy to typecast characters to
integers and visa versa. You could use an algorithm like ROT13
(http://www.wikipedia.org/wiki/ROT13). If you want to use an algorithm
like that, character '0' is decimal 48, and 'z' is 122.

Loop through each character and get the integer, then add a value to
it, and convert back to a character.

int dec = (int)currentChar;
dec += 15;
if (dec > 122) dec -= 75;
newString += (char)dec;

That should confuse the "novices."

 

[Guest]

Hello KH,

Thank you for replying.

We are looking for a simple way to "encrypt" text to a log file in real time
that has very low overhead for the processor, yet still keeping the log files
the same size.

We decided that a simple distortion of the ASCII values would suffice
according to an offset, like in the code below:

buildString += (char)(charString - (31 - (key2)));

// ex, could be: buildString += (char)(charString - 25);
// so a lower case g (103 on ASCII table) would print as a capital N (78 on
ASCII Table)

This is located in a while loop performing this on every character. I
though that I could shift as low as 31 downwards nd still be safe since
notepad shows symbols for ALT+1 and so on.

This is sort of like a kids decoder ring saying that an A really is a L and
so forth, except key2 is randomized each time so it is harder for the person
reading the log line-by-line to translate and read.

This would cause our log files to be the same size since it is just a 1-to-1
character substitution.

Not very secure, but it will deture the bulk of the people from reading our
logs like they have in the past.

However, I did find this article from The Code Project in light of you
suggested. ...

http://www.codeproject.com/csharp/Base64EncDec.asp

It almost appears this method will cause our logs to grow by about 30%...so
I will have to check on that. I don't know how much overhead this is for the
processor either so I will have to bench mark it.

Thanks,

Rob K

 

[Rob Schieber]

Hello everyone... This may sound really stupid, but it is something I have
been working on all day and haven't found a solution yet.

If you go into Notepad and try the keystroke ALT+4, you get a nice little
diamond. Infact, you can do this all the way up to 127 showing different
characters including those similar with the ASCII table for letters and
numbers.

"Oh," I thought, "this could be the simple way for very simple encoding of
our log files." We are looking for an efficient way of encoding log files in
real time. Doing simple subtractions and additions on the character value to
offset them would be confusing for most novices to figure out upon
inspections of the log file (we are not looking for anything ultra secure
here).

But when I run my program and it starts logging the file, I get nice little
boxes instead of the images. Even in debug mode those characters (var =
"☺" will turn to boxes as well before even going out to the file.

I tried using the System.Text.Encoding stuff, but I get confused while
working with it.... perhaps this is not the correct thing to use.

Does anyone know how I can preserve those characters and put them to a log
file? Or is there a simpler way to encode my log file in real time? (
Rijndael and
TripleDES algs make our log files way to large).

Thank you all for reading this.

I don't think shifting the ascii value is a good approach. If you are
looking for something fairly simple, I would just Base64 encode. Its
fairly easy to use and will preserve the value of the bytes.

System.Convert.ToBase64String
System.Convert.FromBase64String

 

[Guest]

What exactly are you trying to do? I think you're confusing encoding and
encrypting.

Assuming you're writing text to your log file, it is already encoded in one
of many many many text encodings (like us-ascii, Windows-1252, UTF-32,
iso-8859-13, big5, ...)

As a guess you may want to look up Base 64 encoding - it may accomplish what
you want.

 

[Jon Skeet [C# MVP]]

Thank you for replying.

We are looking for a simple way to "encrypt" text to a log file in real time
that has very low overhead for the processor, yet still keeping the log files
the same size.

There are various ways you can do that, but frankly it becomes easier
if you treat the data as binary - encode it (eg using Encoding.UTF8 or
Encoding.Unicode) and then do whatever simple "encryption" you want.
However, that way you will *not* get logs which are viewable in
notepad. Is that really an issue for you? I would have thought you only
wanted log files which, if sent to you, you can decode.

 

[Guest]

Correct, base 64 will increase your files by about a third from whatever
encoding you're converting from, since it uses 4 bytes to encode 3 bytes.
Here's a good article on how it works:

http://email.about.com/cs/standards/a/base64_encoding.htm

Also while I'm sure that code example works, there's already base 64
encoding classes in .NET - see Convert.ToBase64String and
Convert.FromBase64String.

You still need to know what text encoding you're going to and from to use it
properly.

Hello KH,

Thank you for replying.

We are looking for a simple way to "encrypt" text to a log file in real time
that has very low overhead for the processor, yet still keeping the log files
the same size.

We decided that a simple distortion of the ASCII values would suffice
according to an offset, like in the code below:

buildString += (char)(charString - (31 - (key2)));

// ex, could be: buildString += (char)(charString - 25);
// so a lower case g (103 on ASCII table) would print as a capital N (78 on
ASCII Table)

This is located in a while loop performing this on every character. I
though that I could shift as low as 31 downwards nd still be safe since
notepad shows symbols for ALT+1 and so on.

This is sort of like a kids decoder ring saying that an A really is a L and
so forth, except key2 is randomized each time so it is harder for the person
reading the log line-by-line to translate and read.

This would cause our log files to be the same size since it is just a 1-to-1
character substitution.

Not very secure, but it will deture the bulk of the people from reading our
logs like they have in the past.

However, I did find this article from The Code Project in light of you
suggested. ...

http://www.codeproject.com/csharp/Base64EncDec.asp

It almost appears this method will cause our logs to grow by about 30%...so
I will have to check on that. I don't know how much overhead this is for the
processor either so I will have to bench mark it.

Thanks,

Rob K

What exactly are you trying to do? I think you're confusing encoding and
encrypting.

Assuming you're writing text to your log file, it is already encoded in one
of many many many text encodings (like us-ascii, Windows-1252, UTF-32,
iso-8859-13, big5, ...)

As a guess you may want to look up Base 64 encoding - it may accomplish what
you want.

 

[Guest]

Do you think that the 64bit encoding is fairly fast with low overhead... I
may consider that....

Thanks,

Rob K

:

 

[Guest]

Thank you all for your help. I have since found out through peoples
comments, like Jon Skeet's, that notepad does not correctly display some of
the characters
although their ASCII value is really kept.

I think that in the future I may use the 64 bit encryption as suggested by
Rob Schieber.

I think everything is working at the moment, so thank you all for your
input.

Rob K

 

[Guest]

Hey, nice web page Jon. I think I may book mark it.

Your comment with notepad made me realize that the characters were actually
preserved, just that notepad itself coudn't display them.

Everything seems to be working.

Thanks again for your help.

Rob K

 

[Jon Skeet [C# MVP]]

Thank you all for your help. I have since found out through peoples
comments, like Jon Skeet's, that notepad does not correctly display some of
the characters
although their ASCII value is really kept.

I think that in the future I may use the 64 bit encryption as suggested by
Rob Schieber.

I think everything is working at the moment, so thank you all for your
input.

Just to make it clearer if you need more help later: Rob Schieber
didn't suggest 64 bit encryption; he suggested base64 encoding. They're
somewhat different things