Cryptography-Digest Digest #356, Volume #12 Fri, 4 Aug 00 07:13:01 EDT
Contents:
Re: What is the word on TC5? (Raphael Phan)
Re: OTP using BBS generator? (Tim Tyler)
Re: What is the word on TC5? (Mark Wooding)
Re: What is the word on TC5? (Mark Wooding)
Re: What is the word on TC5? (Mark Wooding)
Re: DES implementation woes (Paul Schlyter)
Re: Cracking RC4-40 in FPGA hardware (Eric Young)
Re: New William Friedman Crypto Patent (filed in 1933) (Mok-Kong Shen)
Re: Small block ciphers (Mok-Kong Shen)
Re: OTP using BBS generator? (Mok-Kong Shen)
Re: Small block ciphers (Mok-Kong Shen)
Re: A non-linear extension of the Hill cipher (Mok-Kong Shen)
Re: Plausible Word Generation via Trigram Statistics (Mok-Kong Shen)
Re: Observation on MDS matrices (Mark Wooding)
RE: New block cipher for the contest (=?iso-8859-1?Q?Fierabr=E1s?=)
Re: Kill my Cipher (Mark Wooding)
Re: IV for arfour ("Andreas Sewe")
Re: New William Friedman Crypto Patent (filed in 1933) (John Savard)
Re: DES implementation woes (John Savard)
Re: New William Friedman Crypto Patent (filed in 1933) (John Savard)
----------------------------------------------------------------------------
Date: Fri, 04 Aug 2000 16:14:36 +0800
From: Raphael Phan <[EMAIL PROTECTED]>
Subject: Re: What is the word on TC5?
Mark,
> bijective F-functions in <[EMAIL PROTECTED]>. The
How do we access this?
Raphael
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: OTP using BBS generator?
Reply-To: [EMAIL PROTECTED]
Date: Fri, 4 Aug 2000 07:55:12 GMT
Mack <[EMAIL PROTECTED]> wrote:
:mdw wrote:
:>Mack <[EMAIL PROTECTED]> wrote:
:>> BBS is a bit more efficient than the RSA generator (one
:>> multiplication).
:>
:>One squaring, in fact. Squaring is faster than multiplication.
: No, one multiplication. BBS uses one squaring. RSA uses one
: squaring and one multiplication.
It looks like you're both right ;-)
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Breast is best.
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: What is the word on TC5?
Date: 4 Aug 2000 08:50:30 GMT
tomstd <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Mark Wooding) wrote:
>
> > 1. (0, d) ---> (d, 0)
>
> You mean to say 'd' causes '0' but that is impossible.. Or am I
> missing something...?
Oh. I didn't read your description very carefully. I must have got the
Feistel network the wrong way around. It pushes a zero difference
through F and swaps. This is clearly right, no?
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: What is the word on TC5?
Date: 4 Aug 2000 08:52:26 GMT
Raphael Phan <[EMAIL PROTECTED]> wrote:
> Mark,
>
> > bijective F-functions in <[EMAIL PROTECTED]>. The
>
> How do we access this?
Point your nearest web browser at http://www.deja.com/forms/mid.shtml
and paste the message-id into the form.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: What is the word on TC5?
Date: 4 Aug 2000 08:59:24 GMT
tomstd <[EMAIL PROTECTED]> wrote:
> But in order to distinguish the cipher from random you have to
> first pick d, d' and d'' values right?
The impossible differential is (0, d) -/-> (?, d). That is, for any
input difference of the form (0, d) (d nonzero), the right hand half of
the output difference can *never* be d.
> I mean for any cipher I can say random differences cause random
> differences...
Yes. The differences should be random. The impossible differential
above shows that they're not.
[Pretty please get a news service that doesn't screw up quoting and put
horrible advertisements at the bottoms of articles!]
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: DES implementation woes
Date: 4 Aug 2000 10:48:16 +0200
In article <[EMAIL PROTECTED]>,
John Savard <[EMAIL PROTECTED]> wrote:
> On Thu, 03 Aug 2000 17:57:22 -0400, Tony Lauck <[EMAIL PROTECTED]>
> wrote, in part:
>
>> Let's not start a holy war on what's natural or strange. At least not until
>> after a chance to (re)read Danny Cohen's entertaining classic paper. [1]
>
> Oh, no. I'm just expressing a personal opinion: and, even if
> big-endian is more natural to Westerners, that is still due to a
> _cultural_ cause, not a fundamental one.
Although Easteners read their words right-to-left, they still write
numbers in the same direction as we do -- so to Easteners too,
big-endian would be more "natural".
So let's conclude that, to be most easily readable by humans, big-endian
is indeed preferable.
But there's another point of view to consider! Binary code is rarely
read by humans, but most often read by the CPU. And from the point
of view of the CPU, little-endian will be "more natural" - why?
Well, consider if you want to do multiple-precision arithmetic, e.g.
in aome big-integer packade. Then it makes most sense to deal with
the least significant word first, then the 2nd least significant word
-- etc, and finally the most significant word last. Think if how you
will add and subtract a multi-digit number with pencil and paper: you
start with the last significant digit, right? Now, try to do it the
other way, using the most significant digit first. There'll be no
problems until you encounter a carry or a borrow, but then you'll have
to go back and fix up the more significant digits before going on...
So basically "big-endian" is the order you'd want to read binary data,
while "little-endian" is the order you'd want to to computations on
binary data.
====================================================================
Some 20+ years ago there was a similar "war" raging between pocket
calculator users: Reverse Polish Notation (used by Hewlett-Packard
calculators) vs Algebraic Notation (used by everyone else). And the
acutal difference was here quite similar to "big-endian" vs
"little-endian": using Algebraic Notation you just typed in some
math expression as it was written, while using Reverse Polish Notation
you just typed it in as it was to be computed.
=====================================================================
I'm a "functionalist" rather than a "appearance-alist" myself, so
I've mostly been using RPN calculators, as well as little-endian
CPU's (first the 6502, then the 8080 and Z80, then the x86 family of
CPU's; although I do have made some excursions into "big-endian" land
too).
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: Eric Young <[EMAIL PROTECTED]>
Subject: Re: Cracking RC4-40 in FPGA hardware
Date: Fri, 04 Aug 2000 09:30:57 GMT
Paul Rubin wrote:
>
> In article <WPmi5.815$[EMAIL PROTECTED]>,
> CMan <[EMAIL PROTECTED]> wrote:
> >I forgot to mention...while the Word Document key is truly 40 bits (actually
> >48 bits because there is some re-keying in an easy to guess way), but the
> >problem is the RC4 key is actually 128 bits. You see, Word first takes the
> >40 bit (48) bit document key and computes a hash of this document key and
> >uses that to schedule RC4.
>
> Hmmm, that can be a problem--what is the hash function?
>
> >I believe SSL also uses an MD4/5 hash also so this same difficulty arises
> >there.
SSLv2, when using an export cipher, RSA encrypted 40 bits of data
and sent the other 88 bits as clear text.
This 128 bits was then fed through MD5 to generate a 128bit RC4 key.
This 'cipher' when used in SSLv2 was called RC4-40.
This was 'broken' a few years back by writing code to do the MD5/RC4
combination
until the 'GET ' string was revealed :-). We 'walked' through the 40 bit
range
that were the output from the RSA. The hit occurred at just under half way,
which was rather annoying because I started my array of about 70 machines
(mostly 486 solaris) at the half way point :-(.
For SSLv3/TLS, the same algorithmic concept is used, input 40/56 bits of
unknown data into a hashing construct and then use the output for the key.
So you are not really breaking RC4-40 in the true sense. The speed of the
hashing is the bottleneck.
eric (who cannot remember the exact SSLv3/TLS hashing sequences right now...)
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: New William Friedman Crypto Patent (filed in 1933)
Date: Fri, 04 Aug 2000 11:49:24 +0200
Bruce Schneier wrote:
>
[snip]
> synchronization between the sending and receiving machines. Rowlett
> conceived of using one rotor machine to manufacture the pattern of
> rotor motions for the other, an idea that was to remain officially
> secret for 60 years."
So two rotor machines are coupled in some way (mechanical or
electrical). What is this set named? Could you give a reference?
Thanks.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Small block ciphers
Date: Fri, 04 Aug 2000 11:49:45 +0200
Benjamin Goldberg wrote:
>
> Mok-Kong Shen wrote:
> > Mack wrote:
> >
> > > I am more interested in the theoretical properties of a small block
> > > cipher. For example, If we change the key after every second
> > > encryption. Can an attacker find the key? Or if we change the key in
> > > some linear manner after every encryption can an attacker find the
> > > key for N encryptions where the key size is N*M?
> >
> > I believe that, if the block cipher (and hence the key size) is small,
> > the opponent will simply do brute-force, for that's easy for him,
> > while a well-designed large block cipher is impractical to brute-force
> > and he has therefore to resort to more intelligent means, if
> > available.
>
> Having the block size of a cipher small does *not* imply that the key
> size is small. An 8-bit block cipher can have as many as 256! possible
> keys. Breaking such a cipher is usually done with either some
> statistical analasys, or a codebook attack, or with known plaintext.
> Figuring out what the key is may not actually be necessary, especially
> if it uses, for example, an 16 byte key to simulate a 256 byte table.
We have at least some terminology difference here. By key size
I mean the number n of bits of one single key used. If that number
is small, then one can brute force, there being only 2^n
possibilities for that particular key.
> If the key is changed in a linear manner, you get something like a
> dynamic substitution cipher [I think]. If the key is changed in a
> non-linear manner, you get something like RC4/ARC4. Regardless of how
> your key-changing takes place, you're adding a significant amount of
> state, which moves your cipher out of the realm of block ciphers, and
> into the realm of a stream ciphers.
It is my humble view that (for design purposes) it is not
necessary to 'sharply' distinguish beteen stream and block
encryptions. (In fact, the most general encryption is
f(K, whole message), where f is an arbitrary function.)
Both techniques can be advantageously combined to achieve the
optimum of the design goal, namely security. On several occasions
I have pleaded for the use of variable keys. Using variable
keys does involve the issue of efficiency (setup time), but I
believe that's tolerable in a large number of cases in practice.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: OTP using BBS generator?
Date: Fri, 04 Aug 2000 11:49:35 +0200
Bryan Olson wrote:
>
> Mok-Kong Shen wrote:
> > For one that does not have expert knowledge in BBS, like me,
> > it seems unfortunately to be difficult to know from the materials
> > of past discussions in the group alone whether one party is
> > absolutly right and the other absulutely wrong.
>
> So look it up. Surely anyone can recognize the utter
> slyness of the claims that the reason the major current
> references don't include the long-cycle test in their
> description of the generator is that the authors have simply
> not read the whole paper. One could study the math and
> understand why, for example HAC, describes the simpler form
> of the generator; but only modest skill should enable one to
> recognize that the author are not lazy nor careless, they do
> understand the material, and that there's no evidence that
> these allegations are other than fabrications.
I am afraid either the phrase 'but only modest skill should
enable one to recognize that the author are not lazy nor
careless' is not objective or you are demanding a skill that
you condider to be modest but actually is not for the average
people. If only the simpler form is described in a book and
nothing else, how can a reader recognize laziness/carelessness
of its author or its opposite, excepting through reading the
original article of BBS?
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Small block ciphers
Date: Fri, 04 Aug 2000 11:49:50 +0200
Mack wrote:
>
> On the subject of changing keys:
>
> Yes changing the key in a certain manner after X encryptions does turn a
> block cipher into a stream cipher.
>
> But the problems of how many ciphertext it takes to break the cipher and
> how to create ciphers immune to related key attacks are still good topics
> of study.
True. But using variable keys does reduce (in 'any' situation)
the availability of materials that the opponent needs for
certain kinds of attack and hence the measure is worthy unless
efficiency issue is against it.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: A non-linear extension of the Hill cipher
Date: Fri, 04 Aug 2000 11:49:30 +0200
Benjamin Goldberg wrote:
>
> Some of what you are describing sounds very like Mark Wooding's "Storin"
> cipher. Enciphering is as follows:
>
> X[i], Y[i], Z[i] = intermediate values.
> K[i] : Round keys.
> Ma : a 4x4 matrix, invertable under integers mod 2**24
> Mb : the inverse of Ma; used for decryption
>
> Z[-1] = Plaintext, split into a vector of 4 24-bit values.
>
> For i = 0 to 7
> X[i] = Z[i-1] XOR K[i]
> Y[i] = (X[i] * Ma) MOD (2**24)
> For j = 0 to 3
> Z[i][j] = Y[i][j] XOR (Y[i][j] >> 12)
> end For j
> End for i
>
> Ciphertext = Z[7] XOR K[8]
K is used as whitening and can be excluded from the present
discussion. The computation of Y is the orginal Hill cipher
step. Then Z is computed from Y as given above, i.e. post-
processing of the output from Hill. I am not sure that there is
a 'very like-ness' that you indicated, excepting of course
the Hill cipher step. Could you please elaborate a little bit?
Thanks.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Plausible Word Generation via Trigram Statistics
Date: Fri, 04 Aug 2000 11:49:40 +0200
Tom Anderson wrote:
>
> On Wed, 2 Aug 2000, Mok-Kong Shen wrote:
>
> > I just saw in a post in a mailing list something that is
> > related in some measure to what you are doing. The author
> > call it mnemonic encoder. The following is taken from
> > his web page http://www.tothink.com/mnemonic
> >
> > The mnemonic encoding presented here is a method for
> > converting binary data into a sequence of words suitable for
> > transmission or storage by voice, handwriting, memorization
> > or other non-computerized means. The encoding converts 32
> > bits of data into 3 words from a vocabulary of 1626 words.
> > The words have been chosen to be easy to understand over the
> > phone and recognizable internationally as much as possible.
>
> it's not the same thing as Kurt's suggestion, as has been pointed out.
>
> however, it is similar to the PGP fingerprint-in-words scheme; i remember
> reading about this, but can't find it on the web. basically, there's a
> wordlist (actually, there's two ...), and bytes of data are used as
> indices into the list (or something). the words are chosen to minimise the
> probability of confusion (a bit like maximising Hamming distance).
My question is: Aren't genuine English words better than
artificial words for use or the other way round?
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Observation on MDS matrices
Date: 4 Aug 2000 10:07:14 GMT
tomstd <[EMAIL PROTECTED]> wrote:
> Just wanted to know if this is right...
No, 'fraid not.
> With a 4x4 mds matrix applied to an input the different in the
> input/output tuples is at least five right?
>
> Well if we consider two inputs (a, b) where b differs by four
> from 'a' then the outptu (f(a), f(b)) must only differ by one
> place at the most.
Wrong here.
Let M be a 4 x 4 MDS matrix; let x be a column vector of inputs, and let
d be a nonzero input difference. Then the output difference is
M (x + d) - M x = M x + M d - M x = M d
by distributivity of matrix multiplication.
To see why your argument above is wrong, count the number of vectors
with zero, one, two and three zero entries. (Hint: 255^4, 255^3, 255^2
and 255.) Noting that multiplication by M is a permutation on vectors,
count how many inputs with no zero elements can end up with one, two or
three zeros in the output...
-- [mdw]
------------------------------
From: =?iso-8859-1?Q?Fierabr=E1s?= <[EMAIL PROTECTED]>
Subject: RE: New block cipher for the contest
Date: Fri, 4 Aug 2000 12:13:11 +0200
Thanks Mr. Wagner for your analysis; it is greatly appreciated.
> When a plaintext/ciphertext pair u,c is known, this gives a single
> linear equation on 2N+1 formal unknowns (i.e., the N bits of b, the
> N bits of a, and the single bit m_0). Each known text gives another
> linear equation. Thus, with 2N+1 known texts, we obtain a system of
> 2N+1 linear equations in 2N+1 unknowns, and thus we can expect that
> the system may be uniquely solved for a,b,m_0 using Gaussian elimination
> with just O(N^3) bit operations.
Well, I must get deeply into your attack; as a quick overview, I'm not sure
it is so easy find 2N+1 {u,c} pairs that provide the 2N+1 linearly
independent equations in GF(2) needed to get out a, b, and m_0.
>
> But it gets worse. The same attack may be repeated on the next
> lowest bit position of v,w,m, i.e., w_1 = v_1 + m_1 + m_0 * (v_0 + 1);
> since v_0 and m_0 are now known, they may be eliminated, and we may
> solve another set of 2N+1 linear equations in 2N+1 unknowns to learn
> m_1 as well as the second column of M and M^{-1}. In this way, we
> may repeat until the entire key has been derived, and then the cipher
> is well and truly broken. The same 2N+1 known plaintexts may be re-used,
> and we repeat Gaussian elimination N times, so the total workfactor of
> the attack is O(N^4).
Moreover, if such 2N+1 {u,c} pairs are found to play with the '0'-bit, do
those pairs yield 2N+1 linearly independent equations for the '1'-bit and so
forth?
I'll go on short holidays, which I use to test your attack. Honestly it
seems to target! but let's see...
--
Manuel Pancorbo
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Kill my Cipher
Date: 4 Aug 2000 10:25:40 GMT
Ulrich Kuehn <[EMAIL PROTECTED]> wrote:
> You have not made clear where the key actually is input. And what is
> its length? All you have given is a method to produce a fixed set of
> 16 32-bit values.
I agree it wasn't very clear. His key is the 32-bit integer ky[0].
-- [mdw]
------------------------------
From: "Andreas Sewe" <[EMAIL PROTECTED]>
Subject: Re: IV for arfour
Date: Fri, 4 Aug 2000 12:36:13 +0200
"Benjamin Goldberg" wrote:
> Andreas Sewe wrote:
> > Well, any stream-cipher needs an IV, and in most cases it is
> > altogether sufficant to XOR the key K with the IV to get the
> > session-key K_s.
> Why XOR? Why not concatenate? With a 256 bit key, and 64 bit IV, you
> *can* use all of your key+IV to initialize the state of the RC4
> generator.
Ok, concatenating is seems to be the better solution, as long as
sizeof(K) + sizeof(IV) <= 2048 bit.
> > But now, arcfour doesn't use a simple n-bit value as key K, but a
> > permutation of 256 elements. Of course, this permutation, the internal
> > key K_i, is generated - in Rivest's implementation - out of a 2048
> > bit, i.e. 256 bytes; the external key K_e. So you can simply xor an
> > 2048 bit IV with the external key, perform Rivest's algorithm of
> > generating the internal key, and you get an internal key modified by
> > the IV.
> > But, the ugly is, this method relies heavily on the algorthim for
> > generating internal keys.
> Hmm, considering that RC4's method of generating the internal state from
> the key is designed to avoid short cycles, mixing your IV with the key
> before generating the state seems [to me] to be a good idea.
Well, the question is, if arcfour_key() is responsible for avoiding short
cycles, or it is simply something done by the arcfour_encryption() algorithm
itself.
In the first case, you're right; in the second one, any permutation is as
good as
any other one, because the encryption algorithm itself avoids short cycles.
> > Now suppose I get my permutations toying with 256 coloured marbles,
> > getting real random ones.
> You mean numbered, not colored marbles, cause most people can't
> destinguish between 256 different colors :)
Ok, let's play Pool billiard :)
> Umm... You've got an array with 256! possible states. Are you using
> this as your RC4 internal state, bypassing normal key setup, or are you
> using this as your IV, with the idea of combining it with RC4's state?
Now, basically as an IV, but you can also use two arrays, one for key K
and the other one for IV - at least if RC4's cycle length doesn't depend on
specific characteristics of the permutations, but only on the encryption
algorithm itself.
> > But now, I can't use the XOR method described above to get
> > my session key out of two permutations, generated by the "marble
> > method". So I have to link two permutations, key K and IV, to get a
> > third permutation - the session key K_s.
> > /* in C it can be done by the following code */
> > typedef char permutation[256];
> > permutation k, k_s, iv;
> > int n;
> > for(n = 0; n < 256; n++)
> > k_s[n] = k[iv[n]];
> > Are there any fundamental weaknesses, perhaps a chosen-key-attack?
> Your thinking of taking the state produced by RC4's key schedule, which
> was carefully designed to avoid short cycles, and modifying it using an
> IV that's essentially random, to produce a new internal state which
> might very well have a short cycle in it. This is Bad.
It would be Bad, if RC4's key schedule was the way Rivest tried to avoid
short cycles. If the encryption algroithm itself was designed for avoiding
those circles, it doesn't matter.
So, has anyone definitive information on short cycles for arcfour?
- and, more important, on the way they are avoided by the original
implementation?
> > Andreas Sewe
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: New William Friedman Crypto Patent (filed in 1933)
Date: Fri, 04 Aug 2000 10:50:39 GMT
On Fri, 04 Aug 2000 11:49:24 +0200, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote, in part:
>So two rotor machines are coupled in some way (mechanical or
>electrical). What is this set named? Could you give a reference?
>Thanks.
I discuss this coupling in my page on the SIGABA, at
http://home.ecn.ab.ca/~jsavard/crypto/ro0205.htm
John Savard (teneerf <-)
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: DES implementation woes
Date: Fri, 04 Aug 2000 11:00:19 GMT
On 4 Aug 2000 10:48:16 +0200, [EMAIL PROTECTED] (Paul Schlyter)
wrote, in part:
>Although Easteners read their words right-to-left, they still write
>numbers in the same direction as we do -- so to Easteners too,
>big-endian would be more "natural".
No, that is precisely why little-endian would make sense to them.
Because they still read their words first letter first; so, if we take
the storage of strings starting in lower addresses as a given, we
assume they would depict computer storage with the higher addresses
*on the left* like so...
7 6 5 4 3 2 1 0
000
001
so that if the computer's storage contained characters, the text would
be readable.
John Savard (teneerf <-)
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: New William Friedman Crypto Patent (filed in 1933)
Date: Fri, 04 Aug 2000 10:56:36 GMT
On Thu, 03 Aug 2000 17:47:11 -0500, Bruce Schneier
<[EMAIL PROTECTED]> wrote, in part:
>He calls it one of the worst crypto machines ever designed.
It is true that it applies a one-time-tape to a message in such a way
that it stops being a perfect one-time-tape (32 possibilities applied
to 26 letters, so the distribution can't be uniform to begin with, and
depending on the starting position of the rotors, some replacements
may not even be possible).
But considering that it was fruitful, and that the additional
complexity of the rotors would mask imperfections in the
one-time-tape, that hardly seems a fair assessment. Particularly when
there are so many _insecure_ cipher machines around. Also, it's an
improvement on the original experimental model, that moved a single
rotor to any of its 26 positions - and which therefore was impractical
because of being too slow. (_That_ patent, although also within the
line of historical development of the SIGABA, was granted without any
unusual delays, back in the 1930s.)
John Savard (teneerf <-)
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
** 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
******************************
