Jump to content

  • Log In with Google      Sign In   
  • Create Account


Anyone want a want a file encrypter I made?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
5 replies to this topic

#1 rnw159   Members   -  Reputation: 120

Like
1Likes
Like

Posted 13 January 2012 - 07:58 PM

A friend asked me for a file encrypter a while ago, so I wrote one in console. He just told me that it has been really useful for him and I should consider giving it to other people. It just asked you to drag and drop the file on the screen, and it encrypts it with a key you can use to decrypt it from the same program.




Anyway, it is rar'd with this post if you want it.

Attached File  Encrypt.rar   109.53KB   32 downloads

Sponsor:

#2 rnw159   Members   -  Reputation: 120

Like
0Likes
Like

Posted 13 January 2012 - 08:24 PM

Just realized that it may look strange to ask people to run an exe file just like that. So can one brave person run it, then post proof that it is safe?

Quote:

Original post by rnw159Screw game maker.

There's your sig quote for the forums :D[/quote]

#3 TheUnbeliever   Members   -  Reputation: 957

Like
1Likes
Like

Posted 13 January 2012 - 08:30 PM

You may not call main recursively, as you do in this program. In fact, this can probably overflow the stack if used repeatedly.

Using 'system' to call cls and pause is ugly, fragile, and a potential security vulnerability. (If I know that your program is run with elevated privileges, because it is used to encrypt certain files, then I can put a program with he name 'pause' or 'cls' in the same directory, and have that program be run instead of the one you intend; the titular vulnerability in the book The Cuckoo's Egg is very similar.)

You do not flush (by using std::endl instead of '\n' or otherwise) the output stream at times when you should - it is usually line-buffered, which is why it probably appears to work, but it does not have to be.

Function 'Base' has too many responsibilities and should be split up, separating input/output and actual computation.

You seed the random number generator far more often than you need or probably should do.

I'm not at all sure that you realize that fstreams use RAII.

---

I'm not trying to be mean, but XOR encryption is a pretty standard beginner task - it's also very impractical, which is why it's not generally used in the real world - and I thought feedback on your code would be more useful. All the same, good job for completing a project which someone is finding useful!
[TheUnbeliever]

#4 rnw159   Members   -  Reputation: 120

Like
-1Likes
Like

Posted 13 January 2012 - 08:35 PM

This was the first encryption software I ever made. I make games more often. I made it for a friend who wanted it real fast and couldn't tell any better. One of the reasons I don't post here very often is that when I do, I always get some guy who knows the area 100x better than I do and shoots down my work. Also, I just realized that the code is in the rar file. I did not mean to put it there.

Quote:

Original post by rnw159Screw game maker.

There's your sig quote for the forums :D[/quote]

#5 Bacterius   Crossbones+   -  Reputation: 8187

Like
1Likes
Like

Posted 13 January 2012 - 08:45 PM

The RAR is safe.

However I have to agree with TheUnbeliever, it's a very very basic encryption method. But as long as someone finds it useful it's not wasted time! And you also get to get feedback on other aspects of your project (such as the code, not just the underlying algorithm), which is probably more constructive.

And, as long as you warned your friend this isn't to be used for sensitive information, there's no shame in using XOR encryption to hide stuff away from nosy people on the computer. In fact I do it sometimes to play pranks on people (or deter them from looking into my filesystem).

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis


#6 TheUnbeliever   Members   -  Reputation: 957

Like
1Likes
Like

Posted 13 January 2012 - 08:51 PM

I didn't shoot down your work, I don't think that's a fair assessment. I pointed out errors, some of them fairly serious, none of which were specific to encryption beyond a single passing comment. I know it's hard having your work criticised, but I'm not coming out guns blazing, just offering you an opportunity to learn. You don't have to heed anything in my post, but if you want to develop your programming, I would recommend at least looking into some of the stuff I mentioned.
[TheUnbeliever]




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS