Cryptography-Digest Digest #379, Volume #10       Sat, 9 Oct 99 00:13:03 EDT

Contents:
  Re: Block encryption with variable keys (Mok-Kong Shen)
  Re: DES breaker Technique? (Jim Gillogly)
  Re: Is 128 bits safe in the (far) future? ("Trevor Jackson, III")
  Re: US Crypto Policy: free speech? ("Trevor Jackson, III")
  Re: Using PGP as a source of random numbers (jerome)
  Re: Securing Windows 95 Swap/Temp Files (long) (JTong1995)
  Re: Ritter's paper (jerome)
  spoofing a crl (Miky)
  Re: Q: AI (Tom St Denis)
  Re: Q: AI ("Richard Parker")
  Re: Compression of encrypted data ("Trevor Jackson, III")
  Re: Ritter's paper ("Douglas A. Gwyn")

----------------------------------------------------------------------------

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Block encryption with variable keys
Date: Fri, 08 Oct 1999 23:54:15 +0200

Douglas A. Gwyn (IST/CNS) wrote:
> 
> Mok-Kong Shen wrote:
> > As I said, one could use a PRNG to supply the keys.
> 
> But then the initial parameters of the PRNG constitute the
> actual key.  You have substituted a more complex cryptosystem,
> so it's no longer DES.

I said that instead of a constant key the user employs variable keys. 
He certainly has somehow to manage to have these variable keys. That 
is the assumption. Whether these comes from PRNG or through other 
means is another matter. Yes, the ensemble of variable keys is 
certainly more complex than a single key. The main point, however,
is that with that amount of increased complexity the system (suddenly) 
becomes immune to differential analysis attacks. In other words, we 
no longer have to worry attacks in that direction. Of course the 
user doesn't get that advantage for free (there is no free lunch in 
this world). He certainly has to consider how to appropriately 
obtain these variable keys without too much costs etc., i.e. 
whether the tradeoff is acceptable to him. My argument is then that 
this cost is fairly low. One viable method is namely to employ a PRNG. 
He can use the key which he would have used as the constant DES key 
now as the seed of the PRNG which supplies the series of keys needed.

M. K. Shen

------------------------------

From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: DES breaker Technique?
Date: Fri, 08 Oct 1999 23:06:32 +0000

Paul Koning wrote:
> 
> Andrew Brydon wrote:
> >
> > Once upon a time,  UBCHI2 <[EMAIL PROTECTED]> wrote
> > >When the group won the RSA challenge and cracked the DES message, how did they
> > >know when they found the right key?  Did they have to search for english words

> > Format of the first part of the message was 'known plaintext'.
> 
> Was it really?

Yes, it really was.  The known plaintext consisted of three blocks:
"The unknown message is: ".

