Cryptography-Digest Digest #89, Volume #13 Sat, 4 Nov 00 05:13:01 EST
Contents:
Re: Crypto Export Restrictions (Anthony Stephen Szopa)
Re: Crypto Export Restrictions (Anthony Stephen Szopa)
Re: Crypto Export Restrictions (Anthony Stephen Szopa)
Re: Crypto Export Restrictions (David Schwartz)
Re: Crypto Export Restrictions (Anthony Stephen Szopa)
Re: Crypto Export Restrictions (David Schwartz)
Re: very large mult. div. (Richard Heathfield)
Re: On introducing non-interoperability (Mok-Kong Shen)
Re: Q: Computations in a Galois Field (Mok-Kong Shen)
Re: RSA vs. Rabin (D. J. Bernstein)
Cryptography FAQ (01/10: Overview) ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,talk.politics.misc,alt.freespeech
Subject: Re: Crypto Export Restrictions
Date: Fri, 03 Nov 2000 23:04:07 -0800
Jeffrey Williams wrote:
>
> Comments are in line for clarity.
>
> Anthony Stephen Szopa wrote:
>
> >
> > "IIRC people could not gleen exactly how the algorithm worked by
> > reading those files,..."
> >
> > How do you know?
> >
> > What does "gleen" mean? Is that a new toothpaste?
>
> Glean ("gleen" was a misspelling) means to gather information or material
> bit by bit (Meriam-Webster).
>
> >
> >
> > If you don't get it from reading the Help files you need to learn
> > how to read. Many many people have read the Help files and ran
> > the software and are using the software and they understand it all
> > perfectly well.
>
> The ability to use software effectively does not imply that the user
> understands the underlying algorithms of the software.
You'd make a very good prosecutor: for the defense.
God forbid you ever become a judge.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,talk.politics.misc,alt.freespeech
Subject: Re: Crypto Export Restrictions
Date: Fri, 03 Nov 2000 23:06:52 -0800
"Trevor L. Jackson, III" wrote:
>
> Anthony Stephen Szopa wrote:
>
> > Scott Craver wrote:
> > >
> > > Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
> > > >CiPHER wrote:
> > > >>
> > > >> *waggles fingers* OoooOOOooo! 'Nasty person'! lol
> > > >>
> > > >
> > > >Thank you for your intelligent input.
> > > >
> > > >Like we really need more of this.
> > >
> > > ...," he says, posting a follow-up.
> > >
> > > Have you posted the algorithm yet for your pseudorandom
> > > number generator, or is it still just the "help files?"
> > > IIRC people could not gleen exactly how the algorithm
> > > worked by reading those files, and thus could not subject
> > > it to analysis.
> > >
> > > By the way, since your PRNG uses permutations, it uses
> > > "mathematical equations." If you don't think it involves
> > > math because it uses compositions of permutations rather
> > > than products of large integers, then you need to read some
> > > abstract algebra textbooks. And your customers need to
> > > _know_ that you need to read some abstract algebra textbooks.
> > >
> > > You don't need to give out the source code, but something
> > > like pseudocode for the generator part would be ideal.
> > >
> > > -S
> > >
> > >
> >
> > "IIRC people could not gleen exactly how the algorithm worked by
> > reading those files,..."
> >
> > How do you know?
> >
> > What does "gleen" mean? Is that a new toothpaste?
> >
> > If you don't get it from reading the Help files you need to learn
> > how to read. Many many people have read the Help files and ran
> > the software and are using the software and they understand it all
> > perfectly well.
> >
> > You, like so many before you, have a wild hair up your ass and do
> > not have the slightest ability to simply sit down and work it
> > through. It is very very simple. If you are not interested then
> > forget about it. You have no excuses. Many others have done
> > perfectly well. You have not even tried or have given up.
> >
> > No one listens to a loser.
> >
> > If you have some valid criticism of the software post it and support
> > your position with facts.
>
> Let me get this straight. You want "valid criticism" of the software you
> will not provide or describe. I suppose the "valid" part implies an
> objective standard of rigor based on which side of the bed you got out of
> and what you had for breakfast?
>
> Here's a fact for you: Your software does not deliver on your promises.
> So it is defective.
>
> <high temperature "you" (singular, personal)>
>
> Now you may have a wild hair across a sensitive part of our anatomy and
> obviously do not have the ability to simply sit down and work it through.
> It is very simple. If you are not interested in this fundamental fact you
> should forget about posting in sci.crypt. You have no excuses. Many
> others understand cryptography perfectly well. You have not even tried or
> have given up.
>
> </high temperature "you" (singular, personal)>
>
> >
> >
> > So far you are just a whiner who does not do his homework.
>
> And I'm only holding up a mirror.
Everything is explained in the help files.
That is what you cannot get straight.
If you are not interested just forget about it.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,talk.politics.misc,alt.freespeech
Subject: Re: Crypto Export Restrictions
Date: Fri, 03 Nov 2000 23:09:17 -0800
Scott Craver wrote:
>
> Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
> >
> >If you don't get it from reading the Help files you need to learn
> >how to read. Many many people have read the Help files and ran
> >the software and are using the software and they understand it all
> >perfectly well.
>
> We're not talking about how to _use_ the software, but
> the specific algorithm it is based on.
>
> If you want people to analyze your PRNG, output source
> code or good pseudocode (no steps missing, no ambiguous
> bits) for the PRNG part of the software.
>
> >If you have some valid criticism of the software post it and support
> >your position with facts.
>
> Valid criticism: you won't provide a sufficiently readable
> description of your algorithm.
>
> Why don't you just _look_ at the way real PRNGs are described
> in _Applied Cryptography_? Diagrams and source code are
> provided which explain them unambiguously. People will use
> them, rather than your system.
>
> Valid criticism #2: a program requiring a user to futz around
> (w/ a deck of cards, say) for fifteen minutes to generate a
> crypto key is like a TV requiring a user to mess with a slide
> rule for 15 minutes in order to change a channel.
>
> Valid criticism #3: before people on sci.crypt corrected you,
> you were calling your program a One-Time-Pad (which it is not.)
> I suspect that if people on this group weren't here to keep you
> honest, you'd have made all sorts of false claims about your
> system.
>
> >So far you are just a whiner who does not do his homework.
>
> Speaking of homework, let me know if you want some good
> exercises on permutation groups. It is math, you know.
>
> -S
Have you read the help files?
How many times?
I know what interest is. I've been told by several people of the
effort they made making sure they understood the software.
If you want to discuss your own imaginings go right ahead.
Apparently there are several others here to keep you company.
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,talk.politics.misc,alt.freespeech,alt.hacker
Subject: Re: Crypto Export Restrictions
Date: Fri, 03 Nov 2000 23:14:26 -0800
Terry Ritter wrote:
> Crystal oscillators do drift with temperature, but not much, in
> relative terms. These devices are specifically engineered to drift as
> little as possible (consistent with cost). So if one was depending on
> frequency changes to produce unknowable values, a crystal oscillator
> would be the absolute *last* device one would want to use.
You are confusing compensated oscillators with uncompensated
oscillators. Cheap oscillators like those used to generate clocks for
computers and network cards are not particularly stable with respect to
temperature. The reason is exactly what you said, cost. It costs more to
make it stable, so they're seldom made more stable than neccesary.
> "Microscopic temperature variations" will produce tiny frequency
> changes, but they will be far too small to notice (unless the crystal
> is used in radio, where down-conversions magnify the relative change).
> The changes are also reproducible and predictable, given knowledge of
> the temperature. Even worse, frequency changes can be inferred and
> tracked, when deterministic events occur at somewhat different times
> than expected. This is not cryptographic strength.
With a 500Mhz Pentium, a one part per billion drift will give a single
bit of entropy in two seconds. A typical uncompensated crystal
ocscillator has a repeatability of about 8 parts per billion from second
to second. That is, the average cycle time for one second compared to
the average cycle time over the next second will typically differ by
about 8 parts per billion. This is measurable. Really.
> PC keyboards generally are scanned by a single-chip processor which
> has its own crystal for the processor clock oscillator. A cheap
> crystal might drift +/- 50 PPM (Parts-Per-Million) with -/+ 10 deg C
> temperature change (and much less thereafter). [ See, for example:
You are confusing the drift of the average with the drift from cycle to
cycle. Even with apparently constant temperature (not in an oven, but
nothing specifically changing the temperature either, the oscillator
dithers.
> With a keyboard processor clock of 5 MHz, 50 PPM is 250 Hz. So
> instead of having the original frequency of 5,000,000 cycles per
> second, we now have 5,000,250 or 4,999,750, across 20 deg C. That is
> a 500 Hz change out of 5,000,000 Hz, which is 1 part in 10,000 or
> 1/100th of a percent.
>
> So if we have a keyboard scan rate of 20 msec, and the temperature
> changes by 20 deg C, we might get a 20.001 msec scan. But knowing the
> scan rate to this precision would lead to pretty good deterministic
> prediction estimates, even *with* temperature changes.
Wrong. The temperature changes vary from region to region inside the
case.
> > In any event, the presence of the word "like" is the sentence above is
> >there because this is not the only source used. Other sources are used
> >that have better randomness in them, such as low-order TSC bits sampled
> >at packet arrival.
>
> But if those other sources really are "like" the keyboard, they can't
> be nearly as helpful as you first implied.
Nonesense. You really have nothing but an argument from personal
incredulity.
DS
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,talk.politics.misc,alt.freespeech
Subject: Re: Crypto Export Restrictions
Date: Fri, 03 Nov 2000 23:25:02 -0800
James Felling wrote:
>
> Scott Craver wrote:
>
> > Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
> > >CiPHER wrote:
> > >>
> > >> *waggles fingers* OoooOOOooo! 'Nasty person'! lol
> > >>
> > >
> > >Thank you for your intelligent input.
> > >
> > >Like we really need more of this.
> >
> > ...," he says, posting a follow-up.
> >
> > Have you posted the algorithm yet for your pseudorandom
> > number generator, or is it still just the "help files?"
> > IIRC people could not gleen exactly how the algorithm
> > worked by reading those files, and thus could not subject
> > it to analysis.
> >
>
> As someone who has attempted to understand Mr. Szopa's algo in the past,
> unless he has changed or adjusted things, how it works is via lots and
> lots and lots of user intervention. There are any number of
> inneficiencies in the algorithim, and to generate a useful ( i.e.
> potentially secure) key you must spend at least 15min to 1/2 hour typing
> your "keying data" in.
>
> He probably achieves a fairly good RNG iff you are willing to work hard
> at setup, and have a good understanding of how it works, and permutative
> math. OTOH almost any ARCFOUR/RC4 implementation will blow the doors
> off of it as far as speed to setup, ease of avoiding weak keys, and
> should be comparable as to speed.
>
> I have estimated that (assuming no better attacks vs. his RNG are found
> than those that I have observed in the short time in which I examined his
> math/algo) his algorithim uses about an order of magnitude more keying
> than RC4 to achieve the same results. In general, I wouldn't bother with
> it. PGP, or any other reputable crypto program will achieve results that
> are as good (if not substantially better) , with much less time and
> effort upon the user's part.
>
> >
> > By the way, since your PRNG uses permutations, it uses
> > "mathematical equations." If you don't think it involves
> > math because it uses compositions of permutations rather
> > than products of large integers, then you need to read some
> > abstract algebra textbooks. And your customers need to
> > _know_ that you need to read some abstract algebra textbooks.
> >
>
> It is my considered opinion that Mr. Szopa is self taught, and unawqare
> of some of the more sophisticated elements of permutation theory.
>
> >
> > You don't need to give out the source code, but something
> > like pseudocode for the generator part would be ideal.
> >
> > -S
> >
> >
>
> Pseudo code for the generator part is ugly. Here is a rough version -- I
> am not at my notes to make certian that this is 100% accurate, and I only
> have e-mail access on the PC I am at presently so I cannot verify it at
> the website.
>
> Step1 :Generate mix files
> For i=1 to 3
> A)Start with a file F(i) containing an ordered list of all permutations
> of {0123456789}
> B)User chooses a method, inputs required data(methods are simple
> permutations of File F)
> C)File is permuted accordingly.
> D) GO back to 1B if user feels inclined to.
> next i
> Now you have the three mix files
>
> Generation involves
> n=1
> Take the three F(i)'s and chose nth digit from each( notational F(i,n)=
> nth digit of file i) then A) K=100*f(1,n)+10*f(2,n)+f(3,n)
> if K>= 3*256 then n=n+1 go to A
> Output K mod 256
> goto A
>
> There may be some steps missing, but this is very close to the skeleton
> of the system.
I am very glad you posted this.
If they don't even have the G-2 to get it from the Help Files
themselves they sure as hell won't get a clue from what you
posted.
So, they are left with nothing more than your advice.
And if they are happy with that I am happy for them.
Nothing in this world comes easy. These guys wanted to be spoon
fed. I hope they are wise enough to know that they get what they
pay for. In this case, they got what they made the personal effort
to achieve.
And you gave them just that.
Thanks.
Cheers.
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,talk.politics.misc,alt.freespeech,alt.hacker
Subject: Re: Crypto Export Restrictions
Date: Fri, 03 Nov 2000 23:26:37 -0800
Terry Ritter wrote:
> http://www.kita.or.kr/catalog/it/it_2.html
> http://www.ofc.com/piezo/papers/pcso.html
> http://www.anodynecomp.com/joyous/crystals/z49up.html
> http://www.cmindhk.com/crystal.htm
> www.lecroy.com/labs/volumeIVJitterTiming/default.asp#clockoscillatorstability
Of all of these references, only two deal with short-term stability.
One gives a figure of 5 x 10^10. This is consistent of my own
measurements using a 500Mhz CPU clock signal which showed 8 ppb
differences from second to second. No effort is made to stabilize these
oscillators and multipliers because none is needed.
DS
------------------------------
Date: Sat, 04 Nov 2000 07:35:47 +0000
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: very large mult. div.
"Douglas A. Gwyn" wrote:
>
> Richard Heathfield wrote:
> > The third volume is on sorting and searching, and is absolutely
> > fascinating. (I find the first two fascinating too.) How you can find
> > sorting and searching to be boring is beyond me.
>
> Maybe he missed the centerfold!
ROTFL!
Somehow, though, I can't help thinking that any centrefold with the
words "Read backward polyphase merge" on it is unlikely to be high on
the favourites list for most adolescents...
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On introducing non-interoperability
Date: Sat, 04 Nov 2000 08:48:13 +0100
David Schwartz wrote:
>
> In other words, keeping the algorithm secret is equivalent to making
> the key longer.
No. It is not keeping the (enlarged) algorithm secret.
You can consider that there are two keys. One is just
the original and it leads to the original key scheduling.
The other effects a modification of the round keys
to get the ones that really get used. The code of
that (enlarged) algorithm is perfectly known to the
opponent. It is just a new algorithm (a variation
of the old algorithm). There is nothing hidden to
the opponent. Hence it is not keeping the algorithm
secret. It is entirely open to him and hence there
is no security through obscurity. I Hope that's clear
to you now.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Q: Computations in a Galois Field
Date: Sat, 04 Nov 2000 09:17:02 +0100
I like to ask some questions: The choice of the mapping of
x to 1/x in Rijndael has presumably much contributed to
resulting in a very good substitution of that cipher. Is
this fortuitous or is that mapping intrinsically good for
all GF(2^m)? Are there other mappings of comparable quality?
Does the choice of the polynomial effect the diffusion
properties of the resulting substitution, if not why?
Thanks.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (D. J. Bernstein)
Subject: Re: RSA vs. Rabin
Date: 4 Nov 2000 08:05:24 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
> Perhaps Knuth is wrong
In this case, yes, Knuth is wrong. He oversimplified Rabin's signature
system by omitting the hash function. The original system is unbroken;
the oversimplified system, like the original RSA system, is silly.
---Dan
------------------------------
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: 04 Nov 2000 09:45:29 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 (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
