This project is read-only.

Security Risks

During Seal/Unsealing

During sealing/unsealing the library is only secure if the machine it runs on is secure. This means at least a quality and up to date anti-virus program a correctly configured network firewall. When a computer is used by multiple users (with different authorizations) extra security measures must be taken.

There are some resources on the computer that require some extra attention, these are described below.

Temporarily files

The Sealing and unsealing methods, with stream parameters, do temporarily store a file with the non-encrypted content into the temporary folder of the computer. It is up to application, not the ETEE-library, to adequately protect this directory. The application developer can also use the methods with byte array parameters instead then the non-encrypted content remains in memory.

Private keys

The private keys must be stored in an exportable manner. This means the private keys are potentially vulnerable to be stolen and be used by a non authorized person. It is the application, and not the ETEE-library, that is responsible for an adequate protection of private keys.


The memory allocated by the ETEE-library contains private information, including non encrypted versions of the private and secret keys. As always, it is the application and not the ETEE-library that is responsible to make sure non authorized persons can’t access the memory.

Resulting message

The sealed messages are secure. The messages may be available publicly, only authorized persons will be able to access the information inside it. The key identifier of unkown recipients may also be made available publicly. The key identifier is part of the un-encrypeted part of the message and therefore already available to everbody that has access to the sealed message.

The unsealed messages aren't secure at all, but that is why this library exists.

Last edited Nov 7, 2010 at 11:18 AM by egelke, version 1


No comments yet.