> The DES cracker doesn't depend on that, it can do probable
> plaintext (e.g., if you know it's plain english text).  See
> the book.

Quite right.  Deep Crack is more general than it needed to be for the
RSA DES challenge series.

-- 
        Jim Gillogly
        17 Winterfilth S.R. 1999, 23:02
        12.19.6.10.15, 2 Men 3 Yax, Eighth Lord of Night

------------------------------

Date: Fri, 08 Oct 1999 19:15:20 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Is 128 bits safe in the (far) future?

Roger Carbol wrote:

> Trevor Jackson, III <[EMAIL PROTECTED]> wrote:
>
> >> I'm still unclear as to what sorts of family secrets would need
> >> to be secured for that sort of time frame.
>
> >Paternity.  Medical records.  Psychological evaluations.  Anything
> >embarassing (childhood photos?)
>
> If it is truly all that embarassing, one should probably delete it.
>
> Let's say I get a psychological evaluation.  Why is it in my best
> interest to encrypt it such that it's secure for the next 400 years?
> How can I hope to ensure that the key remains only within my
> family?  Why do I really want my great-grandchildren to be able
> to access it, and no one else?

Because it may be a genetic endowment that you need to preserve for your
descendants.Because you may have an emotional attachment to the
data/picture/information.
Who cares?  The point is that people, rational or not, will want to
protect (hide) information for long periods of time.

If you want to argue that people _should_not_ want that, argue with
someone else, and please do it elsewhere.

>
>
> Or, from the other side, why would I be interested in the
> psychological evaluation of one of my ancestors who lived 400
> years ago?  How likely is it that I'll be able to authenticate
> it with any sort of accuracy?
>
> It sounds like a stretch to me.  The issue is not merely that there
> is some information you might not want around 400 years from now.
> That's an easy problem to solve -- delete it.  The more important
> issue is that you want someone with the key (and exactly how you
> can insure that the right person will have it after 400 years
> is quite the challenge) to be able to get at that information,
> that has been kept secret, presumably because it still has some
> value after all this time.
>
> .. Roger Carbol .. [EMAIL PROTECTED]




------------------------------

Date: Fri, 08 Oct 1999 19:25:53 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: US Crypto Policy: free speech?

Sundial Services wrote:

> >entropy wrote:
> > I'm aware that U.S. laws consider strong crypto algorithms a
> > munition, and thus regulate their export.  However, when these
> > algorithms (source code) are printed, it is protected as free speech,
> > so it can be freely exported.
> >
> > Would the same be true for other, conventional munitions?  If I
> > printed out the schematics of an F-16 fighter jet, or an advanced
> > machine gun, would that also be protected under free speech, and thus
> > exportable?  Is this only true for non-classified munitions?
>
> I think that the safest thing to do is to consult an attorney before you
> do any sort of publication.  The U.S. crypto laws are being revised even
> as we speak, because it is obvious to everyone that they are no longer
> reasonable or adequate (read:  "e-commerce") (read: "billions of dollars
> worth of trade happening right now").
>
> Kinda like what happened with the GPS system:  no one in the Defense
> department anticipated that anyone would use GPS to precisely locate
> manhole covers, but that's precisely what the City of Scottsdale (AZ) is
> doing -- as are thousands of other cities.  [It's much easier to
> describe the location of a leaky faucet this way than to say "it's at
> 12345 West Rio de Whatsizit's Way," which happens to be a very recently
> built, curvy street built over what was once a cotton field.  Sensible
> and valuable use of GPS, but don't expect the DoD to think that way.
> They think of missiles.

Well the 100 MPH GPS limit is supposed to prevent commercial GPS from being
used by terrorists in missiles.  But it reduces the utility of the device
for some personal security applications.

Someone thought very hard about missiles!



------------------------------

From: [EMAIL PROTECTED] (jerome)
Subject: Re: Using PGP as a source of random numbers
Reply-To: [EMAIL PROTECTED]
Date: Fri, 08 Oct 1999 23:46:14 GMT

To my mind, it would be better to use tools designed for it. pgp is probably
not the best way.

To produce good random numbers is pretty time consuming especialy if 
you dont have a hardware device dedicated to it and you want several CDs
of entropy. Apparently it was a bit hard so a new trend seems to say
'the output of a hash function is ok because it is one way'.

if you follow this way, be aware that you are far from the security
of an OTP. You are as secure as your hash function is. So i don't think
it worth the trouble to have this huge key of several CDs. If speed 
doesnt matter, i would use a stack of 'hard to break' bock cyphers.
3des+idea+.... possibly several time the same cyphersystem. your key
will be less than 1k so easier to handle than several GigaBytes.

If you don't follow this way, buy a good hardware generator or be 
prepared to wait. I produced 13k of random numbers in 15min (on linux,
output of /dev/random, not /dev/urandom) so if this rate is constant,
8 day by CD :) but the result is probably much better than the output
of pgp.

On Fri, 08 Oct 1999 14:52:16 -0500, nosehat wrote:
>I'm making a OTP for communication between just two parties.  So I need
>lots (several CDs) of random numbers.  Could I get these by encrypting
>very large files with PGP's conventional encryption, then grabbing big
>chunks out of the middle of these files?  I guess I'm asking if PGP
>encrypted files (minus header) are good noise, or if there are patterns
>there (perhaps related to the block size??)   Sure would be easier than
>taking apart my smoke detector.  :)
>
>--hat
>

------------------------------

From: [EMAIL PROTECTED] (JTong1995)
Subject: Re: Securing Windows 95 Swap/Temp Files (long)
Date: 08 Oct 1999 23:56:19 GMT

>I am interested in security when the computer is
>OFF, 

Check out Cerberus Systems, they make a commericial product that does what you
are looking for, runs in W95/W98, and also uses Triple DES for encryption. 
I've used it for the ast year with good results.  Great documentation, and you
can download a trial version with the DES key set to all zeros.  And nope, I
have nothing to do with the company  :-).  Good luck.
  

