In article 2J0 at phibred.com, brookerg at phibred.com (Glenn Brooke) writes:
!> Can anyone please point me towards information about encrypting
!>BLAST e-mail searches? I'd also be interested in hearing from anyone
!>who is currently doing this. Thanks in advance,
!>
!>Glenn Brooke, Ph.D.
!>Pioneer Hi-Bred International, Inc.
!>brookerg at phibred.com
Glenn,
Follow a file that will give you all the informations you need to send
encrypted request to the NCBI BLAST e-mai server. If you need help or
more details please send your question to blast-help at ncbi.nlm.nih.gov
And as usual ... Happy BLASting !
The RIPEM encryption/decryption software is made available through
the courtesy of Mark Riordan and RSA Data Security, Inc. Please
abide by the licensing terms of the attached license in the file
'rsa.license' and by USA export regulations. Due to Federal export
restrictions on data encryption software, the RIPEM source code and
software may not be distributed outside of the U.S.A. and Canada.
RIPEM, and executables, as well as the NCBI BLAST E-mail Server's
public key, are available via anonymous ftp on ncbi.nlm.nih.gov beneath
the /pub/security directory.
=========================================================================
The NCBI BLAST E-mail Server's public key for use with RIPEM is
provided below. This key was generated at RIPEM's default key length of
516 bits, which is said in the RIPEM documentation to provide adequate
protection against cracking without generating too great a
computational load with the normal processes of message encryption and
decryption.
-----BEGIN PUBLIC KEY-----
User: blast at ncbi.nlm.nih.gov
PublicKeyInfo:
MFkwCgYEVQgBAQICAgADSwAwSAJBALNhtLagnbE1mJBRzN0uQ4diqsfA+qFHou3k
APj8nkAuEZD+xxR855Hoa/vlAlBXYrfdh8DvVCyycuAiaBI5vjMCAwEAAQ==
MD5OfPublicKey: FC3D8A47B82E30F259C92A43EAD94F67
-----END PUBLIC KEY-----
The RIPEM program should be used to generate a public key/private key
pair for the user. Any key length that RIPEM supports can be used for
the user's public key--it is not necessary to use a key of the same
length as the BLAST server's--but keys longer than the default 516 bits
may tax the BLAST server unnecessarily. Also note that the encryption
process produces cipher-text that is significantly larger than the
original clear-text, and longer keys yield a an even greater size
increase.
Users should compose their BLAST requests in the normal manner (e.g.,
starting with a PROGRAM directive), then individually encrypt and mail
each request to the BLAST server using the above public key.
RIPEM-encrypted messages should be sent to the normal BLAST server
address, blast at ncbi.nlm.nih.gov. RIPEM automatically prepends the
user's own public key to the encoded messages it creates; the BLAST
server will then use this public key to encrypt its response to the
user. The user's private key is then necessary to decrypt the BLAST
output.
Every message sent to the BLAST server's address is examined for
possible RIPEM cipher-text content. When BLAST requests are found to
be encrypted by RIPEM, the server encrypts the BLAST output before
sending it, using whatever public key was provided in the in-coming
RIPEM-encoded request. The BLAST server does not use any of the other
methods for obtaining users' public keys that RIPEM is capable of
providing (i.e., neither "finger", "file", nor "server" are used; see
the RIPEM documentation).
The procedures described above provide for privacy of mail messages
exchanged between users and the server, without incurring the overhead
and potential security problems of user key management on the server.
Proof of authenticity of the in-coming messages is not provided, but
this is not of concern to the BLAST server--the server presently does
not care who uses it.
To the BLAST server, a user's identity consists merely of their e-mail
address. What is difficult to prove with this system is that any
particular message to the server actually originated with the user or
from the address given in the message header, rather than from some
imposter. Since the BLAST server does not care who it communicates
with, however, the true identity of the user is irrelevant. All that
users should care about is that the messages that are exchanged with
the server are uncrackable and untamperable, which the present system
ensures.
Users will encrypt their requests using the BLAST server's public key
(see above), and the BLAST server will encrypt its output using
whatever public key is included with the user's request. It will be
technically infeasible for an eavesdropper to decrypt messages to or
from the server without knowing either the server's private key or the
user's private key, respectively. There is essentially no chance that
tampering of either the user's request or the server's response can go
undetected either, because RIPEM "signs" each message to guard against
unauthorized modification.
Spoofing a user into thinking they are communicating with the BLAST
server at the NCBI--which would be difficult to do even if secure
communications weren't being employed--becomes virtually impossible
with RIPEM, because any spoofed BLAST output that is to be believed
must contain the same query sequence as was sent (in encrypted form) by
the user.
---
Sincerely,
--
Herve RECIPON, PhD.
Blast Management Team.
__ __ __
/ \/ \/ \/1001001001 NCBI - NLM - NIH
\__/\__/\__/\ blastmgr at ncbi.nlm.nih.gov
1 / (301) 496-2475
========================================================================
For more details and advice on using BLAST programs, use Mosaic program
to :
http://www.ncbi.nlm.nih.gov/Recipon/index.html
And if you want to submit your sequence to GenBank, below are all the
data you need for a direct submission :
Authorin program request (indicate Mac or PC): authorin at ncbi.nlm.nih.gov
E-mail submission of new sequences: gb-sub at ncbi.nlm.nih.gov
E-mail submission of updates: update at ncbi.nlm.nih.gov
U.S. mail (for submissions on diskette, indicate whether Mac or PC):
GenBank Submissions
National Center for Biotechnology Information
Bldg. 38A, Room 8N-803
8600 Rockville Pike
Bethesda, MD 20894
=========================================================================
