encryption of Blast e-mail searches?

Reinhard Doelz doelz at comp.bioz.unibas.ch
Sun Aug 21 03:56:15 EST 1994

(Discussion issue was that BLAST may be accessed via encrypted mail 
message, and my earlier response mentioned that we use it in our 
Hierarchical Access System for Sequence Libraries in Europe (HASSLE)
as well. I apologize for the late reply). 

BIOSCI Administrator (biosci-help at NET.BIO.NET) wrote:

: Am I not correct in assuming that the query sequences have to be
: decoded at the server site prior to being run through the BLAST,
: HASSLE, or whatever program happens to be running on a server?

Correct - the encryption is _only_ for the transfer. 

: Doesn't this mean that anyone who is really determined could thus
: circumvent this security system by hacking into the computer on which
: the searches are running??

Correct - as soon as any untrusted person may possibly get access to 
the resource where the jobs run with the (at that time) undecrypted 
query the data are potentially unsecure. 

: If so, doesn't this mean that the security added by encryptation is
: primarily a safeguard against people possibly sending a query sequence
: to a wrong address on the net, etc., since anyone with the skill to
: intercept the message in transit would probably also be able to break
: into the computer doing the searches through the numerous operating
: system holes that are discovered repeatedly?

I cannot speak for the BLAST server, obviously, but the reason that our 
own protocol uses encryption is to have the usual triad of safety against
hackers, unauthorized access and abuse. It is hard to commit resources 
to 'anonymous', public access while not being able to control it.  We 
currently run the EMBL database GOPHER/WAIS server as an international 
resource, and encounter a large demand by many sites. If there were one 
which blocks the server for others due to an unscaled amount of queries 
this would cause possible shortages, and require that this demanding site 
purchases/installs their own server rather than using ours.  Not 
that I want to cut usage, but funding agencies, licenses of the software 
and local priorities might make it necessary to regulate the sequence 
of processing. E.g., three people sending one, ten, and 1000 queries at 
the wrong sequence might enjoy different degrees of satisfaction if the 
one-query submitter is queued as 1011. position. Simultaneously, downtime
and maintenance of the data might require temporary suspension, as a finite 
amount of time is required to validate new datasets. Last not least, HASSLE
also runs other services than plain 'searches', and some of these services 
(such as sequence database updating, for example) imply _WRITE_ access to 
the remote computer. I feel perfectly allowed to use encryption to meet 
those demands for our resource. Our encryption and accounting is published 
and available to everyone.  

: There obviously is a need to prevent people from sending their
: favorite top-secret query sequence to, e.g., the whole world by
: accidentally mailing to bionews at net.bio.net instead of to the blast
: server address, but, then again, are the users who are apt to know
: about encryption likely to be the ones to make this kind of mistake?!?

This is, unfortunately, a problem with mail servers. We happen to notice 
all the time that private messages are sent to large user groups because the 
'reply-to' field wasn't properly honored. Secondly, services which require
manual sequence assembly into a mail message are notoriously unsatisfactory
anyhow. I am not sure but assume that BLAST encryption can be applied seam-
lessly into an automatic procedure used by a mail encoding software. There
is this Mail Utility from Rainer Fuchs at the EMBL file server which surely
could be modified to do this. As HASSLE is non-eMail based, we do the en-
cryption on the fly and the user doesn't even notice. 

: Then, in conclusion, if this is a false sense of security, isn't this
: worry about losing it something of a non-issue??!!

Yes and no. I agree that, given the concerns of a 'reachable' end system, 
the use of encryption might pretend a higher security than is actually 

On the other hand, Internet is full of features which could make it possibly 
difficult to be attractive to 'serious' users. Noise reduction and similar 
moderation is always close to being put into a very paranoid corner (apart 
from flame wars and insults, we had a lot of 'semi-commercial' postings and
chain letters), but integrity of data and validity of services being offered
is becoming a very important issue. Encryption may help to ensure the in-
tegrity of a message in terms of that a truncated message will not unpack 
properly. Also, unintended, wrongly addressed mail will not be dangerous 
(i.e., revealing) to the sender. Last, 'faked' messages which are intended 
to be destructive can be ruled out with sufficient decryption.

Another issue is the idea that 'value-added' servers can go commercial 
(an idea which we currently do not anticipate, but commercialization of the 
Internet proceeds faster than we might be able to cope with). 'Public key'-
based systems are ideal to allow for a very reduced administrative effort. 
The unsolved questions with 'public keys' arise with the (necessarily world-
wide) authentication and its implications to individual organizations. This
issue is a bit too far away from bionet so readers might enjoy this topic 

: The question about export limitations on encryption software is a
: separate issue, of course, but in this application of encryption, I am
: concerned that the system may have enough holes in it to render the
: practice somewhat questionable.  I'd like to hear other opinions, of
: course.

I totally agree that this issue is primarily a non-bionet concern. 
As I feel the ongoing competition between US and European resources, though, 
let me expamd on my initial statement. 

Encryption software, if declared as 'standard', is a potential protection 
mechanism if the world-wide community cannot share the achievements. We 
purchased, some time ago, a book called 'Applied Cryptography' and the 
examples are printed in there, while it is prohibited that we get the 
diskette which is usually supplied with the book's purchase. So in 
principle there is no point that we cannot get the software (e.g., we 
could key it in manually), but we are not _allowed_ to do so, or use 
it in communications to the US if the aim of the software was to circumvent
export restrictions.

My point was that, in the US, there is an extremely healthy opinion on the 
freedom of communication. Any attempt to apply constraints, even if these 
are applied for the sake of a good matter, are being bombarded as measures 
of ugliness and anarchy. I do experience such a case elsewhere as we tried
to have a trouble-free scientific discussion, and a contributor from the US 
is rapidly turning temporary, regulative measures into a very negative,
personal, and certainly very undesired campaign. My point was that an 
encryption which is only legal in a given part of the world _might_ 
affect the 'peace' in biology, as we as Europeans might be in the position 
that we have to accept standards like the proposed encryption if we want 
to communicate with the US in a given framework, but are not allowed doing 
so due to the lacking permissions of encryption usage. Now as bionet and 
public servers are far apart from being 'sold', my concern was that in this 
arena the usage of proprietary (law-protected) encryption might cause 
undesired discussion on this sector as we want to be as open-minded as 


  |    Dr. Reinhard Doelz     | Tel. x41 61 2672247    Fax x41 61 2672078 |
  |      Biocomputing         | electronic Mail       doelz at urz.unibas.ch |
  |Biozentrum der Universitaet+-------------------------------------------+

More information about the Bio-soft mailing list

Send comments to us at biosci-help [At] net.bio.net