OpenPGP library?

Dr. Evil drevil@sidereal.kz
Wed Aug 29 13:54:01 2001



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