Cryptography-Digest Digest #480, Volume #10       Mon, 1 Nov 99 07:13:04 EST

Contents:
  Re: Doesn't Bruce Schneier practice what he preaches? ("Adam Durana")
  Re: Newly Encountered  Crypto System
  Boring Web Site and Kerberos News
  Re: MBR / FAT encryption (Dave Hazelwood)
  Re: Doesn't Bruce Schneier practice what he preaches? (Scott Fluhrer)
  Re: Doesn't Bruce Schneier practice what he preaches?
  Re: Proposal: Inexpensive Method of "True Random Data" Generation (David Bernier)
  Re: Symetric cipher ("Douglas A. Gwyn")
  Re: Bruce Schneier's Crypto Comments on Slashdot ("Rick Braddam")
  Re: Build your own one-on-one compressor (SCOTT19U.ZIP_GUY)
  Re: the ACM full of Dolts? (SCOTT19U.ZIP_GUY)
  Cryptography FAQ (01/10: Overview) ([EMAIL PROTECTED])
  Cryptography FAQ (02/10: Net Etiquette) ([EMAIL PROTECTED])

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

From: "Adam Durana" <[EMAIL PROTECTED]>
Subject: Re: Doesn't Bruce Schneier practice what he preaches?
Date: Sun, 31 Oct 1999 22:18:34 -0500

Hi,

I think you guys are missing the real point Schneier was trying to get
across.  He was not saying give out the source code to your software, he was
saying that the encryption methods used in your software should be public.
You have to trust that the designers and coders of the software correctly
implemented it.  Thats a lot of trust to put in someone, but you can test
the software to make sure it is correctly implemented in most cases.  (Test
vectors?)  There is a great deal of software that uses secret methods and
there is no way to tell if it is secure, until someone breaks it or reverse
engineers it.  What Schneier was saying is that the encryption methods used
in software should be public, because the strength of a method should rest
in itself, not in its obsurcity.

-- Adam Durana



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

From: [EMAIL PROTECTED] ()
Subject: Re: Newly Encountered  Crypto System
Date: 1 Nov 99 03:25:50 GMT

John Kennedy ([EMAIL PROTECTED]) wrote:
: It's a pure snake-oil pitch, obviously.

Well, it has *one* difference from the usual snake-oil pitch.

There are as yet no details on how to get in contact with this reclusive
eccentric who has produced an unbreakable cipher that breaks all the
rules.

Shall we call it a snake-oil teaser? And the description of A.N.E.C.
sounds hauntingly familiar, but web and news searches turn up nothing.

John Savard

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

From: [EMAIL PROTECTED] ()
Subject: Boring Web Site and Kerberos News
Date: 1 Nov 99 03:27:01 GMT

Yes, I *finally* broke down and dashed off a page that actually *says*
something about Kerberos for my web site.

John Savard

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

From: [EMAIL PROTECTED] (Dave Hazelwood)
Subject: Re: MBR / FAT encryption
Date: Mon, 01 Nov 1999 01:39:23 GMT

Sounds like win thinks your handler is managing those drives but
it is not so it drops them.

Go here and get secdr14a.zip (the one by Edgar Swank) and try
it out. See if you still lose your other drives. All source is
included. 

I used to work with Edgar at IBM and he has written a number
of useful tools.


>Like what?
> 
>This is what I did: I implemented complete disk encryption (except
>the very first track, where the MBR resides), and a decryption
>algorithm stored in the MBR (and a few more sectors, since all didn't
>fit within one sector).  Encrypting the disk using this worked fine
>on plain DOS and Win 3.x.  On Win-95 it worked too, but disk access
>reverted back to 13-bit compatibility mode -- and I also lost access
>to the IDE CD-ROM.  Next, I implemented a Win-95 VSD (a VxD for block
>device drivers on WIn-95) which performed the encryption in 32-bit
>protected mode.  WHen this VSD loaded, disk access was all 32-bit --
>and I also got my lost IDE CD-ROM back.
> 

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

