home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / sci / crypt / 5617 < prev    next >
Encoding:
Internet Message Format  |  1992-12-12  |  2.3 KB

  1. Path: sparky!uunet!usc!wupost!cs.utexas.edu!sun-barr!ames!purdue!yuma!csn!news.uwyo.edu!jimkirk
  2. From: jimkirk@news.uwyo.edu
  3. Newsgroups: sci.crypt
  4. Subject: Crypto side-issues
  5. Message-ID: <1992Dec11.113730.356@news.uwyo.edu>
  6. Date: 11 Dec 92 11:37:30 MST
  7. Distribution: world
  8. Organization: University of Wyoming - Laramie, WY
  9. Lines: 39
  10.  
  11. I haven't seen any serious discussion here or in the literature on
  12. what I would term "side issues" of cryptography, those issues that
  13. are important but not directly related to algorithmic consideration:
  14.  
  15.   1.  The hardware in use includes several caches such as instruction
  16.       cache, data cache, and/or the disk controller has a cache.
  17.       This seems to be common on 486-based PCs for example.  How
  18.       can one "flush" the caches so there is no possibility of
  19.       sensitive data left in them?  How does one read the cache
  20.       so as to scrounge sensitive information?  Does flushing merely
  21.       mark the contents as invalid (still allowing reading by
  22.       diagnostic mode programs), or is there a way to forcefully
  23.       zero out the cache contents?  I don't accept the power switch
  24.       as an appropriate or fool-proof method.
  25.  
  26.   2.  Say I'm doing encryption/decryption on a workstation that is a
  27.       "diskless" workstation, and in the process some pages get
  28.       swapped over the ethernet, and a snooper captures the packets.
  29.       How to avoid?  (e.g. use a local disk for swapping; or in 
  30.       the program, lock down sensitive pages so no swapping occurs,
  31.       if the OS will allow this)
  32.  
  33.   3.  The run-time library for the language in which the crypto program
  34.       was written allocates output disk blocks, and fills them up to a
  35.       point, terminating with (say) control-Z to indicate logical
  36.       end-of-file, but leaving the rest of the last sector "dirty"
  37.       which happens to contain sensitive data because the corresponding
  38.       memory buffer had previously contained such data.
  39.  
  40.   4.  The program dynamically allocates storage, stores sensitive info,
  41.       and deallocates storage without clearing it.  Or, the same can
  42.       happen with static memory.
  43.  
  44. Are there any published (or unpublished!) guidelines or papers that address
  45. these issues?  They seem critical to the overall functioning of a crypto
  46. system, yet all I ever see are articles that concentrate merely on the
  47. algorithms.
  48.  
  49. Jim Kirkpatrick     jimkirk@corral.uwyo.edu
  50.