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 @@

</sect1>

+ <sect1 id="encryption-approaches">
+   <title>Use of Encryption in <productname>PostgreSQL</productname></title>
+   <indexterm zone="encryption-approaches">
+    <primary>encryption</primary>
+   </indexterm>
+
+   <para> There is increasing interest in having verifiable mechanisms
+    to maintain the privacy of data in databases.  In the United
+    States, legislation called <acronym>HIPAA</acronym> (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.</para>
+   
+   <para> Questions frequently come up as to what functionality
+    <productname>PostgreSQL</productname> 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.</para>
+   
+   <itemizedlist>
+
+    <listitem><para> Passwords stored in MD5 form </para>
+
+     <para> Passwords are normally not stored in
+      <quote>plaintext</quote> form in the database; they are hashed
+      using the built-in MD5 function, and <emphasis>that</emphasis> is
+      what is stored in the database.  </para>
+     
+<programlisting>
+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)
+</programlisting>
+
+</listitem>
+
+    <listitem><para> Connections protected using SSL</para>
+
+      <para> There are various options to control how mandatory it is
+      to use SSL to protect data connections.  At the most
+      <quote>paranoid</quote> end of the spectrum, you can configure
+      <filename>pg_hba.conf</filename> to have the database reject
+      connections that do <emphasis>not</emphasis> come in via
+      SSL.</para>
+
+      <para> 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.</para></listitem>
+
+    <listitem><para> Connections authenticated using SSL</para>
+
+     <para> 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. </para></listitem>
+
+    <listitem><para> Using OS level encryption for entire database
+      partitions</para>
+
+     <para> On Linux, encryption can be layered on top of a filesystem
+      mount using what is called a <quote>loopback device;</quote> 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
+      <acronym>gbde</acronym>.</para>
+
+     <para> 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.
+     </para>
+
+     <para> In contrast, this mechanism does nothing to protect
+      against attacks when the filesystem is mounted, because when
+      mounted, the OS provides a <quote>view</quote> 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.
+     </para></listitem>
+
+    <listitem><para> Using the contrib function library
+      <function>pgcrypto</function> so the database engine manages
+      encryption of certain fields.</para>
+
+     <para>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 <quote>unencrypted</quote> form while it is being
+      communicated between client and server, and the use of an SSL
+      layer of <quote>superencryption</quote> alleviates that
+      problem.</para>
+     
+     <para> 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. </para></listitem>
+
+    <listitem><para> Using cryptographic tools on the client </para>
+
+     <para> 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 <quote>paranoia</quote> 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.</para>
+
+     <para> Peter Wayner's book, <citation>Translucent
+       Databases</citation>, discusses how to do this in considerable
+      detail.</para></listitem>
+
+   </itemizedlist>
+
+  </sect1>
+
</chapter>

<!-- Keep this comment at the end of the file

-- 
Bruce Momjian                        |  http://candle.pha.pa.us
pgman@candle.pha.pa.us               |  (610) 359-1001
+  If your life is a hard drive,     |  13 Roberts Road
+  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073