From: Scott Fluhrer <[EMAIL PROTECTED]>
Subject: Re: Doesn't Bruce Schneier practice what he preaches?
Date: Mon, 01 Nov 1999 04:57:51 GMT

In article <oE7T3.2615$[EMAIL PROTECTED]>,
        "Adam Durana" <[EMAIL PROTECTED]> wrote:

>Hi,
>
>I think you guys are missing the real point Schneier was trying to get
>across.  He was not saying give out the source code to your software, he was
>saying that the encryption methods used in your software should be public.
>You have to trust that the designers and coders of the software correctly
>implemented it.  Thats a lot of trust to put in someone, but you can test
>the software to make sure it is correctly implemented in most cases.  (Test
>vectors?)  There is a great deal of software that uses secret methods and
>there is no way to tell if it is secure, until someone breaks it or reverse
>engineers it.  What Schneier was saying is that the encryption methods used
>in software should be public, because the strength of a method should rest
>in itself, not in its obsurcity.

If that's all Schneier meant, then he's wrong.  Just knowing the algorithms
used is not enough.  You have to know that they were put together correctly,
for example, that any random number generators used were not chilled, that
any keys created were not chosen with malice, that no key bits were being
leaked somehow.

Schneier knows all this.  That's why I suspect you're misinterpretting him.

-- 
poncho


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

From: [EMAIL PROTECTED] ()
Crossposted-To: alt.security.scramdisk
Subject: Re: Doesn't Bruce Schneier practice what he preaches?
Date: 1 Nov 99 05:34:47 GMT

Roman E. Liky ([EMAIL PROTECTED]) quoted:
: >Here's an example, Counterpane Systems has a nice little freeware
: >utility called Pasword Safe.

Probably an exception was made here simply because this is intended as a
convenience for users who can't be bothered to memorize passwords, or do
anything else they ought to - of course, using PGP or ScramDisk makes
better sense from a security standpoint, but not everyone will find them
convenient enough to use.

Windows code for a convenient program, as opposed to encryption code, is
harder to release.

John Savard

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

From: David Bernier <[EMAIL PROTECTED]>
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: Mon, 01 Nov 1999 06:44:27 GMT

In article <[EMAIL PROTECTED]>,
  Boaz Lopez <[EMAIL PROTECTED]> wrote:
[...]
> > PROPOSAL: Make use of minute electronic inaccuracies in existing
> > computer
> >           systems. Every computer, no matter how skillfully
designed,
> >           contains some component(s) which can be "tortured" to
extract
> >           entropic data.
> >
> > Examples of Implementation
> >
> > Basic premise: ALL MODERN DIGITAL COMPUTERS CONTAIN BUILT-IN
TRUE-RND
> > GENERATORS,
> >                WHETHER PART OF THE DESIGN OR NOT.
> >
> > (1)
> > The machine you are most likely now using contains a number of
quartz
> > crystals used for timing various processes, including the operation
of
> > the CPU. The crystals are accurate to ~0.02%, as I recall. No two of
> > even the
> > best-made and most accurate quartz crystal timing devices will err
in
> > exactly
> > the same way at any given point of time. Use various system timers
to
> > extract
> > data from relative inaccuracies. Put it through some entropizing
> > algorithm,
> > mix well.
>
> This has been done before by several people. Yes, it works,
> with a degree of quality which is not perfect.

I'd like to propose a method for generating truly random bits
based on "random pictures" taken with a digital camera.

Suppose we tune a TV set to a channel with no local broadcasting on
it.  Let's say also that we have removed the antenna.  Next, we put
the TV (on) inside a Faraday cage (to block as much electro-magnetic
radiation from the outside as possible).  This could be some fine
mesh wire (maybe of the type used in construction to let air in/out and
keep mosquitoes and other pests out?).  We would expect to see "snow"
on the TV screen unless the TV set is "too smart"...  Then we put
a digital camera inside the cage and start taking pictures by
pressing on the button through a small hole in the cage.  We would take
as many pictures as the camera can hold in memory.  Then we would
download the pictures onto a hard drive in big files.  Each picture
file would have to be "distilled" in a prudent way to get some
(supposedly) true random bits.  That's the basic idea.  I see questions
in the areas of:

