C# ROT13 encipher/decipher method

[C#] ROT13 encipher/decipher method - Printable Version

+- Hack Forums (https://hackforums.net)
+-- Forum: Tech (https://hackforums.net/forumdisplay.php?fid=444)
+--- Forum: Coding (https://hackforums.net/forumdisplay.php?fid=151)
+---- Forum: Software Development (https://hackforums.net/forumdisplay.php?fid=118)
+---- Thread: [C#] ROT13 encipher/decipher method (/showthread.php?tid=5685204)

ROT13 encipher/decipher method - gigajew - Aug 2, 2017

After working on the inclusive or, this caught my interest and so here you go. It works by rotating forward or backward 13. So if you had 13 and rotated backward, it'd become 0. If you had 255 and rotated forwards, you'd have 13.

Instructions for dummies: Rot13.Encipher(byte[]); and Rot13.Decipher(byte[]);

[Image: WjfS1TE.png]

* - Phizo - Aug 2, 2017

You don't need to do if(r > 255) return r % 255 else return r. That is the same as r % 255. Same with the other condition below. Also, it is exclusive. It is in the interval [0, 255), meaning when r = 255, r % 255 = 0. Are you sure that you don't want r % 256?

* - gigajew - Aug 2, 2017

(Aug 2, 2017 09:32 PM)Phizo Wrote: You don't need to do if(r > 255) return r % 255 else return r. That is the same as r % 255. Same with the other condition below. Also, it is exclusive. It is in the interval [0, 255), meaning when r = 255, r % 255 = 0. Are you sure that you don't want r % 256?

Thanks for the input I will review it tomorrow

With the modifications specified above. Thank you, Phizo
[Image: kOIWUei.png]

* - D3RP - Aug 3, 2017

This is interesting. Makes for a good encryption if you want to rotate ahead part of a bye array and rotate backwards other parts. Then you can represent this forwards / backwards movement using a single bit. 1 forwards, 0 backwards.... Really simple key to encode.

* - 0xDEAD10CC - Aug 3, 2017

Why are your shift functions public members of the class when they have no relevance to the caller in terms of Rot13 which is dealt with by the 2 other functions? And why would you clone and unbox the array when you can just create an array of the same length? This is terribly inefficient for such a simple algorithm... However it's also inaccurate since 255 is a valid byte.

Code 
private static byte[] Rot13Encode(byte[] bytes)

{

    byte[] encoded = new byte[bytes.Length];

    for (int i = 0; i < bytes.Length; i++)

    {

        encoded[i] = (byte)((bytes[i] + 13) % 256);

    }

    return encoded;

}

private static byte[] Rot13Decode(byte[] bytes)

{

    byte[] decoded = new byte[bytes.Length];

    for (int i = 0; i < bytes.Length; i++)

    {

        decoded[i] = (byte)(bytes[i] >= 13

            ? bytes[i] - 13

            : 243 + bytes[i]);

    }

    return decoded;

}

* - gigajew - Aug 4, 2017

(Aug 3, 2017 10:06 PM)0xDEAD10CC Wrote: Why are your shift functions public members of the class when they have no relevance to the caller in terms of Rot13 which is dealt with by the 2 other functions? And why would you clone and unbox the array when you can just create an array of the same length? This is terribly inefficient for such a simple algorithm... However it's also inaccurate since 255 is a valid byte.

Code
private static byte[] Rot13Encode(byte[] bytes) { byte[] encoded = new byte[bytes.Length]; for (int i = 0; i < bytes.Length; i++) { encoded[i] = (byte)((bytes[i] + 13) % 256); } return encoded; } private static byte[] Rot13Decode(byte[] bytes) { byte[] decoded = new byte[bytes.Length]; for (int i = 0; i < bytes.Length; i++) { decoded[i] = (byte)(bytes[i] >= 13 ? bytes[i] - 13 : 243 + bytes[i]); } return decoded; }

I know 255 is a valid byte. Did you even try running the code and verifying the output? Hence the separate functions. Debugging purposes. Thanks for the input about the byte array I will keep it in mind.

* - Phizo - Aug 4, 2017

(Aug 4, 2017 04:48 AM)gigajew Wrote: I know 255 is a valid byte. Did you even try running the code and verifying the output? Hence the separate functions. Debugging purposes. Thanks for the input about the byte array I will keep it in mind.

You misunderstand. He is saying what I said above. Modulo is exclusive. r % 255 is in the interval [0, 255) (0 ≤ r < 255). Hence, r % 255 has a maximum value of 254. You need to change it to r % 256, as 255 is a valid byte, which your code does not account for.

(Aug 2, 2017 09:33 PM)gigajew Wrote: Thanks for the input I will review it tomorrow

With the modifications specified above. Thank you, Phizo

No problem. That is better. :)

I see you have changed one of them to r & 254. That is good (aside from being a byte off). r % 2^n is equivalent to r & (2^n - 1) for all n > 0. The latter is much faster. You should change the other operation as well. It will be r & 255 in this case, but I would advise making a variable m = 256 and doing r & (m - 1). This is equivalent to r % m, but again, significantly faster. Keep in mind this is only in the case r is non-negative or the language supplies % as true modulo rather than remainder. In C# (and many other languages), % is actually the remainder. -1 % 2 = 1 when % is true modulo. Here, it is -1 % 2 = -1. I assume that's why you used bitwise AND instead. Not for efficiency reasons. What you have is fine (it is actually better), but just keep this in mind (and update your code), as it's very important. You will run into logical errors otherwise, which are not always easy to spot.

* - gigajew - Aug 4, 2017

Final version, suggestions implemented and lots of mistakes realized

* - 0xDEAD10CC - Aug 5, 2017

(Aug 4, 2017 04:48 AM)gigajew Wrote: I know 255 is a valid byte. Did you even try running the code and verifying the output? Hence the separate functions. Debugging purposes. Thanks for the input about the byte array I will keep it in mind.

Little late - but did YOU even try running the code and verifying output? Clearly not...

* - gigajew - Aug 5, 2017

(Aug 5, 2017 09:54 AM)0xDEAD10CC Wrote: Little late - but did YOU even try running the code and verifying output? Clearly not...

I did, I was just expecting a different result than it was supposed to produce which caused the problems

* - Niǌa - Aug 5, 2017

(Aug 5, 2017 10:05 AM)gigajew Wrote: I did, I was just expecting a different result than it was supposed to produce which caused the problems

This is why testing and high code coverage is a must.