Jeffrey Tong     [EMAIL PROTECTED]<Jeffrey Tong>
PGP 5 Key available for download at WWW.PGP.COM   Key ID: BFF6BFC1
Fingerprint: 6B29 1A18 A89A CB54 90B9 BEA3 E3F0 7FFE BFF6 BFC1

------------------------------

From: [EMAIL PROTECTED] (jerome)
Subject: Re: Ritter's paper
Reply-To: [EMAIL PROTECTED]
Date: Sat, 09 Oct 1999 00:49:07 GMT

On Fri, 8 Oct 1999 15:13:04 GMT, Douglas A. Gwyn (IST/CNS) wrote:
>
>The point is, once one has collected the empirical natural-language
>statistical data, it can be *used* to construct a source model that
>does a decent job of substituting for the actual language.  We just
>had a thread with an example showing that even a simple trigraph
>frequency model already embodies a lot about the language.  With
>more advanced Markov models, especially HMMs (probabilistic functions
>of normal Markov models), we can easily come so close to the actual
>population statistics/information measures that there is no difference
>in practical applications in cryptography.

any reference about the usage of the Hidden Markov Models in cryptography ?

------------------------------

From: Miky <[EMAIL PROTECTED]>
Subject: spoofing a crl
Date: Fri, 08 Oct 1999 22:31:56 -0400
Reply-To: [EMAIL PROTECTED]

This is a cryptographically signed message in MIME format.

==============msA3244AB8A4D94D39349D2BA5
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

If somone or some security product requests a crl and does not have the
issing CAs cert, can't a spoofed site offer its own CRL signed by its
own keypair?

Mik

