Re: Using Encryption Patch to Docs

I have reworded some of the encryption sections in this patch and
applied the changes:

	http://candle.pha.pa.us/main/writings/pgsql/sgml/encryption-approaches.html

I moved the section up a few sections, changes the markup a little, and
removed the encryption FAQ item now that we have a clearer encryption
section.

---------------------------------------------------------------------------

pgman wrote:
> 
> Patch applied.  Thanks.  Your documentation changes can be viewed in
> five minutes using links on the developer's page,
> http://www.postgresql.org/developer/testing.
> 
> 
> ---------------------------------------------------------------------------
> 
> 
> Christopher Browne wrote:
> > ? out
> > Index: runtime.sgml
> > ===================================================================
> > RCS file: /projects/cvsroot/pgsql/doc/src/sgml/runtime.sgml,v
> > retrieving revision 1.315
> > diff -u -r1.315 runtime.sgml
> > --- runtime.sgml	23 Apr 2005 03:27:40 -0000	1.315
> > +++ runtime.sgml	29 Apr 2005 16:43:22 -0000
> > @@ -5109,6 +5109,132 @@
> >  
> >   
> >  
> > + 
> > +   Use of Encryption in <productname>PostgreSQL</productname>
> > +   
> > +    encryption
> > +   
> > +
> > +    There is increasing interest in having verifiable mechanisms
> > +    to maintain the privacy of data in databases.  In the United
> > +    States, legislation called HIPAA (Health
> > +    Insurance Portability and Accountability Act) requires that
> > +    personal health information is handled securely.  The European
> > +    Union has similarly been developing directives as to how personal
> > +    data is to be managed there.
> > +   
> > +    Questions frequently come up as to what functionality
> > +    PostgreSQL offers with regard to
> > +    supporting the use of data encryption.  It uses and provides use of
> > +    encryption tools in several ways that may be useful to provide
> > +    protection against certain classes of attacks.
> > +   
> > +   
> > +
> > +     Passwords stored in MD5 form 
> > +
> > +      Passwords are normally not stored in
> > +      plaintext form in the database; they are hashed
> > +      using the built-in MD5 function, and that is
> > +      what is stored in the database.  
> > +     
> > +
> > +sample=# alter user foo password 'some dumb value';
> > +ALTER USER
> > +sample=# select usename, passwd from pg_shadow where usename = 'foo';
> > + usename |               passwd                
> > +---------+-------------------------------------
> > + foo     | md5740daa4aaa084d85eb97648084a43bbb
> > +(1 row)
> > +
> > +
> > +
> > +
> > +     Connections protected using SSL
> > +
> > +       There are various options to control how mandatory it is
> > +      to use SSL to protect data connections.  At the most
> > +      paranoid end of the spectrum, you can configure
> > +      pg_hba.conf to have the database reject
> > +      connections that do not come in via
> > +      SSL.
> > +
> > +       The use of SSL, alone, is useful for protecting
> > +      communications against interception.  It may not be necessary
> > +      for connections that take place across a carefully controlled
> > +      network; if connections are coming in from less controlled
> > +      sources, its use is highly recommended.
> > +
> > +     Connections authenticated using SSL
> > +
> > +      It is possible for both the client and server to provide
> > +      to one another SSL keys or certificates.  It takes some extra
> > +      configuration on each side where these are used, but this likely
> > +      provides stronger verification of identity than the mere use of a
> > +      text password. 
> > +
> > +     Using OS level encryption for entire database
> > +      partitions
> > +
> > +      On Linux, encryption can be layered on top of a filesystem
> > +      mount using what is called a loopback device; this
> > +      permits having a whole filesystem partition be encrypted on disk,
> > +      decrypted by the operating system.  On FreeBSD, the equivalent
> > +      facility is called GEOM Based Disk Encryption, or
> > +      gbde.
> > +
> > +      This mechanism may be expected to be useful for protecting
> > +      against the threat that someone might pull disk drives out and
> > +      try to install them somewhere else to draw data off of them.
> > +     
> > +
> > +      In contrast, this mechanism does nothing to protect
> > +      against attacks when the filesystem is mounted, because when
> > +      mounted, the OS provides a view of the filesystem
> > +      accessible in plain text form.  Furthermore, you need some way
> > +      for the encryption key to be passed to the operating system in
> > +      order to mount the filesystems, which encourages having the key
> > +      accessible somewhere on the host that mounts the disk.
> > +     
> > +
> > +     Using the contrib function library
> > +      pgcrypto so the database engine manages
> > +      encryption of certain fields.
> > +
> > +     If much of the data can be in plain text form, and only a
> > +      subset is particularly sensitive, this mechanism supports
> > +      treating them differently.  The encrypted data is only ever
> > +      presented in unencrypted form while it is being
> > +      communicated between client and server, and the use of an SSL
> > +      layer of superencryption alleviates that
> > +      problem.
> > +     
> > +      Unfortunately, in this approach, the encryption keys need
> > +      to be present on the server, even if only for a moment, which
> > +      presents the possibility of them being intercepted by someone
> > +      with access to the database server.  As a result, this mechanism
> > +      is not suitable for storage of data that is too sensitive for
> > +      system administrators to have access to it. 
> > +
> > +     Using cryptographic tools on the client 
> > +
> > +      If it is not safe to trust the system administrators at
> > +      least somewhat, you may find it necessary to encrypt data at the
> > +      client level such that unencrypted data never appears on the
> > +      database server.  This sort of paranoia is quite
> > +      appropriate for applications where it would be damaging for data
> > +      to be seen by inappropriate readers that might generally be
> > +      considered trustworthy, as can be the case with
> > +      medical and legal records.
> > +
> > +      Peter Wayner's book, Translucent
> > +       Databases, discusses how to do this in considerable
> > +      detail.
> > +
> > +   
> > +
> > +  
> > +
> >  
> >  
> >