(1) how random is the TV "snow" to start with?
(2) what happens when you shoot the snow with the digital cam?
    how random are the digital pictures?
(3) what would be a good "mixing, distilling" algorithm to be
    applied to the entropy in the snow-files ?
(4) what would the throughput rate be in bits per second?
(5) what about automating the procedure so that the camera could take
    say 20,000 pictures a day?

David Bernier


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

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

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Symetric cipher
Date: Mon, 01 Nov 1999 06:50:25 GMT

"Trevor Jackson, III" wrote:
> Douglas A. Gwyn wrote:
> > How sad that NSA makes a special effort to avoid spying on US
> > citizens??  Maybe you should explain why you think that's "sad".
> That you believe that just because there are rules everyone follows
> them.  Do you also believe everything that you read in the newspapers?

You are making stupid assumptions.

I have first-hand knowledge of the actual processes.
Indeed, the entire DoD is constrained in its operations by the
requirement to avoid spying on the natives.  There are procedure
manuals (TMs, TBs, etc.) detailing all this that troops involved in
intelligence operations have to study during their training, and
intelligence agency employees are cautioned about this law during
their indoctrination.

It is always possible that individuals might not follow the policy,
but it is certain what the policy is.

You have more to fear from the DoJ than from the DoD (of which NSA
is a part), because the DoJ is much more susceptible to political
pressure from the WH.  Recall J. Edgar Hoover..

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

From: "Rick Braddam" <[EMAIL PROTECTED]>
Subject: Re: Bruce Schneier's Crypto Comments on Slashdot
Date: Mon, 1 Nov 1999 01:00:42 -0600

Trevor Jackson, III <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]...
> Dave Knapp wrote:
>
> > Jerry Coffin wrote:
> > >
> > > Sorry, but "secret" and "top secret" are both classified.  The levels
> > > of classification start with confidential, run though secret and top
> > > secret.  There are more classifications above that as well, such as
> > > TS/SBI and TS/SCI, but these are (at least theoretically) divisions of
> > > top secret, not entirely new classifications themselves.  In fact, the
> > > "TS" on the beginning of these stands for "Top-Secret."  OTOH, for
> > > most practical purposes, TS/SBI and TS/SCI are two more levels of
> > > classification "above" the usual Top-Secret.
> >
> > Completeness requires me to add that there is at least one other
> > category of classified data: Restricted Data (RD).  It is added to the
> > others as is SCI or SBI.  It's for nuclear weapons data.
>
> It used to be the case that crypto was also a separate classification.  It
> may still be.
>
I retired from the Air Force in 1986, so I don't know about since then, but up until I 
retired TS/Crypto was still a separate
classification. Another thing I thought someone would have caught by now is the SBI. 
That stands for Special Background
Investigation, which is the type of investigation Defense Investigative Services 
performs before the Top Secret clearance will be
awarded. There was (is?) another called Bring-Up SBI which is performed every five 
years after the SBI.

Rick




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

From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: comp.compression
Subject: Re: Build your own one-on-one compressor
Date: Mon, 01 Nov 1999 09:29:05 GMT

