OpenPGP library?

[Dr. Evil]

> If you want a high performance solution you need to use the right
> tools.  GnuPG is not the silver bullet to all encryption or signing
> problems.

Alas, we have been waiting for a PGP library for years, and we may
have to wait for more years.  I am very ready to make OpenPGP a basis
for all kinds of authorization tasks, but I need to be able to
integrate it with various other tools.  I may need to do this at the
java layer, because there is a java OpenPGP implementation, but it's
not as good as GPG.

> > Also in the GPG FAQ it says stuff like "absolutely never use GPG over
> > a network".  This is ridiculous.  There is absolutely no such thing as
> 
> Expirience has shown that a lot of folks are using GnuPG in a way
> which renders any security achievable by GnupG worthless.  We have to
> care about the bulk of users and therefore it is justified to use
> stron words.

I think I'm one of those users: I use it exclusively on a remote
machine.  I have extremely good reasons for doing this; in fact, the
overall security threat would be much higher if I used it on a local
machine.  The security it gives me is not worthless, but it is
limited.  I know the limits of it.  The right decision for me is
different from the right decision for others.  In security, there is
often a tradeoff between usability and security, and the balance point
is determined by the value of the information which is being secured.

> > Anyway, enough ranting.  Security is very poorly understood by most
> > people who deal with it, and the idea of the "unversal security
> 
> and therefore it is justified to write software in a manner to reduce
> the risks.

No, not at all.  Not in the slightest.  Security software should be
written in a way which supports a broad range of uses, from research,
where no security is needed, to high security applications.  The
writer of general-purpose software like GPG doesn't know the value of
what is being secured, or what are the other components of the system
(OS, hardware, users), so he can't make decisions about how secure it
should be in actual use.  It is justified to write software in such a
way as to reduce the risks in the default installation.  If people
want to do things to turn off their security, they should be able to
go ahead and do it.  Anyone who knows enough to be able to link a
library into a piece of software should be able to make his own risk
decisions based on his threat model.  I know that if I link this in to
Postgres, and there is some big hole in Postgres, I have compromised
my encryption, and I'm willing to accept that.

> > policy" is one of the biggest misconceptions.  Any kind of built-in
> > security policy is based on the idea that there should be some kind of
> 
> There is no security police in GnuPG.  Well, there are some
> preconditions which are really necessary and I don't believe anyone
> would argue that one should support plain-DES, Skipjack or even use a
> redictable RNG.

Those are security policies.  Deciding to not have a library is a
policy.  Those policies may be wrong for some users.  If you are
saying that no one could argue that something should support
plain-DES, it means that you believe you know the security needs of
all your users.  You don't.  I could list a dozen reasons why, in some
cases, DES might be a better choice than AES, for instance.  Can you
think of some?

Let's put it this way: Cryptographicly, OpenSSL does exactly the same
things as GPG: It's a hybrid cryptosystem.  The difference is that
it's a library, so it gets linked in all over the place: into Apache,
into telnetd, even into databases for the command-line sessions.  This
is good; it results in widespread deployment of crypto, at different
security levels, for different users and applications.  It also
supports a wide range of different cryptosystems, including secure
ones such as AES and 3DES, low security ones such as DES, very low
security ones such as 40 bit DES, and even plaintext (ie, no
encryption).  Users with all kinds of different needs can link it into
all kinds of different projects, and that's great.  Right now I can
configure my Apache/SSL server to support only 40-bit DES or no
encryption at all if I want to.  I'm glad to have the choice.  The
same choice applies to SSH and ipsec, both of which support a wide
range of key sizes and encryption modes, from plaintext to AES.

Basically, I think you are thinking about GPG as a "mail encryption
tool to prevent tapping", and the current design is reasonable for
that use.  That's what Phil Z was originally thinking of, too.  But
public key crypto, such as GPG, can and should be used all over the
place, for a very broad range of applications.  It's unfortunate that
people only think of email when they think of PGP, because it has
resulted in software with needless constraints, and it has resulted in
the protocol being used much less than it could be.