Cryptography-Digest Digest #192, Volume #12 Mon, 10 Jul 00 10:13:01 EDT
Contents:
Re: Has RSADSI Lost their mind? (Mark Wooding)
Re: Proposal of some processor instructions for cryptographical (Runu Knips)
Re: [Q] Serpent: Gladman Code incomplete ? (Mark Wooding)
Rijndael key schedule question (Dido Sevilla)
Re: [Q] Serpent: Gladman Code incomplete ? (Dido Sevilla)
Re: [Q] Serpent: Gladman Code incomplete ? (Runu Knips)
Re: Proposal of some processor instructions for cryptographical (Konrad Schwarz)
Re: Proposal of some processor instructions for cryptographical (Runu Knips)
Re: Suggestions for crypto for constrained-memory/CPU computers? (Mark Wooding)
Re: Random Numbers (John Savard)
Re: Advanced Cryptography FAQ (John Savard)
Re: Compression & Encryption in FISHYLAND (John Savard)
Re: Proposal of some processor instructions for cryptographical applications (Bruce
Hoult)
#sci.crypt irc channel (csybrandy)
key dependent s-boxes (Vladimir Castro Alves)
Re: SecurID crypto (was "one time passwords and RADIUS") ("Trevor L. Jackson, III")
Re: Rijndael key schedule question (Mark Wooding)
tokens and vpns ( was:Re: SecurID crypto (was "one time passwords and RADIUS")
(Padgett 0sirius)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Has RSADSI Lost their mind?
Date: 10 Jul 2000 09:59:41 GMT
Bill Unruh <[EMAIL PROTECTED]> wrote:
> If you are in the USA, then you fall under US patent law. As such you
> have the five choices.
[...]
> e) Rewrite OpenSSL to use DH/ElGammel key exchange ( but ov course
> then you would not be in compliance with SSL)
Alternatively, use ephemeral Diffie-Hellman with DSA authentication,
which has been in SSL for ages. (And I wish more people would use it:
the forward secrecy properties of Diffie-Hellman are a major benefit.)
-- [mdw]
------------------------------
Date: Mon, 10 Jul 2000 12:11:29 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical
Thomas Womack wrote:
> "Mok-Kong Shen" <[EMAIL PROTECTED]> wrote
> > Transposition is one of the basic operations in cryptography.
> Is it, any more? Having a look at the AES candidates, most of them carefully
> refrain from calling for bit transpositions simply because they're rather
> hard to implement.
Rotations are bit permutations, too, therefore you're simply wrong.
And, well, Serpent contains a really complex initial (and final)
bit permutation, even if I don't understand whats the use for it,
except that the cipher is seriously slowed down in software.
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: [Q] Serpent: Gladman Code incomplete ?
Date: 10 Jul 2000 10:18:05 GMT
Runu Knips <[EMAIL PROTECTED]> wrote:
> Last weekend I have studied the Serpent paper, and was surprised how
> easy to understand and elegant this cipher is, even if I missed some
> of the very basic features of a cipher description in it, meaning test
> vectors and at least an idea how to implement the cipher in software.
>
> I also read the Serpent implementation of Brian Gladman
> (http://www.btinternet.com/~brian.gladman/cryptography_technology/aes/serpent.c),
> but what I don't understand is the fact that Serpent defines an
> initial and final bit transformation (called IP and FP in the paper),
> which are not implemented in the cipher of Mr. Gladman. So is it true
> that Mr. Gladman's implementation is in fact incomplete ?
No. You've misunderstood the description.
There are actually two ways of looking at Serpent. The first one is the
`traditional' approach, where you do the initial permutation, and then
do 32 rounds of key mixing, push each group of four bits through S-boxes
and then do a hairy linear transformation.
In the traditional view, we have four 32-bit words, a, b, c, d. Here's
a diagram, labelling the bits (after the initial permutation).
a_0 a_1 a_2 a_3 a_4 a_5 a_6 a_7 ... a_{28} a_{29} a_{30} a_{31}
b_0 b_1 b_2 b_3 b_4 b_5 b_6 b_7 ... b_{28} b_{29} b_{30} b_{31}
c_0 c_1 c_2 c_3 c_4 c_5 c_6 c_7 ... c_{28} c_{29} c_{30} c_{31}
d_0 d_1 d_2 d_3 d_4 d_5 d_6 d_7 ... d_{28} d_{29} d_{30} d_{31}
Each block of four bits a_0 a_1 a_2 a_3 gets pushed through an S-box.
That's easy, but deadly slow because that's 32 separate S-box lookups to
do every round. Bleugh.
There's an alternative to doing the initial permutation, though.
Instead of moving all of the bits around, we can leave the bits exactly
where they are and move the rest of the world around instead. What we
have is
a_0 a_4 a_8 a_{12} ... d_{16} d_{20} d_{24} d_{28}
a_1 a_5 a_9 a_{13} ... d_{17} d_{21} d_{25} d_{29}
a_2 a_6 a_{10} a_{14} ... d_{18} d_{22} d_{26} d_{30}
a_3 a_7 a_{11} a_{15} ... d_{19} d_{23} d_{27} d_{31}
Notice that the four bits going to each S-box, instead of being adjacent
in a word, are now written across all four words but in the same bit
position. We can now do all 32 S-box operations in parallel, by doing
some hairy bitwise logic operations between the four words which
actually do the same thing as the S-boxes. There are some good papers
on the subject of choosing the logical operations with which the S-boxes
should be implemented: there's one which was presented to AES3, which I
use in my version.
It's this `bitslice' view of the world in which the cipher is actually
intended to be used. The linear transformation is much simpler in this
view, and we don't need to do the initial and final permutations.
Does this help?
-- [mdw]
------------------------------
From: Dido Sevilla <[EMAIL PROTECTED]>
Subject: Rijndael key schedule question
Date: Mon, 10 Jul 2000 18:12:04 +0800
I finally have a fast, working implementation of Rijndael in 80186
assembly language, but I just noticed something odd while looking over
its description in the AES pages. It seems that the AES page describing
Rijndael says that the key schedules for Rijndael encryption and
decryption are different. However, I don't find anything in the
Rijndael specification papers or even in the sample code Vincent Rijmen
provides on his website that says the key schedules are different. What
does that mean?
--
Rafael R. Sevilla <[EMAIL PROTECTED]> +63 (2) 4342217
ICSM-F Development Team +63 (917) 4458925
University of the Philippines Diliman
------------------------------
From: Dido Sevilla <[EMAIL PROTECTED]>
Subject: Re: [Q] Serpent: Gladman Code incomplete ?
Date: Mon, 10 Jul 2000 18:16:33 +0800
Runu Knips wrote:
>
> Last weekend I have studied the Serpent paper, and was surprised how
> easy
> to understand and elegant this cipher is, even if I missed some of the
> very basic features of a cipher description in it, meaning test vectors
> and at least an idea how to implement the cipher in software.
>
> I also read the Serpent implementation of Brian Gladman
> (http://www.btinternet.com/~brian.gladman/cryptography_technology/aes/serpent.c),
> but what I don't understand is the fact that Serpent defines an initial
> and final bit transformation (called IP and FP in the paper), which are
> not implemented in the cipher of Mr. Gladman. So is it true that Mr.
> Gladman's implementation is in fact incomplete ?
No. Read the specification paper more carefully. The initial and final
permutations are already included in the particular S-box logic used by
Gladman and his bitslice implementation of the cipher. It's a
particularly ingenious bit of work actually. Try downloading the
complete AES submission tarball from the Serpent website
(http://www.cl.cam.ac.uk/~rja14/serpent.html) and you'll see IP and FP
aren't included either in the fast ANSI C (bitslice) implementation.
--
Rafael R. Sevilla <[EMAIL PROTECTED]> +63 (2) 4342217
ICSM-F Development Team +63 (917) 4458925
University of the Philippines Diliman
------------------------------
Date: Mon, 10 Jul 2000 12:26:29 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: [Q] Serpent: Gladman Code incomplete ?
Mark Wooding wrote:
> Does this help?
Yep. Thank you very much !
------------------------------
From: Konrad Schwarz <[EMAIL PROTECTED]>
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical
Date: Mon, 10 Jul 2000 12:42:06 +0200
Al Grant schrieb:
>
> Is that a worse issue than byte addressing? With today's
> processors, isn't the concept of 'byte' just as artificial as that
> of 'bit', and wouldn't it be easy to extend the hardware already
> in place to support byte addressing to support bits as well?
>From an abstract point of view, possibly. From a practical
point of view, I beleive not: the investment in byte addressable
hardware is just too large and the payoff of bit-addressing too small.
------------------------------
Date: Mon, 10 Jul 2000 12:35:29 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical
Runu Knips wrote:
>
> Thomas Womack wrote:
> > "Mok-Kong Shen" <[EMAIL PROTECTED]> wrote
> > > Transposition is one of the basic operations in cryptography.
> > Is it, any more? Having a look at the AES candidates, most of them carefully
> > refrain from calling for bit transpositions simply because they're rather
> > hard to implement.
>
> Rotations are bit permutations, too, therefore you're simply wrong.
>
> And, well, Serpent contains a really complex initial (and final)
> bit permutation, even if I don't understand whats the use for it,
> except that the cipher is seriously slowed down in software.
Ouch. Forget that posting ;-) It was <censored> ...
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Suggestions for crypto for constrained-memory/CPU computers?
Date: 10 Jul 2000 10:48:24 GMT
Paul Rubin <[EMAIL PROTECTED]> wrote:
> If you're thinking of public key algorithms, all the ones I know of
> are slower at decryption than low-exponent RSA is at encryption.
The group's number theorists will be able to point out why it's a stupid
idea, but: can't you improve RSA private-key operation performance at
the expense of public-key operations by choosing the private exponent to
have low Hamming-weight residues modulo each of (p - 1) and (q - 1)?
If you ensure that (p - 1)/2 and (q - 1)/2 have no common factors (which
isn't very difficult -- you could, for example, choose p and q as
Lim-Lee primes, although brute force works quite well), you can choose d
mod (p - 1)/2 and d mod (q - 1)/2 to have low Hamming-weight. Since (p
- 1)/2 and (q - 1)/2 are coprime, we can construct d (mod \lambda(p - 1,
q - 1)) using the Chinese Remainder Theorem. The encryption exponent e
will be horrible to work with, but that's the price we're paying.
I wouldn't have thought that choosing the residues of d in this way
would lead to small-exponent attacks. Are there any other problems with
this idea?
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Random Numbers
Date: Mon, 10 Jul 2000 10:50:19 GMT
On Mon, 10 Jul 2000 00:18:55 +0100, "David Hyde"
<[EMAIL PROTECTED]> wrote, in part:
>Sorry I left out some detail about the random bit stream. The bit stream
>has been generated from a white noise source I built from a zener diode, a
>couple of op-amp stages and a comparator. Although the bits produced are
>independent of each other, there is a bias that can't be removed by
>adjusting the dc mean level of the noise. Therefore I was asking if there
>is a way of processing the bit stream to produce 16-bit random numbers with
>a uniform distribution?
One important thing to note is the information content of these random
bits, so you know how many of them are needed to produce a 16-bit
random number. But the simplest rule for producing truly random bits
from biased bits is to use this table:
00 : discard
01 : 0
10 : 1
11 : discard
John Savard (teneerf <-)
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Advanced Cryptography FAQ
Date: Mon, 10 Jul 2000 10:54:50 GMT
On 10 Jul 2000 07:06:22 GMT, [EMAIL PROTECTED] (Mack) wrote, in
part:
>You have got it wrong he isn't a lamer because he thinks that static
>keylength and static operators are wrong.
>He is a lamer because he is trying to sell his spreadsheet or whatever it
>is.
Well, I'd say the problem isn't that he thinks that "static keylength
and static operators" can be improved upon. Nor that he has a product.
But when he claims that all existing ciphers "are wrong", in that
nothing is any good unless it uses his idea, then that is indeed what
lets us know he is a crackpot. As for being a lamer, things like "not
understanding a chosen-plaintext attack" will do it.
John Savard (teneerf <-)
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Compression & Encryption in FISHYLAND
Date: Mon, 10 Jul 2000 10:58:58 GMT
On 9 Jul 2000 23:18:43 -0700, [EMAIL PROTECTED] (Kurt Shoens)
wrote, in part:
>Agreed that there's no proof of security against known
>plaintext attacks. If you're really concerned about avoiding
>known plaintext, you can always avail yourself of the various
>chaining modes, which will do a better job of camouflaging the
>plaintext.
The traditional block cipher chaining modes do nothing to increase the
fundamental security of the underlying block cipher; nor do they
protect against a true known-plaintext attack, where the entire text
of a message is known with certainty, although by "camouflaging the
plaintext" they might make a _probable word_ attack more difficult.
John Savard (teneerf <-)
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Bruce Hoult <[EMAIL PROTECTED]>
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical applications
Date: Tue, 11 Jul 2000 00:22:44 +1200
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
> I don't think that's the right kind of argument. Lacking these
> instructions
> prevents certain algorithms from emerging which may be better than
> those optimized under the current constraints. (I just learned from the
> follow-up of Bruce Hoult, however, that permutation is implemented on
> the processor of PowerPC.)
I should probably hasten to point out that the PowerPC permute
instruction is a *byte* permutation instruction, not a bit permutation.
This doesn't prevent its use for bit perutation, but you'll want to
interleave eight data blocks of 128 bits into eight 128-bit AltiVec
registers and process several data blocks in parallel. This shouldn't
be a problem for encryption codes. This interleaving would appear to
require eight instructions to load the data blocks, a bytewise rotate on
each of the eight data blocks (by differing amounts), and seven vector
select instructions per destimation register (56 altogether). That
makes 72 instructions for eight data blocks (16 * 8 = 256 bytes of
data), which is nine instructions per data block, or just under 0.5
intructions per byte. Then the actual bit permute will take one
instruction per data block. No doubt you'll do a few other things with
the data while it's interleaved, so you can't charge the whole packing
(let along the mirror unpacking) cost to the permute operation.
You might also be able to decrease those instruction counts by using the
"pack" instructions, rather than vsel, but not by much, I think, as they
only work down to 4-bit fields.
-- Bruce
------------------------------
From: csybrandy <[EMAIL PROTECTED]>
Subject: #sci.crypt irc channel
Date: Mon, 10 Jul 2000 08:25:40 -0400
I remember seeing a post that someone was trying to get this channel up
and running again. I believe it is on DalNet, but every time I go
there, nobody's home. Are people using the channel? If so, when?
csybrandy
------------------------------
From: Vladimir Castro Alves <[EMAIL PROTECTED]>
Subject: key dependent s-boxes
Date: Mon, 10 Jul 2000 15:39:59 +0200
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi,
<p>I am looking for references on key dependent s-boxes
<br>and their robustness compared to "conventional" s-boxes.
<p>Thanks for any hint on the subject.
<p>Vladimir Castro.
<br>[EMAIL PROTECTED]</html>
------------------------------
Date: Mon, 10 Jul 2000 09:49:29 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: SecurID crypto (was "one time passwords and RADIUS")
Vin McLellan wrote:
> The SecurID hash, created by John Brainard of RSA Labs in 1985, is not
> patented, but it is a RSA trade secret -- largely because when
> ACE/SecurID was first brought to market 14 years ago, the secrecy of any
> embedded crypto in a commercial product was often a market requirement.
> RSA continues to honor commitments made then to early users of
> ACE/SecurID, but it has always publicly insisted that the secrecy of the
> hash is merely a customer requirement, and that the publication of the
> hash would in no way lessen the integrity of ACE authentication.
>
> RSA <www.RSAsecurity.com> has sold some seven million SecurIDs. There
> are now approximately 12,000 ACE/Server installations worldwide.
>
> Interest in the SecurID hash, per se, has been cyclical.
>
> Its integrity has rarely been called into question -- never, AFAIK, by
> anyone who has studied it - but it is getting a little long in the
> tooth, and Moore's Law clearly indicates that any cryptosystem will
> (sooner rather than later;-) require more than a 64-bit key. It is,
> nevertheless, a measure of the confidence that RSA's major customers
> place in Brainard's hash that it has remained unchanged for 14 years --
> while RSA's authentication server (ACE/Server) and the ACE client/server
> protocol have been steadily enhanced to meet new threats in new network
> environs.
>
> If you are a current or (serious) potential customer, RSA has always
> been willing to give you -- or your designated crypto consultants --
> access to the SecurID algorithm under a NDA. So, while Brainard's hash
> has never been published, it has, over the years, been studied in depth
> by a sizable and well-credentialed community of corporate and government
> cryptographers.
>
> So many prominent cryptographers have had occasion to evaluate the
> SecurID hash over the past 15 years -- legally, under NDA; or,
> illicitly, on gray market work benches -- that it was probably
> inevitable that the algorithm has begin to be mentioned more frequently
> in professional crypto circles. Good hashes are fairly rare, after all.
> Beyond that, any unpublished cryptosystem which holds the market's trust
> for so long -- even for so narrow and specific an application --
> inevitably earns a place in the lore of the Craft.
The product has been extensively reviewed. So far, so good.
[snip]
> Published details about the SecurID hash are sparse.
>
> RSA has said only that the SecurID hash consists of a sequence of 256
> operations (each of which requires several processor instructions),
> where each operation depends upon the results of the previous operation.
...
> The issue of a secret cryptosystem was not always so contentious. In
> '85, after a stint as IBM's historian, I was a journalist when I came
> across Ken Weiss, the inventor of the SecurID. I wrote an aggressively
> positive cover story about the technology for "Information Week." I
> thought it was gonna take over the world.
>
> Shortly thereafter (thinking I was one smart guy;-), Weiss invited me
> to spend an afternoon with his planning team in what was then the
> company's headquarters, the living room of his Boston townhouse, to
> present the case for open publication of the SecurID hash.
>
> I did a pretty good job, I think, but my arguments were not enough to
> sway them. It was not yet clear, even to me, whether or not the NSA
> would succeed in its campaign to crush or leash the nascent
> private-sector cryptographic community. Meanwhile, several large banks
> and a major financial services firm had expressed interest in buying the
> tokens, and all had said they expected that the SecurID algorithm would
> be kept secret.
Why did they have this expectation? What was their rationale?
> Over the years, as ACE/SecurID rapidly seized and held a hungry lion's
> share of the market for two-factor authentication {particularly in large
> corporate enterprise environments), I've had to concede that -- on the
> "business case," which is what dominates in the real world -- they were
> right and I was wrong.
>
> I realize that, today, secret (and proprietary;-) algorithms rub a lot
> of people on this forum in the wrong way -- but anyone with history in
> this Craft can tell you that they were once quite common, and are not
> (solely by virtue of being unpublished) inherently weak.
>
> Conventional Wisdom to the contrary, the question of _who_ evaluates a
> cryptosystem has always been much more important than how many people
> get to study it;-)
[snip long discussion containing testimonials by reasonably credible customers]
> In crypto, few things are impossible, but many things are
> infeasible or impractical. No one can say that Mr. Ashwood may not
> discover some new cryptanalytic weakness in the hash, but his idea for
> an analytical attack is pretty basic. Many smart people have looked at
> a SecurID's token-code output without discovering any exploitable
> pattern. (And the scale of such a task, I've been told, would probably
> entail collecting millions of token-codes from a given SecurID, for a
> statistical attack with bleak prospects for success.)
...
> In North America, and in many nations in Europe, Asia, and the Middle
> East, citizens and local corporations can usually ask their respective
> national cryptographic authority for either a formal or informal
> evaluation of the SecurID algorithm. YMMV. What you'll get will probably
> be a declaration of sufficiency, similar to what the American NSA issued
> years ago.
...
> OTOH, "who" reviews the code is still more important than how many
> people review the code. There have also been numerous examples of "open
> source" crypto, freely available to all, being widely used for years
> before a serious cryptographer picked through it carefully and discovered
> dangerous weaknesses.
...
> None of the cryptographers who have reviewed the SecurID crypto before
> their government or their employer adopted it had any reason to evaluate
> by anything less than the most rigorous standard. If one could crack
> the SecurID they were guaranteed, at least, a toast among their peers,
> and probably headlines as well.
>
> All things being equal, published cryptography (and for some, open
> source) is more attractive to many than unpublished or proprietary
> crypto for many reasons -- but not because it guarantees either
> cryptographic quality, nor quality in a crypto implementations.
>
> Still, I don't mean to argue against open publication and unfettered
> evaluations of crypto. I think that argument has been won, and the
> market has echoed the pro-publication judgment of the professional
> cryptographic community. For cryptosystems, I think that is a very good
> thing -- although I suspect proprietary implementation code (buttressed
> by 24/7 support, development efforts, and vendor stability) will remain
> a fixture in the commercial market.
> I suggest, however, that both the market and the crypto community have
> made some rare exceptions and "grandfathered" cryptosystems which,
> despite being unpublished, have built their own credibility as they have
> been challenged, evaluated, and used over the years.
>
There's an apparent contradiction in the reliance upon customer's testimonials as
to strength and the same reliance upon the same customers as the source of the
preference for continuation of trade secret protection. Either the customers think
the system is strong, or they think it may not be. The construct "they think it is
strong as long as it is secret" is a weak reed upon which to rest the judgments
you've endorsed.
Considering your observations regarding "who the reviewers are" rather than "how
many the reviewers are" leads to a concise interrogative that encapsulates the
issue: Just who are your customers afraid to let review the system?
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Rijndael key schedule question
Date: 10 Jul 2000 13:53:51 GMT
Dido Sevilla <[EMAIL PROTECTED]> wrote:
> It seems that the AES page describing Rijndael says that the key
> schedules for Rijndael encryption and decryption are different.
> However, I don't find anything in the Rijndael specification papers or
> even in the sample code Vincent Rijmen provides on his website that
> says the key schedules are different. What does that mean?
I think he means that the sensible way to implement Rijndael decryption
needs to use modified keys which (if memory serves) have already had the
InvMixColumn operation applied to them.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Padgett 0sirius)
Subject: tokens and vpns ( was:Re: SecurID crypto (was "one time passwords and RADIUS")
Date: Mon, 10 Jul 2000 08:52:57
Hi Vin:
My perception is essentially the same as it always has been and that is the
the flaw in any time synchronous mechanism is that it is only as good as the
clocks employed hence the necessity for a "window" and a failure mode that
requires waiting for the next changeover.
This makes specialized tokens with accurate clocks a necessity. Since PCs
have notoriously inaccurate clocks, soft tokens have special problems.
However they are easy to use (Read the display. Enter.) and difficult enough
to compromise that other attacks are easier. Add in very good marketting and
you have a recipe for dominance which has occured.
Personally, have always preferred challenge/response systems since they do
not have the above limitations and permit much simpler operation. True you
do not know the exact hour of expiration (have a SafeWord from 1991 that
still works) but are ideally suited for PDA and smart card use. Hover it
seems to be a case of VHS vs Beta all over again.
One thing I mentioned a lot back around 1992 was the inherant VPN capability
of tokens but no-one seemed to understand what I was talking about. Consider
if instead of sending the display, it were used as the seed for a symmetric
encrypted link. Since both ends have the same value, no exchange is
necessary so a man-in-the-middle attack cannot work. By the fact that
communication is possible, both ends are authenticated. Unfortunately no
vendor was interested.
A. Padgett Peterson, P.E. CISSP: Cybernetic Psychophysicist
http://www.freivald.org/~padgett/index.html
to avoid antispam use mailto:[EMAIL PROTECTED] PGP 6.5 Public Key Available
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