==============msA3244AB8A4D94D39349D2BA5
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIGSAYJKoZIhvcNAQcCoIIGOTCCBjUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BCYwggQiMIIDi6ADAgECAgIA5jANBgkqhkiG9w0BAQQFADCBiDELMAkGA1UEBhMCQ0ExGTAX
BgNVBAgTEEJyaXRpc2ggQ29sdW1iaWExEjAQBgNVBAcTCVZhbmNvdXZlcjEkMCIGA1UEChMb
UHJpdmFjeXguY29tIFNvbHV0aW9ucyBJbmMuMSQwIgYDVQQLExtQcml2YWN5eC5jb20gU29s
dXRpb25zIEluYy4wHhcNOTkwOTAxMTEzNDE0WhcNMDAwODMxMTEzNDE0WjCBnzELMAkGA1UE
BhMCQ0ExGTAXBgNVBAgTEEJyaXRpc2ggQ29sdW1iaWExEjAQBgNVBAcTCVZhbmNvdXZlcjEV
MBMGA1UEChMMcHJpdmFjeXguY29tMRUwEwYDVQQLEwxwcml2YWN5eC5jb20xDjAMBgNVBAMT
BW1qeTV5MSMwIQYJKoZIhvcNAQkBFhR4dGV5OTJhQHByaXZhY3l4LmNvbTCBnzANBgkqhkiG
9w0BAQEFAAOBjQAwgYkCgYEAqPIgUODI9Yb2on8t4cbKYhSxqJFjifwxJ2xqczOjgVVMIqBq
GykH/+d4+EE+gdixa8zutWirN3Rzuugo4p9t52pzjJ/UspkkmMwcqqgf9mFZ15R0IqqmhInq
Idq+ZotDipr2mM/rNTPD08u8MoYH11EhlfhUHkWK9gxxdugyQuUCAwEAAaOCAYAwggF8MAkG
A1UdEwQCMAAwEQYJYIZIAYb4QgEBBAQDAgWgMIGEBglghkgBhvhCAQ0EdxZ1UHJpdmFjeXgu
Y29tIFNvbHV0aW9ucyBJbmMuIEFub255bW91cyBEaWdpdGFsIENlcnRpZmljYXRlLiBGb3Ig
bW9yZSBpbmZvcm1hdGlvbiBwbGVhc2UgdmlzaXQgaHR0cHM6Ly93d3cucHJpdmFjeXguY29t
MB0GA1UdDgQWBBTfJf4saWC+6X9LKUmyrtbvdzFDGzCBtQYDVR0jBIGtMIGqgBQZrxXP7BQV
3SERd+oUu80EwxoagqGBjqSBizCBiDELMAkGA1UEBhMCQ0ExGTAXBgNVBAgTEEJyaXRpc2gg
Q29sdW1iaWExEjAQBgNVBAcTCVZhbmNvdXZlcjEkMCIGA1UEChMbUHJpdmFjeXguY29tIFNv
bHV0aW9ucyBJbmMuMSQwIgYDVQQLExtQcml2YWN5eC5jb20gU29sdXRpb25zIEluYy6CAQAw
DQYJKoZIhvcNAQEEBQADgYEAOWj80i5FDSpZpXEryYSUFvIxPib95C7qioLjNQ1dE4PqnLt1
h0sIhxjShD+akKw0BMZedAdPEllnx26pZMKRgvWUe8fty8jEmTRTrIAX7F06rmbIDfbfmSzd
NTLVLUr5y7Vf2JC1V9fVW628ss3VlZMMB1kxoYZV/JKbo8f4GwYxggHqMIIB5gIBATCBjzCB
iDELMAkGA1UEBhMCQ0ExGTAXBgNVBAgTEEJyaXRpc2ggQ29sdW1iaWExEjAQBgNVBAcTCVZh
bmNvdXZlcjEkMCIGA1UEChMbUHJpdmFjeXguY29tIFNvbHV0aW9ucyBJbmMuMSQwIgYDVQQL
ExtQcml2YWN5eC5jb20gU29sdXRpb25zIEluYy4CAgDmMAkGBSsOAwIaBQCggbEwGAYJKoZI
hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNOTkxMDA5MDIzMTU2WjAjBgkq
hkiG9w0BCQQxFgQUDtGjszZV5aBjWx2rsxovgyIsYEYwUgYJKoZIhvcNAQkPMUUwQzAKBggq
hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZI
hvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYA/J+8ze/9ShcyefBsnBUe6iAnJS40DRL86TCdP
loR//EgG7Dq5dpmHepBeq57UsaX9Xvmum5CuJTFjv4Bx5uRIqlwUJu+jyBccr8efuzOTKYvy
D/jCcdZxurJNqqUL7IiMp5lFD8V4K+cn89VStOViJsta3WykaOSiGaQqIXGDNA==
==============msA3244AB8A4D94D39349D2BA5==


------------------------------

From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Q: AI
Date: Sat, 09 Oct 1999 01:40:37 GMT

In article <[EMAIL PROTECTED]>,
  Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> Does anyone have information about research results of application
> of AI techniques to cryptology (in particular a survey)? I should
> appreciate very much obtaining a reference.
>
> M. K. Shen

In which side?  Cryptanalysis or actual protection?  It has already been
developed in a limited sense such as the linear attack on DES.  When you
think about it any program is AI, it's not sentient so to one degree it's not
a life form.  But if you think about it, any program can perceive and make
decisions based on what it knows.

Tom


Sent via Deja.com http://www.deja.com/
Before you buy.

------------------------------

From: "Richard Parker" <[EMAIL PROTECTED]>
Subject: Re: Q: AI
Date: Sat, 09 Oct 1999 01:55:24 GMT

Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> Does anyone have information about research results of application
> of AI techniques to cryptology (in particular a survey)? I should
> appreciate very much obtaining a reference.

