Technnical Description
-- Privacy is Key -- |
Technical Description |
| [ Home ] [ Technical Description ] [ Encryption Strategies ] [ Advancement ] [ Uncertainty ] [ 1996 ] |
[ Home ]
[ Next ]
|
Technical Description of Crypt Software
History
Trantor has been developing software for private encryption since 1994. Prior to that time, the developer created encryption software for a Canadian Bank (Royal Bank) in 1988. That encryption software was in daily use by more than 500 users for about six years until the system was retired in 1995. During its years of operation no bugs were reported and the system was never compromised.
In 1996 Trantor developed an Alpha prototype entitled Crypt, for which the company received grant money from the Canadian Government. Trantor developed a beta-version of the program the following year, expecting commercial distribution post beta-testing. It was intended for the novice internet user, but at that time (and perhaps now) novice users were simply not interested in securing their data with such a system. Commercial distribution was to be taken in early 1998, but the we decided that the financial risk was too great for a small company.
We did not pursue sale of the product to another company for two reasons: 1) We did not feel that we had the software at a sufficient state of readiness to be viable for sale. 2) The code was (and is) related to ongoing research into data compression.
This current description is for work that was done on Crypt from its design in August 1994 to an Alpha prototype, completed in August of 1996. We have left it un-edited, so you may find what is now the past is spoken of in the present tense.
Technical Objectives
Trantor has lately recognized the explosive number of internet users (mostly novices) and the massive movement of data across the ‘net. Data security will become one of *the* hot topics of the coming years as more and more users recognize how insecure their communications over the internet are. One of the things that will likely become a tool used by everyone is some type of encryption robot that will package communications for secure point-to-point transmission.
When a message is sent across the internet, it travels from one computer to other computers on the network. Two types of computers in particular, **mail servers** **and mail gateways** are required to forward information across the network. While messages reside at these machines they are available for inspection and interception.

Encryption protects messages by making them unreadable as they cross the network. The file is effectively no longer available for inspection.

There are any number of encryption schemes available at this time but they all have certain weaknesses. These weaknesses must be addressed by the encryption and programming communities.
Trantor is developing an encryption device that, as far as we know from preliminary tests, deals with the following weaknesses in available encryption schemes, and with data security in general:
Encryption Algorithms
Encryption algorithms are the formulas for encrypting data. A variety of strong encryption algorithms have been published. The prevailing wisdom in the cryptography community is that publication and peer verification of the strength of encryption algorithms is the best insurance against attack by cryptanalysts. This idea certainly has merit in most disciplines, but cryptography is peculiar in that its aim is to obscure information. Published algorithms used for extended periods of time offer additional incentive and opportunity to be defeated. We believe that the obscurity of the algorithm used **does** offer some protection, hence we allow for any and all algorithms (published and unpublished) to be used with our software. We have architected our software to allow the use of any encryption method as a plug-in, something that has not previously existed in encryption devices. Even relatively weak algorithms can provide safety if they require particular analysis on their own. When coupled with cryptographically strong algorithms, additional complexity can increase the cost of an attack to the point that the attacker will turn their attentions elsewhere.
We have attempted to architect our software to allow ongoing changes to the underlying encryption algorithms. Thus far we believe we have accomplished this although further testing must be conducted. We provide a simple, extensible framework with unlimited encryption techniques. Individuals (or groups, companies, etc.) with the highest security needs may develop their own proprietary encryption, while still having access to the common framework. We feel that focusing effort on a particular single algorithm is an unnecessary vulnerability and our efforts have addressed this concern.
Length of Key
The best encryption algorithms will make the entire ciphertext dependent upon the entire key. Furthermore, the ciphertext will bear no discernible relationship to either the original plaintext or the key. The holy grail of encryption is to find an algorithm sufficiently powerful to reduce cryptanalysis to no better than a guess. Given that you know the algorithm, have access to plaintext, corresponding ciphertext and keys, the **ideal** algorithm would be invulnerable to attack such that an $n$ bit key would take $2^{(n-1)}$ trials on average to discover a given key. Even for modest key lengths, such an algorithm could provide perfect security. For various reasons, not the least of which have been U.S. export restrictions on encryption software, available key lengths have been on the order of 40 to 100 bits. This is an inherent weakness. Even using the ideal algorithm above, a 16 bit key would take only $2^{15}$ key trials on average to discover the key. This is a trivial undertaking on a modern home computer.
Without regard to the strength of the encryption algorithm, ciphertext can be rendered provably secure provided that the length of the key exceeds the length of the plaintext and the key is discarded once it is used (a so-called ‘one time pad’). We have architected our software to allow **arbitrary key lengths, arbitrary password lengths, and arbitrary mask lengths** (which act as one time pads). For our own encryption methods, a practical limit on key lengths is on the order of many thousands of bits, limited only by processing power.

For one-time pads, our architecture supports masks whose length is limited only by available disk storage.
Processing power/time
One of the assumptions underlying much encryption software is that increases in computing power and analysis techniques can be predicted. This has lead to a practice of setting arbitrary limits on keys, pass phrases, digest lengths, etc. These limits have traditionally been thought good enough. We feel that it is an inherent weakness in existing encryption practice that software is not built to scale-up automatically. Our architecture allows our encryption to scale-up as appropriate, without arbitrary limits. It is one of our design points to address increasing power, including sudden unexpected increases. Note that it is not necessary that this increased power be actual. There is always a processing/storage trade-off. It could be that a saltatory virtual increase in cryptographic attack strength might be realized by way of novel storage methods for instance. Our architecture is designed to allow the software to scale up its processing to meet the abilities of the two parties to an exchange.
Usability
Current encryption programs are not readily usable by a wide audience. A program is required that allows for simple cut and paste operations to encrypt notes for forwarding via e-mail. Menu options that encrypt files and e-mail attachments, and a method for generating and maintaining a database of private keys and passwords, would increase the program’s utility to the novice user. We have created a working prototype of such a program and are continuing to refine our thinking through a limited Alpha test.
Program Features
To date Trantor’s Crypt program has incorporated the following features and appears to be functioning in very limited tests: Windows 3.1/NT/95 Alpha test program (currently in testing as version 00.00.11). This program allows users to send ‘shrouded’ messages and encrypted files across the internet.
The program allows key lengths up to 65536 bits, passwords up to 1024 bytes, and unlimited length masks. Software includes ‘key manager’, ‘user manager’ and ‘password manager’ components that simplify the use of the encryption. Encrypted messages contain sufficient information about their origin to allow the program to automatically decrypt messages and files for which the operator has valid keys and passwords.
The Alpha distribution consists of a user shell written in Microsoft Visual Basic Version 4.0, Dynamic Link Library (DLL) routines written in Microsoft ‘C++’, Version 7.0 and ‘plug’ libraries and programs written in C. The entire source for the distribution code is approximately 15,000 lines of code (BASIC and C).
| Questions or comments? Send mail to webmaster@hushserver.com. | Copyright 2000 HushServer Division Site was Last modified: January 07, 2000 | ![]() |
-- Privacy is Key --

Comments
Post a Comment