Hi, fellow coders of cplusplus.com! I have created a simple program that takes in input from a user, and then sort or 'encrypts' it using a completely random sequence of characters, different each time. What I want is that the program I create to actually encrypt the data given to it. Here is my program so far.
If I were to mess around with crypto (which I actually am), I'd start with base64 encoding. Base 64 encoding is not a cryptographic algorithm, but rather provides convenient notation for handling arbitrary bit streams in human-readable format.
In other words, base64 is the input and the output format your crypto system can use.
Goodness Grace, this is a lot more code than I am willing to endure. It will take a VERY long time to write all that, and providing a statement of code for EVERY statement seems very inconvenient. I like your code, tition, but I want one that is much less to write. In fact, the whole reason I did random characters, was because I did not want to have to define each and every character for my program.
The problem with your code, though, is that it isn't reversible. It just spews out random characters that happen to share a size with the original string.
Also, if that code is too much for you to endure, realize that most C++ programs go a lot more than just 250 lines. Most of that is just switch statements anyway.
No, the whole idea of this topic was to do what tition proposed, just with a less REPETITIVE solution, otherwise I'm fine with what he said. I'm more or less looking for a better algorithm as a solution.
@isplis
Didn't you read my question! That was what I wanted to do, as you said!
You know what, based on titios answer, THANK YOU, I just thought of something. Wouldn't it be possible to create a multidimensional array, bidimensional to be exact, and using the same loop as before, print the character at the same index as the one found? How would I implement it, though?
@tition: GetCharFrom6bit and Get6bitFromChar can be reduced to around 5-10 lines of formatted code...
I am sure your statement is correct: how would you do it? In my defense though it took me about 5 minutes to type that code in (I have been a gaming style copy+ paste ninja* all my computer life, also am good at using multi-line inputs). Looking up the standard libraries usually takes longer than 5 minutes. Also in my defense these two functions are very fast and I think as portable as they get.
*I am talking about the alt+shift (+arrows, can use mouse too) shortcuts available in code blocks, visual studio, and many other good editors.
Cire, your code appears slower than mine. Yours will run its main cycle 64 times in the worst case scenario. It will be more than 128 machine instructions in the worst case scenario, on average more than 64 instructions. My code's speed is supposed to not depend on character you are looking up.
Probably Get6bitFromChar is a tad slower. It was off-the cuff. On the other hand, I expect the complementary function to be a tad faster than the typical jump table a switch turns into.
RUNNER PROG AGARIO wrote:
So tition and cire, I still don't have an answer, which one of your solutions should I use?
For kicks I profiled the functions. On average, my version of Get6bitFromChar took about 1.5 times as long your version took. On average, your version of GetCharFrom6bit took 3 times as long as my version took. At least, on my machine with VC++.
Modifying my version of Get6bitFromChar to use a static look-up table reduced the execution time considerably.
@Cire: oh yes, indeed! Your cire_Get6bitFromChar is much better than mine, my comments were for your first version (the one posted above). Your new one (in the link you gave) is a lot more elegant! Your GetCharFrom6bit is faster than mine too, but I get less than 10% difference on the website you gave [edit:]but not if I do some dirty optimizations.
I hope you wouldn't mind if I use your solution to refactor my code (for my own use)?
[Edit:] Aha! Got it: if I first convert the switched variable to unsigned char, my version of GetCharFrom6bit beats yours by a hair's width, so that's really down to how the machine does things. And yes, your cire_Get6bitFromChar is about 4 times faster - in fact eliminating your val intermediate variable appears to speed it up a bit. However, I do dare say my version is much simpler to come up with and explain than yours - yours does require some algorithmic insight. You could also avoid the init preparation by hard-coding the entire 256 element array, this will make it even faster and more reliable.
I hope you wouldn't mind if I use your solution to refactor my code (for my own use)?
There's nothing earth-shattering about a look-up table. Knock yourself out.
in fact eliminating your val intermediate variable appears to speed it up a bit.
The tests are set up to use containers to avoid the optimizer optimizing too much. The more you take away from that, the less likely the test results are to resemble real usage patterns.
[Edit: I see the change you made wasn't to where I was thinking when I saw your comment. If you're going to make that change, you may as well get rid of the return value and let the user check the value in output to determine if the call was successful. At the very least, it should be documented when a function makes a (surprising?) change on failure.]
However, I do dare say my version is much simpler to come up with and explain than yours - yours does require some algorithmic insight.
From my point of view, it's not. We use look up-tables all the time in everyday life. Switch analogs, not so much.
You can also avoid the init preparation by hard-coding the entire 256 element array, this will make it even faster and more reliable.
Hard-coding things rarely makes things more reliable, and this case is no exception. In fact, I should've done the initialization of the table a little differently to allow for different letter encodings (although I doubt that code'll ever see a system with EBCDIC,) but this wasn't really intended to go past the toy phase. As for speed, the cost of the initialization is a one-time cost that doesn't affect the look-up speed at all. Hard-coding won't buy you much.
We use look up-tables all the time in everyday life. Switch analogs, not so much.
Now that you are saying it: how are switches actually implemented ... I remember the creator of D making a point about his language having or planning to have switches over arbitrary data types (including user-defined ones).
RUNNER PRO AGARIO, there's a bug in your original program. Lines 49-52 encrypt the text N times. You probably need to get rid of the loop, or change encryptText() to be encryptChar() (i.e., to encrypt a single character).
I suggest that you also add an option to the program that will decrypt the text too. That way you can write and test both encryption and decryption at the same time.
Hmm. You probably want an option to enter the encryption and/or decryption key too, assuming that there is one.
Regarding base-64 encoding: you could use a lookup table for both encoding and decoding, but why not just encrypt the bytes directly? That way you can encrypt non-text data too.
Now the real question: what encryption algorithm do you want to use?