Take a look at the research of Michael Kearns.  He works in
the field of artificial intelligence, but also has an interest in
cryptography.  He was one of the authors of a paper that discusses how
to apply knowledge from the field of AI to construct several
cryptographic primitives based on the difficulty of learning.

  A. Blum, M. Furst, M. Kearns, and R. Lipton, "Cryptographic
  Primitives Based on Hard Learning Problems," Advances in
  Cryptology - Crypto'93, Springer-Verlag, 1994, pp. 278-291.
  <http://www.research.att.com/~mkearns/papers/prim.ps.Z>
  <http://www.cs.cmu.edu/People/avrim/Papers/cryptofinal.ps.Z>

He has also written a paper on applying results from cryptography to
prove negative results in machine learning.  I suspect, however, that
you are not actually interested in research that applies AI techniques
to cryptography, you are looking for research that applies AI
techniques to cryptanalysis.  Unfortunately, I can't provide any
pointers for research in this area.  In any case, here is Michael
Kearns home page:

  <http://www.research.att.com/~mkearns/>

-Richard




------------------------------

Date: Fri, 08 Oct 1999 23:35:22 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: comp.security.pgp.discuss,alt.security.pgp
Subject: Re: Compression of encrypted data



ashwood wrote:

> Douglas A. Gwyn (IST/CNS) <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Actually, substitution of syllables, words, and/or phrases by shorter
> > code groups has been done for many centuries.
> But those all required prior knowledge of what would be encoded, Huffman
> does not, although to build the tree does require some knowledge.
>
> > Obviously, machine compression of encoded data wasn't a particularly
> > relevant research area before the advent of modern computers.
> But as you pointed out in your last paragraph, there has been a desire to
> decrease the size of a message for many centuries, which takes knowledge of
> the expected set of words
>
> > > by other methods). Now assuming that it takes a mere 50 years of time to
> > > develop a good huffman encoding for something the complexity of English
> ...
> >
> > Why on Earth would we make such an erroneous assumption in the first
> > place?
> The statement I made was not erroneous, even now, even after having
> computers around for a significant amount of time, we are still finding
> better huffman trees for encoding english, albeit very rarely (and we've
> been looking for over a decade).

You appear to be ignoring a fundamental property of English (as well as most
other languages) which is that the redundancy is available from within the text
of the message.  This makes it possible to compress a message without a large
corpus of text whose relationship to an individual message is problematic.  If
you could model English perfectly and build frequency tables to represent the
_average_ of all English messages you would have a sub-optimal representation of
any message that is small enough to be non-representative of the Enghlish corpus
you analyzed.  Most messages would be non-representative.

Thus the optimal analysis for a message would be based on its own statistics.
If  'the' did not appear in the particular message at all, then the high
frequency assigned to 'the' by analyzing English would be a source of
inefficient coding.

But analyzing message statistics requires a multi-pass message processing
algorithm.  A single pass algorithm, also based on the particular message rather
than on generalized statistics is still a superiour technique because of the
redundancy or conceptual locality of most messages.  If the test starts "The
quick brown fox jumps over the lazy dog", chances are that "brown fox" and "lazy
dog" will appear again in the message.  This is the basis for dictionary
compression where repeated strings are encoded by referring to the previously
transmitted strings.

