(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
practiced.
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
elsewhere.
: 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
possible.
Regards
Reinhard
--
+---------------------------+-------------------------------------------+
| Dr. Reinhard Doelz | Tel. x41 61 2672247 Fax x41 61 2672078 |
| Biocomputing | electronic Mail doelz at urz.unibas.ch |
|Biozentrum der Universitaet+-------------------------------------------+
