Rolling out the new clients

Dan Oetting (oetting@gldfs.cr.usgs.gov)
Mon, 5 May 1997 00:14:25 -0600


It's disappointing that the rate that new clients are developed and
released is not much higher. I attribute this primarily to the fact that
the client software is proprietary and so there are only a few programmers
working part time on new releases. The task of porting the client code to
new operating systems and optimizing the encryption engine for each cpu
could easily be distributed without compromising the search.

The client program can be divided into 3 parts with different requirements
for system dependency, security and optimization. The client shell contains
all the system dependent code and handles all communications, user
interaction and scheduling. The security unit contains all the proprietary
security code for decoding the request parameters and encoding the result.
The encryption engine contains the code that needs to be optimized for each
cpu.

The client shell contains the bulk of the client code and will require the
most effort in porting to a new platform. Fortunately the source for the
client shell could be made public so porting to new clients can be a widely
distributed process. The client shells are independent of the challenge
being processed so they will be ready for the next challenge once DES is
crushed.

The security unit is system and hardware independent so only one version is
required for each challenge. Since the security of the search effort
depends on proprietary encoding and decoding functions the source code
should not be released. Although a reference version without the security
functions could be made available for testing. The security unit will be
accessed with a single function call to pass the starting address and block
size. A periodic callback to check_input allows the client shell to check
activity and update displays while the search is processing. The callback
rate should be adjusted by the client shell. The security unit would also
have full control of the encryption engine.

The encryption engine would benefit most from optimization. Although the
encryption engine is system independent optimization would be cpu specific.
A reference version of the encryption engine in standard C should be made
available (subject to export restrictions of course). The reference version
could be used in new clients until the optimized versions are available.

Under this scenario development of new clients could be a distributed
effort requiring the core teem only to verify, compile and test the final
versions.

-- Dan Oetting <oetting@gldfs.cr.usgs.gov>