</programlisting>
  </para>
  <para>
   You need to use <function>dearmor()</function> on these keys before giving them to
   the PGP functions.  Or if you can handle binary data, you can drop
   <literal>-a</literal> from the command.
  </para>
  <para>
   For more details see <literal>man gpg</literal>,
   <ulink url="https://www.gnupg.org/gph/en/manual.html">The GNU
   Privacy Handbook</ulink> and other documentation on
   <ulink url="https://www.gnupg.org/"></ulink>.
  </para>
 </sect3>

 <sect3 id="pgcrypto-pgp-enc-funcs-limitations">
  <title>Limitations of PGP Code</title>

  <itemizedlist>
   <listitem>
    <para>
    No support for signing.  That also means that it is not checked
    whether the encryption subkey belongs to the master key.
    </para>
   </listitem>
   <listitem>
    <para>
    No support for encryption key as master key.  As such practice
    is generally discouraged, this should not be a problem.
    </para>
   </listitem>
   <listitem>
    <para>
    No support for several subkeys.  This may seem like a problem, as this
    is common practice.  On the other hand, you should not use your regular
    GPG/PGP keys with <filename>pgcrypto</filename>, but create new ones,
    as the usage scenario is rather different.
    </para>
   </listitem>
  </itemizedlist>
  </sect3>
 </sect2>

 <sect2 id="pgcrypto-raw-enc-funcs">
  <title>Raw Encryption Functions</title>

  <para>
   These functions only run a cipher over data; they don't have any advanced
   features of PGP encryption.  Therefore they have some major problems:
  </para>
  <orderedlist>
   <listitem>
    <para>
    They use user key directly as cipher key.
    </para>
   </listitem>
   <listitem>
    <para>
    They don't provide any integrity checking, to see
    if the encrypted data was modified.
    </para>
   </listitem>
   <listitem>
    <para>
    They expect that users manage all encryption parameters
    themselves, even IV.
    </para>
   </listitem>
   <listitem>
    <para>
    They don't handle text.
    </para>
   </listitem>
  </orderedlist>
  <para>
   So, with the introduction of PGP encryption, usage of raw
   encryption functions is discouraged.
  </para>

  <indexterm>
   <primary>encrypt</primary>
  </indexterm>

  <indexterm>
   <primary>decrypt</primary>
  </indexterm>

  <indexterm>
   <primary>encrypt_iv</primary>
  </indexterm>

  <indexterm>
   <primary>decrypt_iv</primary>
  </indexterm>

<synopsis>
encrypt(data bytea, key bytea, type text) returns bytea
decrypt(data bytea, key bytea, type text) returns bytea

encrypt_iv(data bytea, key bytea, iv bytea, type text) returns bytea
decrypt_iv(data bytea, key bytea, iv bytea, type text) returns bytea
</synopsis>

  <para>
   Encrypt/decrypt data using the cipher method specified by
   <parameter>type</parameter>.  The syntax of the
   <parameter>type</parameter> string is:

<synopsis>
<replaceable>algorithm</replaceable> <optional> <literal>-</literal> <replaceable>mode</replaceable> </optional> <optional> <literal>/pad:</literal> <replaceable>padding</replaceable> </optional>
</synopsis>
   where <replaceable>algorithm</replaceable> is one of:

  <itemizedlist>
   <listitem><para><literal>bf</literal> &mdash; Blowfish</para></listitem>
   <listitem><para><literal>aes</literal> &mdash; AES (Rijndael-128, -192 or -256)</para></listitem>
  </itemizedlist>
   and <replaceable>mode</replaceable> is one of:
  <itemizedlist>
   <listitem>
    <para>
    <literal>cbc</literal> &mdash; next block depends on previous (default)
    </para>
   </listitem>
   <listitem>
    <para>
    <literal>cfb</literal> &mdash; next block depends on previous encrypted block
    </para>
   </listitem>
   <listitem>
    <para>
    <literal>ecb</literal> &mdash; each block is encrypted separately (for
    testing only)
    </para>
   </listitem>
  </itemizedlist>
   and <replaceable>padding</replaceable> is one of:
  <itemizedlist>
   <listitem>
    <para>
    <literal>pkcs</literal> &mdash; data may be