home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / lang / cplus / 13326 < prev    next >
Encoding:
Text File  |  1992-09-07  |  3.0 KB  |  57 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!mcsun!Germany.EU.net!ira.uka.de!slsvaat!us-es.sel.de!kanze
  3. From: kanze@us-es.sel.de (James Kanze)
  4. Subject: Re: ENCRYPTION OF DATA FILE ACCESSED BY MY C++ PROGRAM
  5. Message-ID: <1992Aug28.141631.12027@us-es.sel.de>
  6. Sender: news@us-es.sel.de
  7. Organization: SEL-Alcatel LTS Dept. US/ES
  8. References:  <1992Aug23.165130.15650@eagle.lerc.nasa.gov> <1992Aug27.184155.2111@us-es.sel.de>
  9. Date: Fri, 28 Aug 92 14:16:31 GMT
  10. Lines: 45
  11.  
  12. In article <1992Aug23.165130.15650@eagle.lerc.nasa.gov>, tostan@bert.lerc.nasa.gov (Stan Mohler) writes:
  13. |> 
  14. |> Hello Turbo C++ programmers.  I'm just learning C/C++, teaching myself on my
  15. |> PC with Turbo C++.  I want to write a program that reads a big data file,
  16. |> which I plan to create, and uses the info.  The data file will be very large,
  17. |> and will be contained on the disk with the program. 
  18. |> 
  19. |> But: when I sell this program, I don't want the buyer to be able to access 
  20. |> the accompanying data file's information EXCEPT through MY PROGRAM.  
  21. |> 
  22. |> It will take alot of effort to create this file.
  23. |> I want some way of encrypting it so that my C++ program can read it, decrypt
  24. |> the sentences in there, and display them in plain English.  Any ideas on
  25. |> how to do this?  I though of making up my own "ascii codes", and storing the
  26. |> characters as binary numbers decipherable by my own inveted table.  But I
  27. |> think that might be too easy to decrypt.  Any thoughts?  Thanks.  Note: I
  28. |> would also like to store images in some manner that no other program will be
  29. |> able to recreate the images but mine.  Any thoughts on that, too?
  30. |>  
  31. |> NOTE: OBVIOUSLY it will be possible for SOMEONE to decrypt the file.  Please
  32. |> don't waste my time telling me not the bother!  My objective is the MINIMIZE
  33. |> the ease of decryption, not make it impossible.  
  34.  
  35. Well, just compressing it will already do more encryption than a simple Ceasar
  36. code (which you suggest).  There are a couple of public domain encryption programs
  37. around; if you use one, of course, you'll want to modify it in some personal fashion.
  38. If not, anyone else with the same program will be able to read your files.
  39.  
  40. This also has the advantage of reducing the size of the file.  On the other hand,
  41. it doesn't allow random access, but then none of the good encryption schemes I
  42. know of do either.  It can also be a bit slow.
  43.  
  44. If this doesn't seem sufficient, x-oring the compressed output with (pseudo-)random
  45. sequence of numbers should make things more difficult.  For that matter, since the
  46. input is now apparently rather random, a Ceasar code might be sufficient.
  47.  
  48. Of course, anyone who really wants to can back-engineer your program to find out how
  49. you do it.  But that is a lot of work, especially if you use a lot of virtual
  50. functions (which make the control flow in the disassembled program particularly
  51. difficult to follow).
  52. --
  53. James Kanze                             GABI Software, Sarl.
  54. email: kanze@us-es.sel.de               8 rue du Faisan
  55.                                         67000 Strasbourg
  56.                                         France
  57.