Cryptography-Digest Digest #297, Volume #10 Wed, 22 Sep 99 17:13:03 EDT
Contents:
Re: Purdue's Large Number (Peter Gunn)
Re: Homophones (jerome)
Re: msg for Dave Scott (Anton Stiglic)
Keymaster's br�nder er tilbage only DK,N,S ("Keymaster")
Re: Securing Executables (jerome)
Re: low diffie-hellman exponent (Tom St Denis)
Re: some information theory (very long plus 72K attchmt) (SCOTT19U.ZIP_GUY)
Re: (US) Administration Updates Encryption Export Policy (SCOTT19U.ZIP_GUY)
Re: (US) Administration Updates Encryption Export Policy (Patrick Juola)
Re: frequency of prime numbers? ("Trevor Jackson, III")
Re: (US) Administration Updates Encryption Export Policy ("karl malbrain")
Re: Okay "experts," how do you do it? (jerome)
----------------------------------------------------------------------------
From: Peter Gunn <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Purdue's Large Number
Date: Wed, 22 Sep 1999 17:01:55 +0100
Dave Rusin wrote:
> In article <7samo2$kv4$[EMAIL PROTECTED]>,
> John M. Gamble <[EMAIL PROTECTED]> wrote:
> >"The number Purdue needs to factor is
> >163790195580536623921741301545704495839
> >239656848327040249837817092396946863513
> >212041565096492260805419718247075557971
> >445689690738777729730388837174490306288
> >87379284041.
>
> Typo? Easily found factors of 3, 39341, 46591, 163245571
>From http://www.cs.purdue.edu/homes/ssw/Wagstaff.number.html
1637901955805366239217413015
4670449583923965684832704024
9837817092396946863513212041
5650964922608054197182470755
5797144568969073877772973038
883717449030628887379284041
I think the typo is near the start...
163790195580536623921741301545...
should be
163790195580536623921741301546...
> >Anyone know why this particular number?
>
> No, but the crew at Purdue (Sam Wagstaff et al) have been factoring
> big numbers for many years, in particular shepherding the Cunningham
> Project, seeking factors of numbers of the form b^n +- 1 (b small).
> There are also some other numbers used as cryptographic challenges
> or benchmarks.
>
> >Anyone know of its status as far as factoring goes?
> You quoted a 1997 newspaper article. A 149-digit composite of particular
> interest would have yielded to massive parallel factorization efforts
> using MPQS (say) by now.
>
> dave
>
> Factorization: http://www.math-atlas.org/index/11Y05.html
------------------------------
From: [EMAIL PROTECTED] (jerome)
Subject: Re: Homophones
Date: 22 Sep 1999 18:49:17 GMT
Reply-To: [EMAIL PROTECTED]
On Wed, 22 Sep 1999 14:14:16 GMT, Tim Tyler wrote:
>: Does anyone have any information/can point me in the direction of some
>: good information, regarding the decryption of a monoalphabetic cipher
>: with homophones?
It highly depends on the number of symbols in your cypher texts and
their frequency.
- if the cypher alphabet is almost as small that the supposed plain text
one. just handle it as without homophone and solve the homophones at
the end, 'filling the holes'.
- if the distribution of the cypher alphabet is flat, you have to use
the struture of the text (aka the digraph, trigraphs).
(becarefull, the frequency of digram is less reliable than the
monogram one because you have twice less texts and much more symbols)
>One of his ten cyphers (the uncoding of which would win 10,000 UKP)
>is a monoalphabetic cipher with homophones. That isn't what you
>want the info for - is it? ;-)
about that ... anybody have an electronic version of these cypher texts ?
i dont have a scanner and an ocr :(
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: msg for Dave Scott
Date: Wed, 22 Sep 1999 14:52:55 -0400
"SCOTT19U.ZIP_GUY" wrote:
> In article <7sagud$4ad$[EMAIL PROTECTED]>, Tom St Denis <[EMAIL PROTECTED]>
>wrote:
> >Well you say you can break all encryption methods and systems. Prove it.
> >
> >beaqaaamL6MNs6}utuaaaaiaaaaW{dsG{jC4KzE3hoqb}tWYZ9qT2Fcaaaaaaaaaaaaa
> >aaaaaaaaaaaaaaaaaaaaaaaaa
>
Does trailing aaaaaaaaaaaaaaaaaaa's do look suspicious Tom. I know that sometimes
when
I mistakenly did some operations on a pointer instead of the value of the pointer I got
stuff
like that, repeated symbols. This would be very rare if it realy was the output of a
decent
crypto function. Did you try going throw your code with a debugger, have you compared
different encryption result, is there anything similar between them (if so, you are not
correctly doing the operations....).
Anton
------------------------------
From: "Keymaster" <[EMAIL PROTECTED]>
Subject: Keymaster's br�nder er tilbage only DK,N,S
Date: Wed, 22 Sep 1999 21:27:54 +0200
Reply-To: "Keymaster" <[EMAIL PROTECTED]>
Hej
For alle dem som havde bestilt eller �nsker at bestille en Keymaster br�nder
er der nu h�b forude
:-))
Et firma som hedder VxTools har k�bt softwaren til Keymaster br�nderne og
ferdigudviklet den, det er blevet til et helt nyt produkt som er helt
enest�ende.
Kig forbi www.keymaster-dk.com eller back up siden www.direct-salg.dk
Der er i �jeblikket ca. 14 dages leveringstid
Hilsen
Keymaster
John Hansen
------------------------------
From: [EMAIL PROTECTED] (jerome)
Subject: Re: Securing Executables
Date: 22 Sep 1999 19:02:14 GMT
Reply-To: [EMAIL PROTECTED]
it depends the level of security you want.
if the attackers can run the application (through a debugger or not)
it mean it can read the code and modify it to do whatever they want.
i dont understand what you try to do. explain clearly your aim
>1. Use something like SHA-1 to check the exe at load time for tampering.
>2. Check with SHA-1 periodically as the client is running.
how to do prevent the attacker from simply recomputing the message digest ?
>3. Can we check we're running inside a debugging environment and crash out?
even if you can, you don't prevent any offline modification
>4. Compress and encrypt local data files
where do you store the key ? on the local drive ? not hard to find :)
all that looks a lot like the tricks used by game coders a long time ago
to prevent the crackers to copy or modify their softwares.
Each time the gamecoders loosed badly because it is easy to modify the
executable just to avoid to do the test.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: low diffie-hellman exponent
Date: Wed, 22 Sep 1999 19:34:10 GMT
In article
<[EMAIL PROTECTED]>, Eric
Lee Green <[EMAIL PROTECTED]> wrote:
> Tom St Denis wrote:
> > BTW does anybody care? I haven't gotten any replies!!! Common, it's free,
> > it's small, it packs features and it's not a homebrew!!! common!!!
> >
> > (please?)
> >
> > http://www.cell2000.net/security/peekboo/index.html
>
> Sorry, I live in the U.S.A., and it would be illegal for me to download
> an unlicensed implementation of RC5 or RC6 (they are patented here in
> the U.S., or, rather, one of the mathematical operations within them is
> patented here in the U.S. -- I don't know how that can be, that one can
> patent mathematics, but so it goes here in the funny farm!).
>
> Anyhow, you may want to look at TwoFish or Rijndael, both of which
> promise that they will forever remain patent-unencumbered. So far both
> look okay from a security aspect. You can find implementations at
>
> http://www.seven77.demon.co.uk/cryptography_technology/AES2/index.htm
>
> These are under a BSD-style license that allows free use as long as you
> let folks know that you're using Dr. Gladman's stuff.
Well I already have Twofish in their (along with CAST, Blowfish and XXTEA).
No offense but your excuse is rather lame, do you feel that opressed that you
can't download it or you just don't have the time? (I don't care which).
Second why not just not use RC6,.. so what it's there... it's probably on
your HD in paper form anyways. If you don't want to use it there is always
CAST/Blowfish/Twofish to pick from :)
Tom
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: some information theory (very long plus 72K attchmt)
Date: Wed, 22 Sep 1999 20:57:12 GMT
In article <[EMAIL PROTECTED]>, James Felling
<[EMAIL PROTECTED]> wrote:
>
>Rick Braddam wrote:
>...
>>
>> David Scott promotes using compression before encryption, and several
> responses have agreed with him. If I understand correctly,
>> compression doesn't increase security, but it increases the work factor
> needed to break the encryption. Why isn't that the same as
>> increasing security? "Increase the work factor" should be the same as "makes
> it harder" to break the encryption... isn't that what
>> increasing security means?
>
>Not really. Lets say I want to conduct an attack on your encryption. I know
> that you use compression method X. Further I know that
>your messages have some common starting feature(enough after compression to be
What if you don't know the starting text. The problem with non "one to
one" comp is that they are weak even if the starting portion of the FILE
is not KNOWN. You sir seem to think one always has the start of the
file encrypted that is not necessarily true. What I showed is that non "one to
one" compression weakens the compression followed by encryption even if
there is no information about the input file.
> a block or two of encyphered text, or can submit a
>limited amount of known plaintext.
>I can then use the compressed feature / compressed known text as the plaintext
> recognise decoded plaintext -- thus the work factor for
>some attacks is NOT increased. An increase in security means under any
Your worng the WORK FACTOR Is increased. Also your assuming weak
encryption methods like AES where if the key is the same the front of
file the same the encrypted text is the same. This is common in crypto systems
since it helps the NSA break systems. You can't do the same if an "all or
nothing" type of encryption like scott16u or scott19u. But if you do use
weak AES methods you could take my advice at
(http://members.xoom.com/ecil/compress.htm) site for using
a reverse huffman pass through the file and a common front of
a the starting file will mean very little.
> circumstance the work factor goes up. The big benefit of
>compression is that instead of 1 meg of raw encoded cypher text the adversary
> gets 100K of encyphered text -- much less material to
>analyze and draw conclusions from.
>
>Similarly by creating apropriately massaged plaintexts known plaintext attacks
> may still be carried out -- it just takes a little
>precomputation on the adversary's part.
So I guess that means you would rather use a compression method
where the attacker does not need to slip in plain text for an attack.
I personnel think that giving some the info to break an encryption
for free is a big mistake. But you think that it is ok.
>
>> Maybe it's relative, in that it doesn't make it substantially harder like
> adding one bit to the key
>> would.
>>
>> I couldn't quite figure out how you could uncompress a file which wasn't
> compressed to start with, so I just thought I'd try
>> what David said to do. Here are the files I generated to run a couple of
> tests. It seems that Adaptive Huffman Compression don't
>> particularly like pdf files. I couldn't find enough text files to make up
> 8.4Mb to test with DieHardC, especially since they needed
>> to be that big after compression. ZipMagic with max compression compresses
> much tighter, but if an analyst knows that the first two
>> letters in my plaintext are PK he/she can throw away wrong keys much quicker.
> Of course, I could do as suggested by one here and
>> strip off the header and send it as plaintext, and save the analyst some
> trouble. I just want to be a troublemaker for the analyst.
>>
>> The attachment, outfiles.zip, contains the DieHardC results for each of the
> tests I ran. The first tests use a file of random
>> numbers generated by the Merseinne Twister.
>>
>> Filename Size
>> RNDFILE 8,520,008 The original output from the
> Merseinne Twister
>> the file above passes all DieHardC tests, see rndfile.out for
> results
>>
>> TESTUNC AHC 28,703,076 Original RNDFILE uncompressed to this
>> You CAN use h2unc.exe to uncompress a file that has not been
> compressed
>>
>> TESTCOMP AHC 8,520,270 Original RNDFILE compressed to this (larger)
>> the file above also passes all DieHardC tests
>> see testcomp.out for results
>>
>> TESTUNC ZIP 10,604,680 Uncompressed file zipped to this (max
> comp)
>> ZipMagic (by Mijenix) used for all zip files... equiv to pkzip
> 2.04G
>> See testuncz.out for results
>>
>> TESTUNC CMP 8,520,008 Uncompressed file compressed back to this
>> *note* above file is identical to original (see rndfile &
> rndfile.out)
>> if you uncompress a not-compressed file then compress it you DO
> get the
>> original file back.
>>
>> TEST PDF 13,231,497 test file built from three pdf files
>>
>> TESTCOM AHC 11,745,172 test.pdf file compressed with Adaptive
> Huffman
>> h2com.exe compressor
>> this file passes only 37 of 235 tests, see testcom.out.
>>
>> TEST ZIP 7,057,309 test.pdf file zipped (max
> compression)
>> This file too short for DieHardC, exausted input file at OPERM5
> test.
>> Failed all tests it ran. See testzip.out.
>>
>> The last two tests don't show anything, unless it's that zip compresses
> pdf files better. I doubt that passing 37 out of 235
>> tests is significant. Passing all tests doesn't prove anything, either. It
> only says that the file *looks* random, not that it is.
>>
>> > [EMAIL PROTECTED]
>>
>
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: (US) Administration Updates Encryption Export Policy
Date: Wed, 22 Sep 1999 20:35:44 GMT
In article <7saug8$172$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Patrick Juola)
wrote:
>In article <7s8h7v$9i1$[EMAIL PROTECTED]>,
>Bill Unruh <[EMAIL PROTECTED]> wrote:
>>In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (Jerry
> Coffin) writes:
>>
>>]Third, the primary reason for finding the regulations unconstitutional
>>]was the lack of ability to appeal a decision. The same basic
>>]regulations on export itself could apparently be made constitutional
>>]simply by providing a better process for appealing a decision.
>>
>>]Finally, note that the Bernstein case revolved around the use of
>>]source code as a method of communication between people, so there was
>>]a restriction on the right to free speech. If, for example, you write
>>]source code like Dave Scott's, which nobody can read, that argument
>>]obviously goes out the window. To export source code in accordance
>>]with this decision, you could be called upon to prove that the
>>]_primary_ reason for using source code was simply to provide an
>>]unambiguous method of communicating with another person. If the
>>]primary reason for the source code is to provide for a computer to
>>]take certain actions, it's unlikely that this decision would apply.
>>
>>No. Your speech does not become less protected just because people find
>>difficulty in understanding you.
>
>Legally speaking, it's not a quesiton of ease of understanding, it's a
>question of communicative intent. That's why, for example, there
>are certain restrictions on "commercial speech" (such as advertising)
>that would not be allowed on "political speech." This particular
>distinction is well-accepted in (U.S.) case law and you're unlikely
>to get it overturned no matter how many lawyers you paid.
>
>Dr. Bernstein is in a rather unusual position in that he is researching
>new cryptographic techniques which he then wants to communicate *to other
>researchers* (publish or perish, what fun!) So his intention is
>human-to-human communication, not human-to-computer.
>
>In general, publishing source code for a software package can easily
>be argued not to be "communicating" with other humans; I don't know
>*how* many programs I've compiled without ever looking at the source.
>The law is capable of recognizing the distinction and acting upon it,
>as much as we might wish to the contrary.
>
> -kitten
>
Actually the law is not capable of recognizing the distinction and
acttiing upon it. Just becasue you can't read code does not mean
that the intent of the code was communication.
But I agree the one with the money makes the rules.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: (US) Administration Updates Encryption Export Policy
Date: 22 Sep 1999 16:09:38 -0400
In article <7sbb32$36g6$[EMAIL PROTECTED]>,
SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
>In article <7saug8$172$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Patrick Juola)
>wrote:
>>>No. Your speech does not become less protected just because people find
>>>difficulty in understanding you.
>>
>>Legally speaking, it's not a quesiton of ease of understanding, it's a
>>question of communicative intent. That's why, for example, there
>>are certain restrictions on "commercial speech" (such as advertising)
>>that would not be allowed on "political speech." This particular
>>distinction is well-accepted in (U.S.) case law and you're unlikely
>>to get it overturned no matter how many lawyers you paid.
>>
>>Dr. Bernstein is in a rather unusual position in that he is researching
>>new cryptographic techniques which he then wants to communicate *to other
>>researchers* (publish or perish, what fun!) So his intention is
>>human-to-human communication, not human-to-computer.
>>
>>In general, publishing source code for a software package can easily
>>be argued not to be "communicating" with other humans; I don't know
>>*how* many programs I've compiled without ever looking at the source.
>>The law is capable of recognizing the distinction and acting upon it,
>>as much as we might wish to the contrary.
>>
>
> Actually the law is not capable of recognizing the distinction and
>acttiing upon it. Just becasue you can't read code does not mean
>that the intent of the code was communication.
Actually, whether or not I can read code is irrelevant. The question
is whether or not you can convince the judge and jury of your
intentions. You'll probably be starting out with at least one strike
against you because the *judge* will be the one looking at your code
initially, and he is extremely unlikely to be able to decypher the
best-written computer program in the world; Judge Patel is to be
commended for her work in learning the technobabble surrounding the
Bernstein case.
But, basically, you (or your lawyer) will be claiming that you were
attempting to communicate scientific ideas, and the government's lawyer
will be claiming that you were trying to export munitions. One of the
questions that *WILL* come up is the question of standard practice --
how do practicing professionals in the field of software engineering
and/or cryptography communicate their ideas? Your line of reasoning
might well make the government's case *for* it; you can't be trying
to communicate if you're using a method that no one else uses and
that you have repeatedly been warned against. Similarly, when you
admit that no one else reads (or even better, "can read") code, you
condemn yourself out of your own mouth as your code is obviously
not intended to be read by humans -- or you would write it in
human readable form.
So the law *can* take the distinction into account -- they simply will
take your intentions into account, together with your actions, together
with their assessment of standard practice in the field (which almost
universally prefers pseudo-code and natural language descriptions of
algorithms). In the case of Bernstein, it's rather apparent that he
is attempting to communicate a new algorithm, with the code specifically
an appendix to the algorithm itself. In the case of a hypothetical
idiot who simply writes inscrutable code and claims that it's a
communication, the legal aspects aren't nearly as apparent.
-kitten
------------------------------
Date: Wed, 22 Sep 1999 17:05:41 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: frequency of prime numbers?
Patrick Juola wrote:
> In article <[EMAIL PROTECTED]>,
> Donald Welsh <[EMAIL PROTECTED]> wrote:
> >On Fri, 06 Aug 1999 17:27:45 GMT, Bob Silverman <[EMAIL PROTECTED]> wrote:
> >
> >>No. What Goedel showed was that any sufficiently rich axiomatic
> >>system is incomplete in the sense that there are true statements
> >>which can not be proved. [as well as other stuff I won't discuss].
> >>Peano arithmetic is "sufficiently rich", BTW.
> >
> >I'd like to correct this misconception, if I may. Godel's theorem
> >does not say that "there are true statements that cannot be proved".
> >It says that there are unprovable statements. These statements are
> >neither true nor false.
>
> But at least some of the statements *are* either true or false; in
> particular, Godel's sentence is an equation which either does or
> does not have a solution -- which is a property of the mathematics
> and not of the representation. So the Godel "sentence" *is*
> actually either true or false within a given model -- but we'll
> never know which.
This is like saying particles actually have both a precise position and
momentum, but we are unable to know them. Now in physics we can show
experimentally, that that is not the case. Is there a proof that there
cannot be a mathematical analogue for the double slit experiment? The
effect of a self referential contradiction certainly feels like the truth
state interfering with the false state.
------------------------------
Reply-To: "karl malbrain" <[EMAIL PROTECTED]>
From: "karl malbrain" <[EMAIL PROTECTED]>
Subject: Re: (US) Administration Updates Encryption Export Policy
Date: Wed, 22 Sep 1999 14:05:12 -0700
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> (...) C source code, reasonably commented, is
> a good way to document a *particular* implementation of some
> ideas, but it has practically no power to express abstractions.
I think you mean that C source without DOCUMENTED METHODS has no power.
Symbolic arrays, i.e. structures, contain all the ABSTRACTION you need.
> And working code has to deal with lots of details that are really
> irrelevant to understanding the idea of an algorithm, which is
> why "pseudo-code" is often used for such descriptions.
This is complete NONSENSE. Details are PROPERTIES, get it?????
E.g.
> if no more input
> sort input data
> find median of input data
> for each input data item
> if value < median/2 or value > 3*median/2
> output item
Yes, HONEYWELL did implement such a language before COBOL, but then again,
I'm only 49 years old and that's before my time. Karl M
------------------------------
From: [EMAIL PROTECTED] (jerome)
Subject: Re: Okay "experts," how do you do it?
Date: 22 Sep 1999 21:08:17 GMT
Reply-To: [EMAIL PROTECTED]
On Sat, 18 Sep 1999 22:19:25 -0700, Sundial Services wrote:
>
>Is it simply an issue that we don't have an effective way to represent
>the cipher in a way that the computer can be made to test it? I
>question this, because nearly all ciphers these days are computer
>functions. The computer does the encipherment; why can't the computer
>readily test the quality of the encipherment? If humans alone can do
>this testing then... "why? why? why??"
>
a human has different caracteristique than a computer.
example: you talk to a 5years old child. it will probably understand
the words even if he has never heard your voice before.
currently nobody do that wiht a computer.
------------------------------
** 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
******************************