> It also takes a significant body of text to
> provide for the efficient coding, something we do not have enough of yet to
> compress modern encrypted blocks, and something that has taken a larger
> amount of time than I have indicated, and of course as English changes so
> will the occurance of characters/words/phrases, which means that the most
> optimal coding will change over time. But even if it takes .01 second, and
> takes linearly more time for each block, adding the complexity needed for
> even DES would mean 2^64/(size of English language) seconds, since the size
> of the english language is significantly less than 1,000,000 words the
> complexity is still in the millenium timeframe (in fact about the 140
> millenium range). This of course only applies at the block by block level,
> but the analysis of DES that has been performed should long ago have
> uncovered if any smaller repeat occurances were more likely.
>
> > This general subject goes by the name "source coding", and there is
> > abundant information about it on the Internet.
> The biggest problem is not finding a way to do the encoding, the ways to do
> it are quite well known. The two biggest problems are in fact getting a
> large enough body of text to do an efficient encoding of many differing
> texts, and finding the time to execute the program. Neither of which did you
> even bother to consider, you simply _assumed_ (quite wrongly) that I am
> purely uneducated in all matters of language and compression, and taht I
> would simply accept your statements as correct, when in fact you provide no
> references to support your concept. Now if you can present any relevant
> information that does anything besides support my point I welcome it, but
> all you have shown so far is an ability to say something like "well I think
> your wrong, and my proof in on the internet" when in reality even the
> internet resources I have found would indicate that it takes a finitely
> small amount of time, using a finitely small amount of text to build even
> the most rudimentary tree, having to multiply these by large exponents of 2
> results in fairly large numbers for the time.
>
> Basically I think what I failed to make clear is that fact that there is a
> very basic rule of compression, a single static compression tree can only
> compress 1/2 of the texts, the other half will be enlarged by it. Only by
> having a large body of text can you hope to make your tree compress the
> majority of used strings (eg I would not expect a method of compressing
> English to be optimal for Chinese). As of this moment it is the large body
> of text that is difficult to come by for encrypted blocks, but also once we
> have this body, we will be able to create probability trees to aid in the
> decryption. If one were to find a perfect encryption method (including
> perfect RNG, and many others), the compression tree would be of no use
> because there would be a perfectly equal probability of any of the potential
> ciphertexts, regardless of the input stream. Hmm, maybe I was wrong in my
> first post, I hadn't thought of my last point there. Of course if we put
> forth the effort to attempt to build this tree, we might be able to
> determine, to a degree, the actual strength on the cipher.
>                 Joe




------------------------------

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Ritter's paper
Date: Sat, 09 Oct 1999 03:40:56 GMT

jerome wrote:
> any reference about the usage of the Hidden Markov Models in
> cryptography ?

The applications are numerous, and once you're familiar with the
technology it isn't hard to find opportunities to use it, for
example to classify suspected textual units into functional
categories (noun, verb, consonant, vowel, digit, punctuation,
null, whatever).  The original papers when published in the open
literature around 1967 had all cryptologic applications
carefully expunged, alas.  If you can find a copy of the NSA
Technical Journal "Special Computer and Information Sciences
Issue" (1975), which was an unclassified collection of NSATJ
articles given out to some job applicants etc., pp. 69-86
constitute an article by E. P. Neuburg, "Markov Models for
Phonetic Text", which cites another article by R. L. Cave and
L. P. Neuwirth, "Three New Statistical Models for English",
IDA-CRD Working Paper No. 233 (June 1968).  I doubt you can
get hold of the latter document, but I've seen references in
the open literature to the analysis of English by Cave and
Neuwirth, for example in the syllabus for a course at CMU LTI,
so there may be an open publication somewhere.  You might also
check for a Cave-Neuwirth reference in Jelinek's book,
"Statistical Methods for Speech Recognition" (MIT Press, 1997)
- my copy is at the office.  (Jelinek certainly has a lot to
say about the use of HMMs in *speech signal* analysis [which
tends to be limited to a subset of possible HMM models], but
not in cryptology.)

An interesting paper slanted more toward theory than practice,
but with a suggestive example, is:  S. Kullback, M. Kupperman,
and H. H. Ku, "Tests for Contingency Tables and Markov Chains",
Technometrics, Vol. 4, No. 4 (November, 1962).

There are more relevant unclassified papers in the NSATJ, but
unless you want to go through a tedious FOIA process they're
probably unavailable.  I got one formerly TSC article
declassified (lightly redacted) on 14 Aug. 1998, and there is
a slim chance that a copy has by now found its way into RG 457
in NARA II:  Mary E. D'Imperio, "An Application of PTAH to the
Voynich Manuscript", NSATJ Vol. XXIV, No. 2 (Spring 1979),
pp. 65-92.  Jim Reeds summarizes it briefly in his Voynich page.

------------------------------


** 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
******************************

Reply via email to