home *** CD-ROM | disk | FTP | other *** search
/ Il CD di internet / CD.iso / SOURCE / CONTRIB / MBASE / MBASE50.TAR / mbase / dox / crypt.dox < prev    next >
Encoding:
Text File  |  1992-10-02  |  3.3 KB  |  68 lines
  1. Encryption Method                                                 MetalBase 5.0
  2. -------------------------------------------------------------------------------
  3.  
  4.   -- Note: This information is provided for your information alone, and --
  5.   -- is sufficient to crack the (rather simple) encryption method.  If  --
  6.   --  you are going to be encrypting sensitive data, please delete or   --
  7.   --               change the permissions on this file.                 --
  8.  
  9. Note that the encryption is apparently working for ALL supported machines
  10. now--however, this has always been the hardest part to port between machines.
  11. If necessary (or if you simply want to), compile mbase.c (and vr.c/sample.c/
  12. whatever) with -DNOENCRYPT, and it'll be turned off.
  13.  
  14. -------------------------------------------------------------------------------
  15.  
  16. If the user has specifed a nonzero key when calling mb_inc(), the following
  17. encryption operations take place at any necessary time before the next call
  18. to mb_rmv():
  19.  o  All records to be written are encrypted on a field-by-field basis
  20.  o  Records being read for return to the user are decrypted
  21.  o  Records being compared during an internal search are decrypted as needed
  22.  
  23. In this way, as long as mb_inc() is always called with the same key, programs
  24. will never see any effect of encryption--records passed to MetalBase routines
  25. are not encrypted by the user, and records returned from these routines are
  26. already decrypted.  However, the relation's data will be unintelligible if
  27. viewed using either an external file display utility or MetalBase routines
  28. which have not passed the proper key to mb_inc().
  29.  
  30. The key used for encryption is passed as an integer argument to mb_inc(),
  31. along with the relation name which is to be opened.  If this key is 0, no
  32. encryption will take place for that session (note that already-encrypted
  33. information will not be decrypted without the proper key--passing 0 is simply
  34. an alternative to encrypting the relation in the first place).  To facilitate
  35. matters, MetalBase 4.0 and up include the routine strtokey() to convert a text
  36. string to a key for mb_inc().
  37.  
  38. Encryption is performed as follows:
  39.  o During mb_inc(), the key passed in is converted to an 8-bit mask by
  40.      shuffling the bits around:
  41.         Bits 12345678  become bits  63417825
  42.    Okay, so it's not really useful.  So it places limits on portability, and
  43.    is generally ugly.  But hey--I always wanted an excuse to do some good
  44.    bit-shuffling...
  45.  
  46.  o When a record is encrypted or decrypted, each field is handled
  47.      individually.  This is because MB 4.0 originally used a memoried
  48.      encryption method; i.e., a byte's mask was dependent on that of the byte
  49.      before it.  Portability problems with uchars made a change to it before
  50.      the original 4.0 release, but the style is still the same.  In the
  51.      interests of speed, it is necessary to decrypt only indexed fields
  52.      during an internal search; thus, each field must be a starting point for
  53.      the algorithm.
  54.    To encrypt a field consisting of N bytes (be they for longs, strings,
  55.      or whatever):
  56.  
  57.      mask = relation.mask; (set by MetalBase during mb_inc())
  58.  
  59.      if (mask)
  60.         for (i=0; i<N; i++)
  61.          {
  62.            byte[i] ^= mask;
  63.            mask     = (mask+1) & (int)0xFF;
  64.          }
  65.  
  66.    Decryption uses the exact same routine.
  67.  
  68.