Envelope Mail's exact format hasn't been decided on yet. What's needed is an implementation of the following API which performs 'adequately', has a 'reasonable' security margin, isn't encumbered by patents, and can be easily coded using public domain libraries -

Seeds are 112 bits long, to make key encoding clean.

This API is not parameterized by key length - standardizing on one which will last the next 30 years is fine.

Since no implementation of this API is forthcoming, a dummy one is being used for now.

Below are explanations of all the features in this API, each new one is marked in bold.

Here is an unacceptably minimal encryption/decryption API

We want encyption to multiple public keys, so the sender can read a message later as well

An extra method to get the public keys encypted avoids having to try every private key available.

Since the private keys probably won't be short enough to write down easily (around 128 bits), they should be derived from a seed which is.

Including the whole public key in the ciphertext is an unnecessary waste of resources, so only an identifier should be used

It makes sense for random seed generation to be part of the crypto API as well

Back to index