Cryptography-Digest Digest #387, Volume #10 Mon, 11 Oct 99 06:13:02 EDT
Contents:
Re: on linear keyspaces
Re: on linear keyspaces
Re: on linear keyspaces (Tom St Denis)
Re: classifying algorithms
Re: Help: Mobility of the Private Key within PKI ([EMAIL PROTECTED])
Re: Ritter's paper (wtshaw)
Re: classifying algorithms (wtshaw)
Re: Ritter's paper (wtshaw)
Re: Block encryption with variable keys (wtshaw)
Re: Compression of encrypted data (wtshaw)
Re: Block encryption with variable keys (Mok-Kong Shen)
Re: Compression of encrypted data (Mok-Kong Shen)
Cryptography FAQ (01/10: Overview) ([EMAIL PROTECTED])
Cryptography FAQ (02/10: Net Etiquette) ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: on linear keyspaces
Date: 11 Oct 99 01:49:00 GMT
Tim Tyler ([EMAIL PROTECTED]) wrote:
: However, to my mind, the whole point of eliminating clues from the
: compression algorithm is that it makes *other* types of cryptanalysis
: (*besides* brute-forcing the keyspace) more difficult - by removing
: statistical artefacts from the compressed text.
You are quite correct.
Compressing text so well that an intelligent mind, and not a computer
program, could tell when a brute-force search found actual text is *way*
beyond the state of the art, and would be very computationally costly.
John Savard
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: on linear keyspaces
Date: 11 Oct 99 01:50:46 GMT
Tom St Denis ([EMAIL PROTECTED]) wrote:
: Ok I should have said flat keyspaces, but my point is still valid. If the
: keyspace is flat, then NO OTHER attack exists.
That's simply not true. A keyspace is "flat" if no keys are particularly
better or worse than other keys, but they can still be all equally bad.
A table is level whether or not it is high.
John Savard
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: on linear keyspaces
Date: Mon, 11 Oct 1999 02:02:21 GMT
In article <7trcoc$sfe$[EMAIL PROTECTED]>,
Tim Tyler <[EMAIL PROTECTED]> wrote:
> No. /None/ of these are known to fulfill this requirement. If you
> believe otherwise, I will not be convinced of the fact until you
> demonstrate it in some manner.
Ok hotshot, prove that you exist. I mean what I stated is assumed truth. go
with it.
> No, no, I'm talking about attacks on the *cypher*.
>
> Many, many, cyphers have been broken by cryptanalysis, exploiting
> features of the plaintext, using tools such as freqiency analysis.
Uh, frequency analysis hardly works against block ciphers of 64-bits or
128-bits. It really doesn't work with salted keys and/or compressed
plaintext.
> Modern cyphers make this approach more difficult, but are still /far/
> from making the best approach to breaking them an exhaustive search -
> assuming you have sufficient cyphertext, etc.
>
> You seem to argue as though the science of cryptanalysis has been
> reduced to mere brute force searching by modern cypher techniques.
> This is very far from the case.
Assuming you have enough plaintext... hehehe do you actually know how much
plaintext you need to break des? try 2^50 bytes or so.... if you can encrypt
at 2^20 bytes a second, it still takes 1073741824 seconds (or 34 years) to
encrypt this much info. You would need a seriously parelled network to
maintain this.
For RC5 at 12 rounds you need 2^53 blocks or 2^56 bytes. Assuming you can
test at 2^19 (which is what my K6 gets), and you have 262144 (2^18)
computers or so.... it still will take 65536 seconds, of which the last
'gathering' step would take much longer...
At anyrate most ciphers are presumed strong when the theory suggests that the
only available models are so bad that they cannot reliable work.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: classifying algorithms
Date: 11 Oct 99 02:11:53 GMT
Doug Stell ([EMAIL PROTECTED]) wrote:
: No. The hallmarks of a stream cipher are the existence of a key
: stream generator, continuously changing state of the generator and
: use of the XOR function. RC4 has all of these characteristics. A block
: cipher, on the other hand, has a fixed input to output mapping for
: each key value.
What would you call a cipher that has an internal state that changes with
each byte enciphered, and for each internal state has a particular input
to output mapping of input bytes to output bytes?
However, you are definitely right that RC4 has all the hallmarks of the
most extreme form of stream cipher, which I would call the pure PRNG
stream cipher.
John Savard
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Help: Mobility of the Private Key within PKI
Date: Mon, 11 Oct 1999 04:18:21 GMT
I would like to clarify things:
I do not intend to use the hash of a passphrase as a Private Key. In my
original post I said that perhaps I could use the hash of the
passphrase as a key to encrypt the Private Key.
Let's say my R=MY_Private_Key_To_be_used_by_RSA
I can use The Triple Des to encrypt R.
The key to TripleDes is DesKey=Hash(PassPhrase)
Then encrypted Private Key is: ER=3Des(DesKey,R).
I can store ER on the server. This server itself does not need to have
the ability to decrypt my private key. The server simply gives the
cipher to me when I request it. Then I can decrypt my Private Key.
I also received e-mails that suggest to use protocols such as SPEKE.
I looked at it and it seems that it would do just fine especially
because SPEKE was just integrated within ENTRUST PKI version #5.
Entrust did this to accomodate those with my demands: romaing users.
Thanks.
In article <[EMAIL PROTECTED]>,
Medical Electronics Lab <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > It would be nice if there was some kind of private key server.
> > The user would login through an application that runs on the
> > workstation. The application would request user's private key from
the
> > server. The server would send that private key. Even though the
private
> > keys are stored on the server only the private key owner can
utilize the
> > key since the server store the keys in the encrypted fashion:
> > TripleDes(hash(user_password),PrivateKey).
> > Since only the key owner knows the password the key can only be
used by
> > the owner.
> >
> > Do such scenarios currently exist?
> > If not then what are the common solutions to the situations where
the
> > enterprise has a PKI which does not restrict the users to their
> > workstations?
>
> Why do the private keys need to be stored anywhere but in
> the users head? If you use the hash of a pass phrase as the
> private key, then only the terminal the user has access to
> needs to be secure. This is easily done using an elliptic
> curve PK system since the private key can be anything.
> The private key can be verified from the public key, so making
> the public key non-changeable except under specific conditions
> is the next level of security. And you need that for any
> system like this.
>
> Patience, persistence, truth,
> Dr. mike
>
--
Alex Bykov [EMAIL PROTECTED]
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Ritter's paper
Date: Sun, 10 Oct 1999 23:22:44 -0600
In article <[EMAIL PROTECTED]>, "Trevor Jackson, III"
<[EMAIL PROTECTED]> wrote:
> wtshaw wrote:
> >
> > It can be very revealing that a particular algorithm requires a
> > unreasonable quantity of ciphertext to attack, which, according to my
> > calculations in one situation, could be very many times the length of the
> > key. By definition, placing high here means that it is a very good
> > algorithm indeed.
>
> This is false. It is based on the several mixtures above of attack
strength (or
> efficiency) and cipher strength.
>
> Specifically, a particular [cipher] algorithm does not require an quantity of
> ciphertext to attack. A particular attack on a particular cipher requires a
> quantity of ciphertext. There may be many attacks on a particular
cipher, each
> attack requiring a different amount of ciphertext or plaintext.
Additionally, some
> attacks can be performed more or less efficiently depending upon the amount of
> ciphertext available.
In choosing a cipher to improve, I picked one that was unlike may others,
and promised blessed few ways to go after it. I saw where the existing
strengths were and compounded the advantage, going from something
requiring a window of ciphertext in a ballpark amount to astronomical
levels in the current design. It is rather specific why I am interested in
critical levels of data for solution, seemingly the only critical measure.
>
> Thus placing high in the amount of ciphertext does not tell us anything
about the
> strength of the cipher. It tells us something about the lack of power (or
> efficiency as defined above) in the attack. A cipher sustaining no efficient
> attacks is not strong. Its strength is unknown. A cipher sustaining an
eficient
> attack is at least as weak as indicated by the most efficient attack.
But that
> shows only the upper bound on the cipher's strength, and does not tell
us anything
> about potentially even more powerful attacks (even weaker spots in the target
> cipher).
True of many ciphers, but only if subject to attack in a myrid of ways.
--
Figures lie, and liars figure.--Daria Dolan
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: classifying algorithms
Date: Mon, 11 Oct 1999 00:08:42 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] () wrote:
>
> But for a stream of binary bits, there's no hard and fast natural unit. Is
> anything above a single bit a block cipher? Five bits? Six bits? Eight
> bits? After all, 5, 6, or 8 bits have all been used to stand for single
> characters, and a simple substitution alphabet even of 8-bit bytes is a
> short table. Then, there's Unicode, with 16-bit characters!
>From time to time, I speak of the convertability of different information
units and there variety. There is no doubt at all that I have written a
variety of ciphers, including a few base three trit ciphers which follow
all the rules for block ciphers, and not a bit to be seen in any of its
simplistic form.
>
> One could make a rule that over 8 bits is a block cipher, and less than 8
> bits (if combined with an 8-bit step) is fractionation, but that is
> arbitrary. On the other hand, taking this argument to the conclusion Terry
> Ritter once did - that DES is merely a simple substitution cipher
> (admittedly on a very large alphabet) - since we can't say over bits where
> being polygraphic begins, seems extremely unsatisfying.
>
With all respect, it is what it is, and fractionation to a bit player
would include those that dine and dance to base ten digits and the specie
so common built useful to the realm.
Be reminded that bit originally, other than a dental problem to a horse,
represented 1/8 of a spanish coin, so divided as to be called pieces of
eight. Or, now, in the area I live 8 bits is one dollar. If you want to
use 8 as a dividing line, you are culturally correct, but only to those
wearing chaps.
--
Figures lie, and liars figure.--Daria Dolan
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Ritter's paper
Date: Sun, 10 Oct 1999 23:22:12 -0600
In article <[EMAIL PROTECTED]>, "Trevor Jackson, III"
<[EMAIL PROTECTED]> wrote:
>
> Do you have any objective evidence that indicates we are getting closer
to being able to measure cipher strength?
It all depends on how picky you are with results. I am satisfied with
such progress as in ciphers can be scaled and some ciphers are obviously
weaker or stronger than others.
Lots of sophisticated so-called modern ciphers are claimed to be strong by
those who do look to hard at the total meaning of strength, is short many
tend to be misguided even as they are zealous in belief that balanced
recursion will not end in a circle.
--
Figures lie, and liars figure.--Daria Dolan
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Block encryption with variable keys
Date: Sun, 10 Oct 1999 23:39:00 -0600
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
I conjecture
> that your asserted aversion to PRNGs might possibly be psychologically
> founded.
That does no make sense to me as I make good use of PRNG's for their
advantage, as a hammer had an advantage to driving nails to a rock. In so
many of my applications, the use of PRNG's is optioanl for the lazy and
easilly mystified, if not for basic convenience.
The fertile fields of crypto use all manner of mechanisms, but to think
that one alone is critical, a minor player, seems to me to be a misguided
prejudice for it. PRNG's can be deviously used in the science that hinges
on deception, but not as a necessity in all things.
Prospective seems to be a good maximum in health a bit more beneficial
than adopting the latest fad as gospel, or pinning beliefs about health on
false assumptions.
--
Figures lie, and liars figure.--Daria Dolan
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: comp.security.pgp.discuss,alt.security.pgp
Subject: Re: Compression of encrypted data
Date: Mon, 11 Oct 1999 00:25:53 -0600
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>
> If the encryption is good, the ciphertext should fairly approximate
> a random string. It could theoretically be compressed further some
> little bit. But why do you want to do that? To save some transmission
> costs? I suppose the research effort to compress encrypted files
> could be better spent to improve the encryption methods, thus achieving
> better security.
>
I hope you have not forgotten the past exercise we went though here some
time ago in which I demonstrated the ciphertext could be manupulated to
skew or flatten it rather simply.
Indeed, efforts to do that sort of thing the hard way seem to be
unjustified. It is just as good to throw the analyst a bone that will
lead him off a cliff as to make it only a contest of subtilities that he
still might win. I will grant that some algorithms are so bad in a
profile sense that anything will help them.
--
Figures lie, and liars figure.--Daria Dolan
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Block encryption with variable keys
Date: Mon, 11 Oct 1999 10:51:55 +0200
wtshaw wrote:
>
> In article <[EMAIL PROTECTED]>, Mok-Kong Shen
> <[EMAIL PROTECTED]> wrote:
>
> I conjecture
> > that your asserted aversion to PRNGs might possibly be psychologically
> > founded.
>
> That does no make sense to me as I make good use of PRNG's for their
> advantage, as a hammer had an advantage to driving nails to a rock. In so
> many of my applications, the use of PRNG's is optioanl for the lazy and
> easilly mystified, if not for basic convenience.
Since I don't know your applications, I certainly can't exclude the
truth of your claim in those cases. On the other hand, PRNGs are
essential to stream encryption, even for those that are lazy. If you
disregard the artificial line of demarcation between stream and block
encipherment, you'll see my point, I guess.
> The fertile fields of crypto use all manner of mechanisms, but to think
> that one alone is critical, a minor player, seems to me to be a misguided
> prejudice for it. PRNG's can be deviously used in the science that hinges
> on deception, but not as a necessity in all things.
Did I ever say that PRNG is one alone that is critical? Please kindly
allow me to cite a part of a sentence that I wrote in the previous
post:
........., you'll consider PRNG to be an entirely normal
component for use in crypto design just as any other useful
building blocks, ............
(I was putting PRNG on an equal footing with the others, assigning
to it no special status at all.)
M. K. Shen
===========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: comp.security.pgp.discuss,alt.security.pgp
Subject: Re: Compression of encrypted data
Date: Mon, 11 Oct 1999 10:52:02 +0200
wtshaw wrote:
>
> In article <[EMAIL PROTECTED]>, Mok-Kong Shen
> <[EMAIL PROTECTED]> wrote:
> >
> > If the encryption is good, the ciphertext should fairly approximate
> > a random string. It could theoretically be compressed further some
> > little bit. But why do you want to do that? To save some transmission
> > costs? I suppose the research effort to compress encrypted files
> > could be better spent to improve the encryption methods, thus achieving
> > better security.
> >
> I hope you have not forgotten the past exercise we went though here some
> time ago in which I demonstrated the ciphertext could be manupulated to
> skew or flatten it rather simply.
>
> Indeed, efforts to do that sort of thing the hard way seem to be
> unjustified. It is just as good to throw the analyst a bone that will
> lead him off a cliff as to make it only a contest of subtilities that he
> still might win. I will grant that some algorithms are so bad in a
> profile sense that anything will help them.
I am sorry that my memory has failed me to recall the discussion
you mentioned. (I doubt at least that I had ever taken an active part
in that.) On the other hand, I don't think that anything one
enciphers with a modern good cipher, say, DES, could be compressed
to any non-trivial amount (say to less then 98%). It would be
interesting if someone could show certain actual figures. The fact
that one attempts to crack DES with such sophisticated methods as
differential analysis and not frequency analysis of ciphertext
lends essential heuristic support to my conjecture.
M. K. Shen
==========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: talk.politics.crypto,sci.answers,news.answers,talk.answers
Subject: Cryptography FAQ (01/10: Overview)
Date: 11 Oct 1999 09:45:10 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: 11 Oct 1999 09:45:12 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
******************************