In article <[EMAIL PROTECTED]>, Mok-Kong Shen <[EMAIL PROTECTED]> 
wrote:
>Tim Tyler wrote:
>> 
>> In sci.crypt Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>> : I meant this:
>> 
>> :       Side1        Side 2
>> :       ABCD         HG
>> :       ABCDHN       UK
>> :       XYZ          PQ
>> 
>> : Now XYZABCDABCD goes to PQHGHG. But the modified PQHGHN comes back
>> : as XYZABCDHN and this goes to XYZUK. Or do I miss something?
>> 
>> Well, XYZABCDHN would seem to go to PQUK...
>> 
>> However your problem is that your dictionary is fundamentally screwed ;-)
>> 
>> If fails to obey the first constraint on dictionary entries I mentioned in
>> my original monograph.
>> 
>> To quote the section from http://www.alife.co.uk/securecompress/ that I
>> quoted in the post at the head of this thread:
>> 
>> ``* No string in the tables should contain another such string as a
>>     substring;
>> 
>>   * No leading symbols in any string should exactly match the trailing
>>     symbols in a different string.''
>> 
>> "ABCD" is a substring of "ABCDHN".  Your dictionary thus violates my first
>> condition, and should not have been used in the first place.
>
>First, let me remark that your first condition is very unreasonable
>for a dictionary. For if your symbols are the normal alphabet,
>I don't see that you can construct such a dictionary at all for
>transcribing English texts. (Compare a normal dictionary.) The second 
>condition is similar to that of Huffman encoding (now at byte level), 
>but it is unreasonable and not applicable for the same reason.
>
>Second, there is no problem for me to construct a case satisfying
>your conditions but nonetheless doesn't work:
>
>          Side1        Side 2
>          ABCD         HG
>          HTHN         UK
>          XYZ          PQ
>
>XYZABCDABCD goes to PQHGHG. I modify this to PQHTHN. It
>comes bach to XYZHTHN. Now this goes to PQUK. Or do I again miss
  You mean it comes back as XYZUK   which goes back to PQHTHN
  no problem. SO maybe you did miss something. 
>something?
>
>M. K. Shen


David A. Scott
--

SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
                    
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm

Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm

Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm

**NOTE EMAIL address is for SPAMERS***

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

From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: the ACM full of Dolts?
Date: Mon, 01 Nov 1999 10:07:11 GMT

In article <[EMAIL PROTECTED]>, Mok-Kong Shen <[EMAIL PROTECTED]> 
wrote:
>SCOTT19U.ZIP_GUY wrote:
>> 
>> In article <[EMAIL PROTECTED]>, Mok-Kong Shen
> <[EMAIL PROTECTED]> wrote:
>> >SCOTT19U.ZIP_GUY wrote:
>> >>
>> >
>> >>    Why add anything extra to the plaintext when it clearly is not needed?
>> >
>> >Well, I think that practical considerations may justify that.
>> >Consider the two cases:
>> >
>> >(1) Add no length information. Use your modification of Huffman.
>> >
>> >(2) Add length information. Use adaptive Huffman.
>> >
>> >The first case employs something that is not yet in wide-spread
>> >use (and hence the user must study its correctness), while the
>> >second is well-known technique. The second, as discussed previously,
>> >adds some 'effective key' bits for encryption and that could be
>> >advantageous.
>> >
>> >M. K. Shen
>>    I am lost. My modifcation was to an "adaptive huffman compression"
>> and yes i agree you could add a training string to make the compression
>> part of the encryption but I think it is easer to analyse this with no
>> training string first. If the compression  does what it is supose to do
>> then one could add the training string to the overall system since this
>> would increae the effective length of the encryption key for the encryption
>> process that follows the compression.
>
>Let me repeat: If one has an initial frequency distribution that
>the analyst can't figure out, then he can't do any compression or
>decompression properly. In that case the failure to meet the
>one-to-one property can namely have two different causes:
>(1) The key he tried to decrypt is right but his guess of the 
>    initial frequency distribution is wrong.
>(2) The key he tried to decrypt is wrong.
>
>Now since his chance of correctly guessing the distribution in
>case (1) is very low, this means that encountering the non-one-
>to-one property tells him practically nothing whether the key
>he tried is right or wrong, i.e. in the present scheme he also can't 
>get the kind of information that your scheme is designed to prevent 
>him from obtaining with your one-to-one property. I hope this
>is understandable to you now.
>
   Sorry but I know less of what you are driving at than the time before.



David A. Scott
--

SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
                    
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm

Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm

Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm

**NOTE EMAIL address is for SPAMERS***

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

From: [EMAIL PROTECTED]
Crossposted-To: talk.politics.crypto,sci.answers,news.answers,talk.answers
Subject: Cryptography FAQ (01/10: Overview)
Date: 1 Nov 1999 11:28:18 GMT
Reply-To: [EMAIL PROTECTED]

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

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

From: [EMAIL PROTECTED]
Crossposted-To: talk.politics.crypto,sci.answers,news.answers,talk.answers
Subject: Cryptography FAQ (02/10: Net Etiquette)
Date: 1 Nov 1999 11:28:23 GMT
Reply-To: [EMAIL PROTECTED]

Archive-name: cryptography-faq/part02
Last-modified: 94/06/13


This is the second of ten parts of the sci.crypt FAQ. The parts are
mostly independent, but you should read the first 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.

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.



Contents:

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?


2.1. What groups are around? What's a FAQ? Who am I? Why am I here?

  Read news.announce.newusers and news.answers for a few weeks. Always
  make sure to read a newsgroup for some time before you post to it.
  You'll be amazed how often the same question can be asked in the same
  newsgroup. After a month you'll have a much better sense of what the
  readers want to see.

2.2. Do political discussions belong in sci.crypt?

  No. In fact some newsgroups (notably misc.legal.computing) were
  created exactly so that political questions like ``Should RSA be
  patented?'' don't get in the way of technical discussions. Many
  sci.crypt readers also read misc.legal.computing, comp.org.eff.talk,
  comp.patents, sci.math, comp.compression, talk.politics.crypto,
  et al.; for the benefit of people who don't care about those other
  topics, try to put your postings in the right group.

  Questions about microfilm and smuggling and other non-cryptographic
  ``spy stuff'' don't belong in sci.crypt either.

2.3. How do I present a new encryption scheme in sci.crypt?

  ``I just came up with this neat method of encryption. Here's some
  ciphertext: FHDSIJOYW^&%$*#@OGBUJHKFSYUIRE. Is it strong?'' Without a
  doubt questions like this are the most annoying traffic on sci.crypt.

  If you have come up with an encryption scheme, providing some
  ciphertext from it is not adequate. Nobody has ever been impressed by
  random gibberish. Any new algorithm should be secure even if the
  opponent knows the full algorithm (including how any message key is
  distributed) and only the private key is kept secret. There are some
  systematic and unsystematic ways to take reasonably long ciphertexts
  and decrypt them even without prior knowledge of the algorithm, but
  this is a time-consuming and possibly fruitless exercise which most
  sci.crypt readers won't bother with.

  So what do you do if you have a new encryption scheme? First of all,
  find out if it's really new. Look through this FAQ for references and
  related methods. Familiarize yourself with the literature and the
  introductory textbooks.

  When you can appreciate how your cryptosystem fits into the world at
  large, try to break it yourself! You shouldn't waste the time of tens
  of thousands of readers asking a question which you could have easily
  answered on your own.

  If you really think your system is secure, and you want to get some
  reassurance from experts, you might try posting full details of your
  system, including working code and a solid theoretical explanation, to
  sci.crypt. (Keep in mind that the export of cryptography is regulated
  in some areas.)

  If you're lucky an expert might take some interest in what you posted.
  You can encourage this by offering cash rewards---for instance, noted
  cryptographer Ralph Merkle is offering $1000 to anyone who can break
  Snefru-4---but there are no guarantees. If you don't have enough
  experience, then most likely any experts who look at your system will
  be able to find a flaw. If this happens, it's your responsibility to
  consider the flaw and learn from it, rather than just add one more
  layer of complication and come back for another round.

  A different way to get your cryptosystem reviewed is to have the NSA
  look at it. A full discussion of this procedure is outside the scope
  of this FAQ.

  Among professionals, a common rule of thumb is that if you want to
  design a cryptosystem, you have to have experience as a cryptanalyst.

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


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