The Open Crypto Engine (OCE) lets you use
different encryption packages on different operating systems in different
It's an API for encryption plugins with a CORBA interface. You can
also bypass CORBA to call the API directly.
There are reference implementation of plugins for Bouncy Castle, GPG,
and PGP. Tiger Envelopes is the reference implementation of an OCE
OCE is intended primarily for email and file encryption. It uses some
library files from Tiger.
Crypto package independent
- Supports Bouncy Castle, GPG, PGP
- For example you can choose PGP today, then instantly switch to
- Applications and encryption plugins can be in any major
- OCE itself happens to be in pure Java, but any language can use
Operating system independent
- Any major operating system
- Write your code once and choose from multiple encryption
- Your application and encryption plugins can be developed in any major
language and run on any major OS.
Makes layered encryption easy.
- If just one of the nested encryption packages works, it doesn't
matter as much whether the others do.
- Use different keys for each package in case one of them exposes
- For all applications that use OCE, encryption interface bugs can be
fixed in one place.
- OCE supports CORBA because SOAP explicitly bypasses firewalls
Rewards and risks
- CORBA provides extreme OS and language independence.
- But the risk of providing a network interface, no matter how well
protected, to secret key operations, and the security risks
associated with additional complexity, may not be worth it.
Developers using Java can get the benefits of OCE without the risks
- Dynamically, using the crypto.Plugin interface and
- Directly, importing GPGPlugin, PGPPlugin, etc.
- For users, interprocess comm probably should be an installation
choice with a default of "No".
- IIOP is easily blocked at the firewall
- Very well standardized
Fiercely platform independent
- Runs on any major OS
- Bindings for every major language
- Platform neutral Interface Definition Language
- IDL is intended to be read and written by humans
- Automatic code generation from IDL to many languages
- If you really need SOAP, there's bridge software. It's
also easy to write an application specific SOAP front end for
If IIOP does cross the firewall it's a major security risk
- No encryption
- CORBASEC with SSL exists, but does not have the same
support as IIOP
- This is much less important than it may appear.
Windows machines have almost no protection of any kind,
anyway. And since both KDE and GNOME on Linux already use
CORBA, OCE does not increase the existing risk on those
- Smaller mind share than XML/SOAP
- MS perceives CORBA as client-server, which helps Sun,
rather than peer-to-peer, which helps them.
CORBA is sometimes linked to the deadly word "legacy".
- There's support for COBOL and PL/1.
- The standards are only available in PDF, a format
designed for dead trees.
- Because of Microsoft's support, SOAP has a large
- SOAP on an alternative port is easily blocked at the
firewall, and if restricted to SSL it's fairly safe even if
it does cross the firewall
- SSL is trusted to protect money
SOAP was explicitly designed to easily slip through
firewalls. This is the last thing you want for your
- You don't want someone to easily forge your
signature, or read your most private messages.
- Nor do you want your passphrase wandering all over
- The best workaround is for the firewall to block some
HTTP based on the headers. Most firewalls can't.
- This is less important on an alternative port
- SOAP can use SSL, but there's little open source
No standard language bindings means no automatic code
- This is changing. De facto bindings for java
- Schemas only theoretically can be read and written by
humans. They are intended for automated parsing and
- SSL requires certs for servers
- Simple. Works.
- No standard use of SSL, but it's easy to do using the
Helma Java implementation.
- RMI is Java specific
- DCOM is just Microsoft's alternative to CORBA
Intended initial applications
- Email security
- File security
- Get signer
To be implemented later
- Get key
Get trust of key
You don't protect paper mail by sending it in a two ton
steel safe. You just wrap it in more paper, an envelope.
Even untrusted keys from public keyservers probably beat
this standard of security.
- Only "probably" because compromise of public key
servers can be automated
Possible trust metrics
Good reasons are
- You generated the key
- You verified the fingerprint by external
means such as voice
- Signed by a trusted key
- Shortest length of trust path from a trusted key
- Total trust in path, weighted by trust of
intermediate keys or of paths
- Add/Edit/Import/Export/etc. of key/keyring/etc. delegated to plugin,
since these objects are opaque.
Acts as a license firewall
- Between non-commercial encryption packages and other systems
- Isolates the effects of almost any package's license