Cryptography-Digest Digest #624, Volume #14 Sat, 16 Jun 01 09:13:00 EDT
Contents:
Re: CipherText E-mail encryption (Bryan Olson)
Re: CipherText E-mail encryption ("Tom St Denis")
Re: Simple Crypto II, the public key... ("Tom St Denis")
Re: IV ("Tom St Denis")
Re: CipherText E-mail encryption (Bryan Olson)
Re: Any good Crypto Books? ("M.S. Bob")
Re: "man in the middle" question ("M.S. Bob")
Re: Is ECB truly more secure than CBC? (Tim Tyler)
Re: "man in the middle" question ("Tom St Denis")
Re: Is ECB truly more secure than CBC? (Tim Tyler)
Re: IV (Tim Tyler)
Re: CipherText E-mail encryption (Bryan Olson)
Re: CipherText E-mail encryption ("Tom St Denis")
Cryptography FAQ (01/10: Overview) ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: CipherText E-mail encryption
Date: Sat, 16 Jun 2001 03:20:58 -0700
Tom St Denis wrote:
> My base64 encoder from my CDLL package [which has not be released]
>
> /* base64 encode */
> void EXP base64_encode(const unsigned char *input, long inlen,
> unsigned char *output, long *outlen)
> {
> long x, i;
> unsigned long y;
>
> *outlen = 0;
> for (x = 0; x < inlen; ) {
> for (y = i = 0; (i < 3) && (x < inlen); i++)
> y = (y<<8) | input[x++];
> /* shift as required */
> if (i != 3) y <<= (8 * (3 - i));
> output[(*outlen)++] = code[y&63]; y>>=6;
> output[(*outlen)++] = code[y&63]; y>>=6;
> output[(*outlen)++] = code[y&63]; y>>=6;
> output[(*outlen)++] = code[y&63];
> }
> output[(*outlen)++] = 0;
> }
>
> This runs very very quickly.
It may be fast, but it's un-decodable. For example, the
string of one zero octet, the string of two zero octets, and
the string of three zero octets all encode to the same
output.
There are already too many algorithms in use for
binary-to-character encoding. I recommend the standard
base-64 encoding from RFC 2045.
--Bryan
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: CipherText E-mail encryption
Date: Sat, 16 Jun 2001 10:46:34 GMT
"Bryan Olson" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> Tom St Denis wrote:
>
> > My base64 encoder from my CDLL package [which has not be released]
> >
> > /* base64 encode */
> > void EXP base64_encode(const unsigned char *input, long inlen,
> > unsigned char *output, long *outlen)
> > {
> > long x, i;
> > unsigned long y;
> >
> > *outlen = 0;
> > for (x = 0; x < inlen; ) {
> > for (y = i = 0; (i < 3) && (x < inlen); i++)
> > y = (y<<8) | input[x++];
> > /* shift as required */
> > if (i != 3) y <<= (8 * (3 - i));
> > output[(*outlen)++] = code[y&63]; y>>=6;
> > output[(*outlen)++] = code[y&63]; y>>=6;
> > output[(*outlen)++] = code[y&63]; y>>=6;
> > output[(*outlen)++] = code[y&63];
> > }
> > output[(*outlen)++] = 0;
> > }
> >
> > This runs very very quickly.
>
> It may be fast, but it's un-decodable. For example, the
> string of one zero octet, the string of two zero octets, and
> the string of three zero octets all encode to the same
> output.
That's funny since I have tested this routine and it does decode properly
> There are already too many algorithms in use for
> binary-to-character encoding. I recommend the standard
> base-64 encoding from RFC 2045.
Yes, but this is just a bloody example of how todo it semi fast.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Simple Crypto II, the public key...
Date: Sat, 16 Jun 2001 10:50:49 GMT
"Fat Phil" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
<snip badly formed post>
Run this code. If you get anything but 0's as output I will donate my
earthly possesions to you.
#include <stdio.h>
int main(void)
{
unsigned a, b, x;
b = 13;
for (x = 0; x < 15; x++) {
a = b * x;
a = ((a>>8)+a)&255;
a = a - ((b*x)%255);
printf("%u\n", a);
}
return 0;
}
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: IV
Date: Sat, 16 Jun 2001 10:55:04 GMT
"Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> David Wagner <[EMAIL PROTECTED]> wrote:
>
> : Are you talking about the fact that CTR mode doesn't conceal the length
> : of the plaintext?
>
> Yes.
>
> : Few modes do.
>
> Indeed - though some are better than others.
>
> : If you need to conceal the length of the plaintext, then you're going
> : to need to add additional machinery. This is true whether you're using
> : CTR more or CBC mode: CBC mode also leaks substantial information about
> : plaintext lengths, too.
>
> CTR mode leaks more - al *lot* more - in the case of 8-bit plaintexts,
> it can be be equivalent to leaking 248 bits from a 256-bit key - a huge
> loss of key material.
We've been through this. No it doesn't leak 256-8 bits of the key material.
Yes there will be that many keys that are equiivalent. But you're failing
to recognize that you won't know when you guessed right. Even if you know
the plaintext you will have to pick from 2^248 remaining keys.
Remember
55 = P + K mod 256
This is the same idea. You can guess K all you want, but you will never be
sure. Actually a better example is
55 = AP + B mod 257
In this case even if you know P you can't find A or B since you can fix one
and rotate thru values of another. All you know is A != 0. But if the
domain is say a larger prime that's a small small bias.
Tom
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: CipherText E-mail encryption
Date: Sat, 16 Jun 2001 04:11:12 -0700
"Prichard, Chuck" wrote:
[...]
> As for other criticisms about the security rendered by the CipherText
> string encryption algorithm, they are merely unfounded speculation based
> on comparisons with stronger methods of byte encryption. No attack has
> EVER been suggested, nor has any attack been made resulting in a broken
> CXT message.
There are also no precise descriptions of the algorithm
available and no reports of actual users actually sending
"CXT" messages.
But from what I think I understand, I can describe how to
break the system (without breaking the cipher). Correct me
if I'm wrong: the novel feature of the program is that
receiver doesn't require the "Ciphertext" program;
Javascript in the message implements decryption so the
receiver needs only Outlook or Netscape.
That concept is fundamentally broken. It requires the user
to enter his key into a program he just received in an (un-
authenticated) e-mail. Some form of code signing might help
a little.
Suppose Alice uses "Ciphertext" to send messages to Bob. Eve
fakes an encrypted message from Alice to Bob. It has bogus
headers indicating it came from Alice and includes a
modified version of the Javascript decryption code. The
modified code presents the same interface to receive the
key, but it encodes the key into the relative part of a URL
on Eve's server, then gets the URL. When Bob enters his key
to decrypt the message, Eve's server captures the key.
--Bryan
------------------------------
From: "M.S. Bob" <[EMAIL PROTECTED]>
Subject: Re: Any good Crypto Books?
Date: Sat, 16 Jun 2001 12:10:07 +0100
Jeff Potts wrote:
>
> I'm trying to get a better understanding of Cryptography and it's uses
> within Security. I did a search for Cryptography books and there seems
> to be few out there.
>
> I guess my question is, has anyone read either of these? If so, which
> would be best to learn Cryptography and Security Protocols? Or would
> one look at completely different books?
Amazon returns over 500 titles when doing a search on the word
"cryptography", so yes, a few.
How afraid of math are you?
Why do you want to know more about cryptography and security protocols?
Cryptography itself, to understand the actual fundementials requires
quite a though knowledge of mathematics, don't expect to master
cryptography without a good understanding of mathematics.
My second question could be reworded, "Are you a practitioner or an
academic?"
For a more practial introduction, of someone who wants to actually build
(design, program) systems then get Applied Cryptography and "Security
Engineering" by Ross Anderson
<http://www.cl.cam.ac.uk/~rja14/book.html>. Period. While wanting for
those to arrive, there are several essays you should read at
Counterpane's Lab page <http://www.counterpane.com/labs.html> such as
"Why Cryptography Is Harder Than It Looks", and in the back issues of
the Crypto-Gram is an article "So you want to be a Cryptographer"
amongst several other good essays and articles. For real life
examination of systems you need to read R. Anderson's "Why Cryptosystems
Fail" and "Programming Satan's Computer", available from his web site.
For a more academic introduction to cryptology itself, read "So you want
to be a Cryptographer", and the textbooks most recommended are:
An Introduction to Cryptography by R. A. Mollin
Chapman&Hall/CRC Press; ISBN: 1-58488-127-5
Cryptography: Theory and Practice by Douglas Stinson
CRC Press; ISBN: 0849385210
A Course in Number Theory and Cryptography by Neil Koblitz
Springer Verlag; ISBN: 0387942939
Handbook of Applied Cryptography, by A. Menezes, P. van Oorschot and S.
Vanstone
http://www.cacr.math.uwaterloo.ca/hac/
They are roughly ordered above in the mathematical maturity required,
IMHO. The Hanbook is actually a reference book, not a textbook, so use
it as a sumplement not a replacement for one of the others.
BTW, Based on only a very quick glance the RSA Official Guide book, it
looks like an extension of their FAQs which are available online, and it
is a decent very basic intro, general reference. Not enough for a
programmer or a student to implement or analysis algorithms, but a
gentle intro to concepts and such without a lot of math.
A good no-math intro is Cryptography Decrypted by H. X. Mel, Doris M.
Baker.
------------------------------
From: "M.S. Bob" <[EMAIL PROTECTED]>
Subject: Re: "man in the middle" question
Date: Sat, 16 Jun 2001 12:16:15 +0100
Tom St Denis wrote:
>
> Not only that but supposedly in a study a in the early 90s [if I recall
> correctly it right] the majority of non-high tech/crypto people [i.e non
> cryptographers] could not successfully use PGP to securely send email.
Why Johnny Can?t Encrypt: A Usability Evaluation of PGP 5.0. Alma
Whitten and J.D. Tygar. In Proceedings of the 9th USENIX Security
Symposium, August 1999.
http://www.sims.berkeley.edu/~alma/
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Is ECB truly more secure than CBC?
Reply-To: [EMAIL PROTECTED]
Date: Sat, 16 Jun 2001 11:28:54 GMT
David Wagner <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:>This would be in a system where previous messages of greater value had
:>been sent, and where the transmitter cannot be certain that exposure of
:>keys does not leak information about previous keys.
: Those previous messages *are* part of the information that the key
: is protecting. [...]
I meant that the previous messages were transmitted under different keys -
though there's some possibility that an imperfect RNG has been used.
However, perhaps the argument is stronger if the same key is
used. You've just transmitted an important short message in CBC
mode. You can't change key - and now want to transmit a long (but
not-very-important) message. Do you use ECB mode or CBC mode?
Joseph's argument seems to suggest that ECB mode might better preserve
the key - and thus maintain the security of the earlier message better.
Now, I'm not sure of the logic of his argument (how do you get
plaintext-cyphertext pairs for your attack from the CBC mode
cyphertext?) - but *if* the premise that ECB mode better prevents
key-recovery attacks under these circumstances is granted, the
conclusion seems OK.
: Anyway, I really don't understand the point of your argument.
It's not really my argument - I'll /try/ to duck out now ;-)
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: "man in the middle" question
Date: Sat, 16 Jun 2001 11:38:26 GMT
"M.S. Bob" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Tom St Denis wrote:
> >
> > Not only that but supposedly in a study a in the early 90s [if I recall
> > correctly it right] the majority of non-high tech/crypto people [i.e non
> > cryptographers] could not successfully use PGP to securely send email.
>
>
> Why Johnny Can?t Encrypt: A Usability Evaluation of PGP 5.0. Alma
> Whitten and J.D. Tygar. In Proceedings of the 9th USENIX Security
> Symposium, August 1999.
> http://www.sims.berkeley.edu/~alma/
Sounds right.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Is ECB truly more secure than CBC?
Reply-To: [EMAIL PROTECTED]
Date: Sat, 16 Jun 2001 11:37:40 GMT
Nomen Nescio <[EMAIL PROTECTED]> wrote:
: Tim Tyler replies:
:> I /presume/ this is the Oorschot/Wiener known-plaintext attack - see
:> Applied Cryptography, 2nd ed. p. 359 for details.
: Thanks, but how well does that fit to the original description:
[...]
: it doesn't seem like a very good match. It's not an attack on 3DES
: and it doesn't take knowledge of > 2^56 known pairs.
Hmm. I concur.
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: IV
Reply-To: [EMAIL PROTECTED]
Date: Sat, 16 Jun 2001 11:54:33 GMT
David Wagner <[EMAIL PROTECTED]> wrote:
: P.S. I said that CTR mode is secure if the block cipher is. You asked
: "How?". The real answer can be found in the definition of real-or-random
: security, and similar notions. I think Mark Wooding has some nice posts
: on the implications of these definitions. Note that when I claim "CTR
: mode is secure if the block cipher is", I am really trying to summarize
: a very precise theorem. If you want to know exactly what that theorem
: promises, you really should look at the statement of the theorem itself,
: not at my brief paraphrase of it. In particular, that theorem does not
: promise to hide anything about plaintext lengths; rather, it claims that
: an adversary (roughly speaking) should not be able to learn anything
: more than the length of the plaintext (more or less). If I caused any
: confusion by omitting this in my attempt at brevity, I apologize.
I think your summary says something different to the theorem - something
that is stronger - and is not actually supported by the theorem at all.
The real bit I object to is that this summary is what went into the
"Comments to NIST Concerning AES-modes of Operations: CTR-mode Encryption"
document - where the reader is going to get the impression that CTR mode
is proven to be at least as good at concealing information about the
plaintext as CBC mode - an idea I reguard as being misguided because of
the different granularities of length encoding - and the resulting severe
loss of possible plaintexts with CTR mode at small sizes.
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: CipherText E-mail encryption
Date: Sat, 16 Jun 2001 05:13:40 -0700
Tom St Denis wrote:
> "Bryan Olson"
> > Tom St Denis wrote:
> >
> > > My base64 encoder from my CDLL package [which has not be released]
> > >
> > > /* base64 encode */
> > > void EXP base64_encode(const unsigned char *input, long inlen,
> > > unsigned char *output, long *outlen)
> > > {
> > > long x, i;
> > > unsigned long y;
> > >
> > > *outlen = 0;
> > > for (x = 0; x < inlen; ) {
> > > for (y = i = 0; (i < 3) && (x < inlen); i++)
> > > y = (y<<8) | input[x++];
> > > /* shift as required */
> > > if (i != 3) y <<= (8 * (3 - i));
> > > output[(*outlen)++] = code[y&63]; y>>=6;
> > > output[(*outlen)++] = code[y&63]; y>>=6;
> > > output[(*outlen)++] = code[y&63]; y>>=6;
> > > output[(*outlen)++] = code[y&63];
> > > }
> > > output[(*outlen)++] = 0;
> > > }
> > >
> > > This runs very very quickly.
> >
> > It may be fast, but it's un-decodable. For example, the
> > string of one zero octet, the string of two zero octets, and
> > the string of three zero octets all encode to the same
> > output.
>
> That's funny since I have tested this routine and it does decode properly
I gave you the simplest cases that demonstrate the error.
Here's code:
void show_bug(void)
{
long inlen, outlen;
static const unsigned char zeros[3];
unsigned char buff[9];
for (inlen = 1; inlen < 4; ++inlen)
{
base64_encode(zeros, inlen, buff, &outlen);
printf("%ld zero octets encoded to length %ld string: %s\n",
inlen, outlen, buff);
}
}
--Bryan
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: CipherText E-mail encryption
Date: Sat, 16 Jun 2001 12:24:19 GMT
"Bryan Olson" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> Tom St Denis wrote:
> > "Bryan Olson"
> > > Tom St Denis wrote:
> > >
> > > > My base64 encoder from my CDLL package [which has not be released]
> > > >
> > > > /* base64 encode */
> > > > void EXP base64_encode(const unsigned char *input, long inlen,
> > > > unsigned char *output, long *outlen)
> > > > {
> > > > long x, i;
> > > > unsigned long y;
> > > >
> > > > *outlen = 0;
> > > > for (x = 0; x < inlen; ) {
> > > > for (y = i = 0; (i < 3) && (x < inlen); i++)
> > > > y = (y<<8) | input[x++];
> > > > /* shift as required */
> > > > if (i != 3) y <<= (8 * (3 - i));
> > > > output[(*outlen)++] = code[y&63]; y>>=6;
> > > > output[(*outlen)++] = code[y&63]; y>>=6;
> > > > output[(*outlen)++] = code[y&63]; y>>=6;
> > > > output[(*outlen)++] = code[y&63];
> > > > }
> > > > output[(*outlen)++] = 0;
> > > > }
> > > >
> > > > This runs very very quickly.
> > >
> > > It may be fast, but it's un-decodable. For example, the
> > > string of one zero octet, the string of two zero octets, and
> > > the string of three zero octets all encode to the same
> > > output.
> >
> > That's funny since I have tested this routine and it does decode
properly
>
> I gave you the simplest cases that demonstrate the error.
> Here's code:
>
> void show_bug(void)
> {
> long inlen, outlen;
> static const unsigned char zeros[3];
> unsigned char buff[9];
>
> for (inlen = 1; inlen < 4; ++inlen)
> {
> base64_encode(zeros, inlen, buff, &outlen);
> printf("%ld zero octets encoded to length %ld string: %s\n",
> inlen, outlen, buff);
> }
> }
Hmm? In my test suite I replaced "fill with random" with "fill with zeros".
I get a long string of zeros which magically decodes.
What is the problem with the code you are noting? Maybe I am just not
seeing it.
Tom
------------------------------
Crossposted-To: talk.politics.crypto,sci.answers,news.answers,talk.answers
Subject: Cryptography FAQ (01/10: Overview)
From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Date: 16 Jun 2001 12:28:03 GMT
Archive-name: cryptography-faq/part01
Last-modified: 1999/06/27
This is the first of ten parts of the sci.crypt FAQ. The parts are
mostly independent, but you should read this part before the rest. We
don't have the time to send out missing parts by mail, so don't ask.
Notes such as ``[KAH67]'' refer to the reference list in the last part.
Disclaimer: This document is the product of the Crypt Cabal, a secret
society which serves the National Secu---uh, no. Seriously, we're the
good guys, and we've done what we can to ensure the completeness and
accuracy of this document, but in a field of military and commercial
importance like cryptography you have to expect that some people and
organizations consider their interests more important than open
scientific discussion. Trust only what you can verify firsthand.
And don't sue us.
Many people have contributed to this FAQ. In alphabetical order:
Eric Bach, Steve Bellovin, Dan Bernstein, Nelson Bolyard, Carl Ellison,
Jim Gillogly, Mike Gleason, Doug Gwyn, Luke O'Connor, Tony Patti,
William Setzer. We apologize for any omissions.
Archives: sci.crypt has been archived since October 1991 on
ripem.msu.edu, though these archives are available only to U.S. and
Canadian users. Another site is rpub.cl.msu.edu in /pub/crypt/sci.crypt/
from Jan 1992.
The sections of this FAQ are available via anonymous FTP to rtfm.mit.edu
as /pub/usenet/news.answers/cryptography-faq/part[xx]. The Cryptography
FAQ is posted to the newsgroups sci.crypt, talk.politics.crypto,
sci.answers, and news.answers every 21 days.
The fields `Last-modified' and `Version' at the top of each part track
revisions.
1999: There is a project underway to reorganize, expand, and update the
sci.crypt FAQ, pending the resolution of some minor legal issues. The
new FAQ will have two pieces. The first piece will be a series of web
pages. The second piece will be a short posting, focusing on the
questions that really are frequently asked.
In the meantime, if you need to know something that isn't covered in the
current FAQ, you can probably find it starting from Ron Rivest's links
at <http://theory.lcs.mit.edu/~rivest/crypto-security.html>.
If you have comments on the current FAQ, please post them to sci.crypt
under the subject line Crypt FAQ Comments. (The crypt-comments email
address is out of date.)
Table of Contents
=================
1. Overview
2. Net Etiquette
2.1. What groups are around? What's a FAQ? Who am I? Why am I here?
2.2. Do political discussions belong in sci.crypt?
2.3. How do I present a new encryption scheme in sci.crypt?
3. Basic Cryptology
3.1. What is cryptology? Cryptography? Plaintext? Ciphertext? Encryption? Key?
3.2. What references can I start with to learn cryptology?
3.3. How does one go about cryptanalysis?
3.4. What is a brute-force search and what is its cryptographic relevance?
3.5. What are some properties satisfied by every strong cryptosystem?
3.6. If a cryptosystem is theoretically unbreakable, then is it
guaranteed analysis-proof in practice?
3.7. Why are many people still using cryptosystems that are
relatively easy to break?
3.8. What are the basic types of cryptanalytic `attacks'?
4. Mathematical Cryptology
4.1. In mathematical terms, what is a private-key cryptosystem?
4.2. What is an attack?
4.3. What's the advantage of formulating all this mathematically?
4.4. Why is the one-time pad secure?
4.5. What's a ciphertext-only attack?
4.6. What's a known-plaintext attack?
4.7. What's a chosen-plaintext attack?
4.8. In mathematical terms, what can you say about brute-force attacks?
4.9. What's a key-guessing attack? What's entropy?
5. Product Ciphers
5.1. What is a product cipher?
5.2. What makes a product cipher secure?
5.3. What are some group-theoretic properties of product ciphers?
5.4. What can be proven about the security of a product cipher?
5.5. How are block ciphers used to encrypt data longer than the block size?
5.6. Can symmetric block ciphers be used for message authentication?
5.7. What exactly is DES?
5.8. What is triple DES?
5.9. What is differential cryptanalysis?
5.10. How was NSA involved in the design of DES?
5.11. Is DES available in software?
5.12. Is DES available in hardware?
5.13. Can DES be used to protect classified information?
5.14. What are ECB, CBC, CFB, and OFB encryption?
6. Public-Key Cryptography
6.1. What is public-key cryptography?
6.2. How does public-key cryptography solve cryptography's Catch-22?
6.3. What is the role of the `trapdoor function' in public key schemes?
6.4. What is the role of the `session key' in public key schemes?
6.5. What's RSA?
6.6. Is RSA secure?
6.7. What's the difference between the RSA and Diffie-Hellman schemes?
6.8. What is `authentication' and the `key distribution problem'?
6.9. How fast can people factor numbers?
6.10. What about other public-key cryptosystems?
6.11. What is the `RSA Factoring Challenge?'
7. Digital Signatures
7.1. What is a one-way hash function?
7.2. What is the difference between public, private, secret, shared, etc.?
7.3. What are MD4 and MD5?
7.4. What is Snefru?
8. Technical Miscellany
8.1. How do I recover from lost passwords in WordPerfect?
8.2. How do I break a Vigenere (repeated-key) cipher?
8.3. How do I send encrypted mail under UNIX? [PGP, RIPEM, PEM, ...]
8.4. Is the UNIX crypt command secure?
8.5. How do I use compression with encryption?
8.6. Is there an unbreakable cipher?
8.7. What does ``random'' mean in cryptography?
8.8. What is the unicity point (a.k.a. unicity distance)?
8.9. What is key management and why is it important?
8.10. Can I use pseudo-random or chaotic numbers as a key stream?
8.11. What is the correct frequency list for English letters?
8.12. What is the Enigma?
8.13. How do I shuffle cards?
8.14. Can I foil S/W pirates by encrypting my CD-ROM?
8.15. Can you do automatic cryptanalysis of simple ciphers?
8.16. What is the coding system used by VCR+?
9. Other Miscellany
9.1. What is the National Security Agency (NSA)?
9.2. What are the US export regulations?
9.3. What is TEMPEST?
9.4. What are the Beale Ciphers, and are they a hoax?
9.5. What is the American Cryptogram Association, and how do I get in touch?
9.6. Is RSA patented?
9.7. What about the Voynich manuscript?
10. References
10.1. Books on history and classical methods
10.2. Books on modern methods
10.3. Survey articles
10.4. Reference articles
10.5. Journals, conference proceedings
10.6. Other
10.7. How may one obtain copies of FIPS and ANSI standards cited herein?
10.8. Electronic sources
10.9. RFCs (available from [FTPRF])
10.10. Related newsgroups
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
