On living with the 56-bit key length restriction

New Message Reply About this list Date view Thread view Subject view Author view

Mok-Kong Shen (mok-kong.shen@stud.uni-muenchen.de)
Wed, 23 Dec 1998 14:33:04 +0100


NOTE: The following is a revised (somewhat enlarged) version of
an article that I recently posted elsewhere.

In view of the recent decision by 33 countries (which comprise
the majority of those possessing the best know-how of science and
technology) to restrict the export of encryption software/hardware
with key lengths exceeding 56 bits, it seems likely that 56 bits
will in foreseeable future be the de-facto standard key length of
encryption of civilian communications of the entire world. (This is
because people outside of the 33 countries will only have 56-bit
hardware/software available to communicate either among themselves or
with people of the (crypto-)technically advanced countries.)

It is my humble personal opinion that this governmental decision is
very unfortunate, because it is factually a very strong blow on the
innocent honest law-obeying common people in respect of their private
communications, without on the other hand having any minute influence
on the activities of the criminals, terrorists and other sorts of
bad guys who can, with or without crypto regulations in force,
smuggle strong cryptos across country boundaries easily anyway and
then calandestinely employ these, using even secret dedicated
channels that are very difficult for the authorities to detect and
identify.

It is therefore of value that we scientists interested in cryptology
investigate ways that are eventually viable for the innocent citizens
to regain, as far as technically feasible, some degree of security
of their privacy in communications which the new restriction is aimed
to destroy. I am taking the liberty herewith to initiate discussions
on the topic with some familiar key items that I guess are among
those that could be relevant by the time when only 56-bit cryptos
are available to the general public:

1. Use of new algorithms specifically designed for the 56-bit
   restriction.

2. Superencipherment.

3. Cryptological multiplexing.

4. Employing multiple channels.

5. Steganography.

6. Homophones.

7. Date compression.

8. Using code books.

Recently I have (as a layman) designed a 56-bit data encrytion
algorithm WEAK3-EX, which has the property that the user can choose
a system configuration parameter such that the algorithm's
initialization time can be arbitrarily long. On the assumption that
brute force is the only viable method of attack, which is highly
likely the case if the user selects to use a sufficiently large number
of rounds of the algorithm, calculation shows that an initialization
time of, say three minutes (which should be tolerable in extreme cases
of necessity), would give rise to an average analysis time greater
than 2*10^11 years for the same hardware, thus easily catering for the
case that the analyst has an aboundant number of much faster processors.
While I don't yet have any evaluations of my design excepting the very
subjective one of myself, it can be well expected on the other hand
that experts of crypto will fairly soon invent 56-bit algorithms that
are highly secure and perhaps much much better than the humble design
of mine. (In the meantime I have also released WEAK2-EX, a very much
simplified version of WEAK3-EX, which is easily implementable though
less efficient than WEAK3-EX.)

If an algorithm is not so to say a 'group', then one can use several
modules of the same in concatenation similar to the triple-DES,
thus obtaining larger effective key lengths. Another way is to use
product ciphers comprising of different 56-bit algorithms that are
appropriate for combination. Besides thus putting algorithms in series,
one can also use the same algorithm (with different keys) in parallel,
i.e. with different keys for processing different sets of blocks of
the same message.

If there are several message streams, then I suppose it could be
beneficial to multiplex them in some way. Suppose there are two
records of the same length. One simple way is to take 4 bits from
each to form a byte and employ a polyalphabetic substitution on the
bytes thus obtained. Other methods can be easily conceived of. More
than two streams could be effectively combined in a binary tree
fashion. This might be interesting for a server that adds on some
security value to the ensemble of the messages it handles.

If multiple channels are available, a single message can be split in
some way and sent through different channels and maybe also at different
time points, i.e. non-synchron. This makes the identification of pieces
that belong to one and the same message difficult and hence renders the
analyst's job more formidable.

Steganography has been given attention since sometime in expectation
of the current crypto regulations. Most steganographical methods
presently in use employ graphics files but other file types could
also be advantagesously used (cf. a short article on my Web page).

Homophones belong to classical techniques and appears to be disfavoured
in modern times because of the efficiency issue. However, a homophone
mapping of say 8 bits to 12 or 16 bits and furthermore applied in a
manner akin to polyalphabetic substitutions could be a justifiable
method in view of the severe restriction on key length.

Data compression, going in the reverse direction to homophones in that
the volume of transmission is reduced, is regarded to have some
favourable effects in frequency distributions.

Employing specific code books could be very inconvenient for a number
of reasons. But an advantange of using code books is that it renders
frequency analysis hard. Code books also generally reduces the message
volume. What I have in mind presently concerns the case if there could
be a generally accepted (public) COMMON code book for English covering
a limited but practically useful vocabulary akin to the official
telegraphic code book of Chinese. One can use, e.g. the convention that
all nouns and verbs are coded in even numbers, with the immediately
higher odd numbers employed for plurals and past participles
respectively. This allows formulation of sentences that are well
understandable though not of good style or at places even not strictly
grammatically correct. Of course, the code numbers assigned to the words
have to be fairly randomly in order to aid defeating the usual frequency
analysis done by the analyst. It is conceivable that that a software
could efficiently do on-line encoding/decoding based on such a
standard code book.

The above are only some rather spontaneous thoughts of mine. Your
contributions on the topic are sincerely solicited.

Please confine however the discussions mainly to technical matters and
don't turn this thread into one for political debates.

M. K. Shen

------------------------------------------------------
M. K. Shen, Postfach 340238, D-80099 Muenchen, Germany
+49 (89) 831939 (6:00 GMT)
mok-kong.shen@stud.uni-muenchen.de
http://www.stud.uni-muenchen.de/~mok-kong.shen/
(Last updated: 22nd December 1998. Origin site of
WEAK2-EX -- A Poorman's 56-bit Data Encryption Algorithm. (22 Dec 98)
WEAK3-EX -- A Layman's 56-bit Data Encryption Algorithm. (22 Dec 98)
Containing 2 mathematical problems with rewards totalling US$500.)


New Message Reply About this list Date view Thread view Subject view Author view

 
All trademarks and copyrights are the property of their respective owners.

Other Directory Sites: SeekWonder | Directory Owners Forum

The following archive was created by hippie-mail 7.98617-22 on Sat Apr 10 1999 - 01:17:38