home *** CD-ROM | disk | FTP | other *** search
/ Il CD di internet / CD.iso / SOURCE / CONTRIB / MBASE / MBASE51.TAR / mbase51 / tech / chapter.4 < prev    next >
Encoding:
Text File  |  1993-09-04  |  3.7 KB  |  75 lines
  1. Tech Chapter 4 - Encryption                                       MetalBase 5.1
  2. -------------------------------------------------------------------------------
  3.  
  4. NOTE:  This information is provided for the database administrator only, and
  5.        is sufficient to decode the (rather simple) encryption method.  If you
  6.        are going to be encrypting sensitive data, you should delete or change
  7.        the permissions on this file.
  8.  
  9. Encryption is apparently working for all machines now--however, this has always
  10.    been the hardest part to port between machines.  If necessary (or if you
  11.    simply want to), compile the library (and vr.c/whatever) with -DNO_ENCRYPT,
  12.    and it'll be turned off entirely.  Please contact me (see the chapter on
  13.    technical support in the ../DOX directory) if encryption does not work on
  14.    your machine, so I can fix the problem.
  15.  
  16. -------------------------------------------------------------------------------
  17.  
  18. When encryption is active in a relation, the following operations take place
  19.    at any necessary time:
  20.  
  21.    - All records to be written are encrypted on a field-by-field basis before
  22.         the write takes place
  23.    - Records being compared during an internal search are decrypted before
  24.         being compared
  25.    - Records being read for return to the user are decrypted after being read
  26.  
  27. In this way, as long as mb_inc() is always called with the same key, programs
  28.    will never see any effect of encryption--records passed to MetalBase
  29.    routines are not encrypted by the user, and records returned from these
  30.    routines are already decrypted.  However, the relation's data will be
  31.    unintelligible if viewed using either an external file display utility or
  32.    MetalBase routines which have not passed the proper key to mb_inc().
  33.  
  34.  
  35. When the user specifies a string as an encryption key for mb_inc(), the string
  36.    is hashed to return an integer; that integer is cast to a character and the
  37.    bits scrambled to obtain a single-character starting mask.  If a non-NULL
  38.    string is passed in, the starting mask is guaranteed to never be zero... it
  39.    is this mask which is stored in the relation, and verified before mb_inc()
  40.    will proceed.  This mask is also stored in the relation data structure
  41.    returned to the process which calls mb_inc(); if the user calls mb_inc()
  42.    with "" or NULL, 0 is stored in both places.
  43.  
  44. If this key is 0, no encryption will take place for that session (note that
  45.    already-encrypted information will not be decrypted without the proper
  46.    key--passing 0 is simply an alternative to encrypting the relation in the
  47.    first place).
  48.  
  49. When a record is encrypted or decrypted, each field is handled individually.
  50.    This is because MB 4.0 originally used a memoried encryption method; i.e.,
  51.    a byte's mask was dependent on the value of the byte before it.  Portability
  52.    problems with uchars forced a change to it before the original 4.0 release,
  53.    but the style is still the same.  In the interests of speed, it is necessary
  54.    to decrypt only indexed fields during an internal search; thus, each field
  55.    must be a starting point for the algorithm.
  56.  
  57. To encrypt a field consisting of N bytes (be they for longs, strings, or
  58.    whatever):
  59.  
  60.      if ((mask = relation.mask) != 0)   // set by MetalBase during mb_inc()
  61.         {
  62.         for (i = 0; i < N; i++)
  63.            {
  64.            data[i] ^= mask;
  65.            mask = (mask+1) & (int)0xFF;
  66.            }
  67.         }
  68.  
  69. Decryption uses the exact same routine.  Note that field types T_MCHAR and
  70.    T_MBYTE are not encrypted, as the sensitive information isn't stored at
  71.    that point.  Instead, it is expected that the compression algorithm used
  72.    will sufficiently hide the relevant text; see the chapter on Compression
  73.    for a more detailed explanation of the scheme used.
  74.  
  75.