Cryptography-Digest Digest #672, Volume #9 Sun, 6 Jun 99 21:13:02 EDT
Contents:
Re: SCOTT19U pass in nut shell ("Matthew Bennett")
Re: Generating Large Primes in C++ (David A Molnar)
Re: Generating Large Primes in C++ (fungus)
Re: Challenge to SCOTT19U.ZIP_GUY (Tim Redburn)
Re: Papers on fields, and general number theory (David A Molnar)
Re: new algorithm (David A Molnar)
Re: "On cryptosystems untrustworthiness" paper ("Markku J. Saarelainen")
Re: Generating Random Numbers (Pierre Abbat)
Re: Challenge to SCOTT19U.ZIP_GUY (SCOTT19U.ZIP_GUY)
Re: Challenge to SCOTT19U.ZIP_GUY (Tim Redburn)
Re: random numbers in ml (Jim Butterfield)
Re: Generating Random Numbers ("Rochus Wessels")
Re: Key lengths vs cracking time ([EMAIL PROTECTED])
rc4 vs. rand() ("Particle")
----------------------------------------------------------------------------
From: "Matthew Bennett" <[EMAIL PROTECTED]>
Subject: Re: SCOTT19U pass in nut shell
Date: Sun, 6 Jun 1999 21:46:01 +0100
SCOTT19U.ZIP_GUY wrote in message <7jei15$1lvo$[EMAIL PROTECTED]>...
> Your correct of course the more serious reason would have been to say
>rectal retrieval. What difference does it make. Either it is hard to crack
or
>not. I am sure that if a lot of the AES candidtates gave an honest anwser
>for every little detail they would say something like that. My god no
wonder
>Clinton is president idots like you voted for him casue he talks nice. I
still
>want to see Jessie Ventura as president. But then stuff shirts like you
>couldn't handle the honesty.
I'm not quite so sure what the USA presidential elections have to do with
this, but posting such things as this does little to assure prospective
users of your credibility.
/\/\/\//
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Generating Large Primes in C++
Date: 6 Jun 1999 20:59:33 GMT
[EMAIL PROTECTED] wrote:
> Hi,
> I need to generate some large primes ( 512 bit and 1024 bit ) for use
> in ElGamal... I've used the search engines and found lots of classes
> for large number arithmetic. I was wondering if someone could save me
> some time and let me know if they have a favorite publically available
> C++ class for generating large prime numbers.
You may want to try Victor Shoup's Number Theory Library (NTL).
It advertises "small prime generation routines." Not clear to me
right now whether "small" refers to the primes or to the routines,
but may be worth a shot. The rest of the library is worth checking
out for its rather useful implementation of LLL and other fun
algorithms.
http://www.shoup.net/ntl/
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: Generating Large Primes in C++
Date: Sat, 05 Jun 1999 14:03:52 -0100
[EMAIL PROTECTED] wrote:
>
> Hi,
>
> I need to generate some large primes ( 512 bit and 1024 bit ) for use
> in ElGamal... I've used the search engines and found lots of classes
> for large number arithmetic. I was wondering if someone could save me
> some time and let me know if they have a favorite publically available
> C++ class for generating large prime numbers.
>
Most of these "large number" packages include classes for this.
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: [EMAIL PROTECTED] (Tim Redburn)
Subject: Re: Challenge to SCOTT19U.ZIP_GUY
Date: Sun, 06 Jun 1999 21:32:40 GMT
On Sun, 06 Jun 1999 20:32:11 GMT, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote:
<snip>
> Actually it isn't. It is just that most code I have looked at people
>increment it. But as I stated somewhere and as it will be in the new
>stuff I am about to put out there on the net.
New stuff !!!! We haven't analysed the existing stuff yet. Give
us a chance !!
>I put the file in virtual
>memory so there was little actual difference in the speed of encryption
>and decryption. But when the data stays in files code is usually set up
>to handle reading a file from the front to the back. But if one using data
>as read to decrypt one must use data fron the back to the front. Sorry
>if the concept is over your head. You ask for simple explanations and
>then you fall apart. So do you really want to understand the routine or
>thoughts behind it or what?
>
You keep posting comments that make us question our understanding
of your algorithm, and with no accurate reference we don't know what
to believe. So scot19u.zip is not slower at decrypting than encrypting
then ? But you just said in a previous post that it was !!
How are we supposed to understand your algorithm, when you keep making
contradictory statements about it ??
Do you actually understand your own algorithm ???
- Tim.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Papers on fields, and general number theory
Date: 6 Jun 1999 21:12:13 GMT
[EMAIL PROTECTED] wrote:
> If anyone has written anything related or knows about anything related
> to the topic at hand I would like to see it.
Maybe it would be worthwhile to look for oonline course notes ?
I'll have to look for this; unless people have particularly good
ones online ?
-David
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: new algorithm
Date: 6 Jun 1999 21:41:55 GMT
Thomas Pornin <[EMAIL PROTECTED]> wrote:
> According to A. N. Alias <[EMAIL PROTECTED]>:
>> The news stated that she may be submitting the result to Crypto '99,
>> but I don't see any mention of it on the list of accepted papers at
>> www.iacr.org. Does anyone know what happened?
> She still has the possibility to make a show at the rump session. Quite
> realistic if it is just a speedup in computation, with no proof of
> security or other high-level stuff. We'll see anyway.
Is there any way to find out if she's submitted before the
deadline for the rump session submissions ?
-David
------------------------------
From: "Markku J. Saarelainen" <[EMAIL PROTECTED]>
Subject: Re: "On cryptosystems untrustworthiness" paper
Date: Sun, 06 Jun 1999 17:32:05 -0700
I would also add another major reason for poor crypto systems. The design,
development and implementation of cryptographic and encryption systems are
often limited to algorithms and not enough attention is paid to the whole
cryptographic system and/or process. In fact, an organization should take a
very strategic approach when specific crypto systems and process are being
designed and developed. And each system has (at least) those 4 Ms: machines
(hardware, software other office equipment such as shredder), material
(plaintext / ciphertext / printouts etc.), manpower (people) and methods
(cryptographic algorithms and extensions etc.).
Cheers !
Pavel Semjanov wrote:
> Hello!
>
> Maybe my paper will be interested to someone...
>
> Abstract:
>
> The reasons of cryptosystems untrustworthiness can be divided into 4
> main groups: application of weak algorithms, cryptalgorithms wrong
> implementation or application and human factor. There is clear parallel
> between these reasons and computer system security violation ones.
>
> Because of pointed reasons there were and still there are security
> problems in all kinds of software, where cryptalgorithms are used, be it
> operating systems; cryptographic protocols; clients and servers
> supporting them; office programs; user encryption utilities or popular
> archivers.
>
> To proper implement your own cryptosystem you should not only learn
> somebody's mistakes and understand the reasons of their occurrence, but
> perhaps use sophisticated protection programming approaches and special
> design tools.
>
> http://www.ssl.stu.neva.ru/psw/publications/crypto_eng.html
>
> --
>
> SY / C4acT/\uBo Pavel Semjanov
> _ _ _ http://www.ssl.stu.neva.ru/psw/
> | | |-| |_|_| |-| 2:5030/145.17@fidonet
------------------------------
From: Pierre Abbat <[EMAIL PROTECTED]>
Subject: Re: Generating Random Numbers
Date: Sun, 6 Jun 1999 18:35:59 -0400
On Thu, 03 Jun 1999, Brian Hetrick wrote:
>Umm, if you read the chip, as opposed to the BIOS interrupt count, the
>period is about 0.8 microseconds. Of course, Windows NT and 9x slap
>your hand if you try to read the chip....
In Windows there is a call QueryPerformanceCounter which reads the chip. But if
you really want randomness, read /dev/random on your Linux box.
phma
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Challenge to SCOTT19U.ZIP_GUY
Date: Sun, 06 Jun 1999 22:49:39 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tim
Redburn) wrote:
>On Sun, 06 Jun 1999 15:07:42 GMT, [EMAIL PROTECTED] wrote:
>
>><snip>
>>
>>Look at : http://members.xoom.com/ecil/page2.htm
>>
>>Which briefly describes the algorithm.
>>
><snip>
>
>I originally looked at those pages some time
>ago, in fact they were what I based my
>analysis of his S-Box generation on.
>
Yes and Horst did a job good enough that
allowed you to do the entropy calculations for
the key selection based on a random keyenc.key
file.
>However, as I showed, the sums in the pages
>are inaccurate, but David refuses to correct them.
I have not refused to correct anything. And I thought
with Horst's backing I changed the numbers in question
so don't say I refused becasue that is not true. What numbers
do you know say are not changed. Becasuse the intent
was to make Horst me and you happy.
>Anyone else reading the pages is likely to duplicate
>work that has already been done by others, without
>actually realising it (I wasn't the first to point
>out problems with Davids S-Box generation).
Again I do say that you pointed out the entropy of using
a file random file leads to slightly less than what is done
with a purely random selection. As far as the key generation
I thought Terry Ritter was the first to notice that since most
users not real sharp I should have done a different job of building
a table from pass pharse. At the time I said the key is so large
and that since "all possible S-Tables are able to be generated"
that I felt it made no difference except that users trying to follow
the key building would focus on that area instead of the
encryption. Again the only thing you pointed at was the entropy
value of a full key using a random key file which still gives more
than a million bytes of "real entropy" I am not even sure that
you realizes ever possible singe cycle S table can be used
with my program.
>
>
>When commenting about the accuracy of those
>pages, all David is prepared to say is that he
>would have written them differently.
>
>He refuses to give a concrete yes or no as to whether
>they give a completely accurate description of his
>algorithm.
>
Well as Clinton would say it depends on the definations
but the Pages are there and the source code toghter give a
completely accurate description.
>Until David corrects the parts that have been pointed
>out to him as incorrect, AND until he confirms absolutely the
>accuracy of the rest of the document, I am not going
>to spend time analysing it further, and I wouldn't
>recommend any one else does either.
>
Yes it is to hard for you so lets not have others show
you up by analyzing what you couldn't. Even though
you have the total source code.
>Without absolute confirmation from David as to the documents
>accuracy, if you do perform any analysis of it, and actually
>find a weakness, it is highly probable that David will turn
>round and claim that it wasn't actually done that way in
>his program.
>
He has a point the description is a guide but the code is the
source. As an example look at figure 2 in Horsts area I lay the
code out from begining to end. Yes at the front C0 is shown partly
in the file area and partly out this is true. But at the back I show
a Pn and I draw the line for end of file through that block. While
that is the general case. But for various file lengths 1 in 19 the EOF
ends at the end of the 19 bit block. One should only expect the general
case and not every possilbe ending. LIke wise I use a Cm for last
C block in the file since M and N not necessiarly the same value
this is reflect in the code by the use of iz and izz that confused
Redburn
>The guy that wrote that description had the same problems
>as the rest of us, in that he had to try to derive the algorithm
>from the source code. If you've looked at the source code,
>you will see that it's not the easiest to follow C source ever
>written, and that guy, in another post on another thread, has
>also requested that David give an absolute statement as
>to the documents accuracy.
>
>If David is prepared to correct the parts that have been demonstrated
>as incorrect, AND he makes an *absolute* statement as to the rest of
>the documents accuracy, (in other words he *must* be prepared to stand
>by such a statement, so he actually will need to check the document in
>detail first), then he will have sucessfully completed the challenge.
>
Well Tim even the IRS doesn't stand by there abreviated code books
of taxation. They can't get it totally right. And there is no why I would say
something is absoulte 100% accuatte in English sense I think I do not
have a strong command of what the hell words really mean. But the source
code is something one can get a handle on. I am sorry if you can't use the
source code to figure it out. But you must not do much maintance coding
if you are under the illusion that documents descripping the source code
of any large program are guaranteed to be absolutely corrent. Hell when I
porgramed various military computers it was impossible to find documentation
on the computers that was correct. Oh I am sure the spelling was correct but
the documents where incomplete and wrong you had to play with the dam
machines to find out what insturction really did. Your luck GNU C is so well
documented you should be able to figure it out.
>- Tim.
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] (Tim Redburn)
Subject: Re: Challenge to SCOTT19U.ZIP_GUY
Date: Sun, 06 Jun 1999 22:41:32 GMT
On Sun, 06 Jun 1999 22:49:39 GMT, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote:
<snip>
> I have not refused to correct anything. And I thought
>with Horst's backing I changed the numbers in question
>so don't say I refused becasue that is not true. What numbers
>do you know say are not changed. Becasuse the intent
>was to make Horst me and you happy.
>
<snip>
When I pointed out that the numbers were incorrect
you said you didn't want to change them because
horst had put so much effort into the document.
I checked the document in the weeks after the errors
were pointed out, and it hadn't changed.
I gave up looking at the document because you
expressed an intention not to change it at the
time. Granted that was several months
ago it and it may have been changed since.
Because at the time you expressed a desire
not to change it, I didn't bother looking
again after a few weeks - there didn't seem
to be much point.
Are you now prepared to categorically state that
that document is a totally accurate representation
of your algorithm, and any weakness found from
an analysis based on that document, will be weaknesses
in your algorithm ?
So we can all go ahead and read and analyse it ?
-Tim.
------------------------------
Crossposted-To: comp.sys.cbm
From: [EMAIL PROTECTED] (Jim Butterfield)
Subject: Re: random numbers in ml
Date: Sun, 6 Jun 1999 22:23:57 GMT
: > Unless we exhaustively analyze the entire set of
: > readers of sci.crypt, how are we to conclude that 'C' is the preferred
: > language for talking about random number generators?
It might be the most widely understood algorithmic language at the
present time, but I suspect that this is not a hard-and-fast rule.
The original question seems to have been posted in comp.sys.cbm, and
still carries the words ".. in ml" in its title; so that the supplying of
specific 6502 code would seem to be quite appropriate. Over the time
that this subject has been active (on and off, a few months), comparable
code has also been contributed in (Commodore/Microssoft) Basic, with
adjustments offered to reflect the limitations of the 8-bit registers and
the effects of the Carry flag. Although there is no consensus as to what
constitute an excellent algorithm for generating random numbers in this
environment, there has been good discussion where most participants seem
to understand what's going on.
The ancient algorithm I tried to recollect came from a publication of the
ACM back around 1964. At that time, the ACM had standardized on Algol as
the language in which all algorithms would be quoted. I don't see heavy
use of Algol at the present time, but I suspect that most readers with
programming background would be able to pick through the code and see the
methodology involved.
Seems to me that the important thing is still the grasping of the concept
rather than the quoting of the code.
--Jim
------------------------------
From: "Rochus Wessels" <[EMAIL PROTECTED]>
Crossposted-To: news.groups,at.test,alt.gothic,sci.math
Subject: Re: Generating Random Numbers
Date: 01 Jun 1999 13:19:32 +0200
"Rochus Wessels" <[EMAIL PROTECTED]> writes:
<crypted looking message deleted, doesn't look
monoalphabetic because of "qq">
I didn't write this message.
And it deleted my original answer, which
were two useful references:
http://www.counterpane.com/yarrow.html
http://www.cs.berkeley.edu/~daw/rnd/
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Key lengths vs cracking time
Date: Sun, 06 Jun 1999 23:08:30 GMT
> Does anyone has some information relating to encryption algorithms
and key
> length in relation to the time needed to break the encrypted data?
Apples and oranges my friend. A 'break' is defined as anything faster
then brute force, by means such as chosen-plaintext or known plaintext
or chosen-difference. If searching the entire key is the fastest way
then the key size becomes important.
Tom
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "Particle" <[EMAIL PROTECTED]>
Subject: rc4 vs. rand()
Date: Sun, 6 Jun 1999 20:53:47 -0400
I've implemented the RC4 algo, and would like
to know what are it's advantages over plain rand()
method... for example: in rc4 way I got:
rc4init(key); // initializes the 8x8 box using key
while((ch = fgetc(in)) != EOF)
fputc((ch ^ rc4()) & 0xFF,out);
// rc4() returns the next subsequent number
how would this be different from say:
srand(key); // init random number gen
while((ch = fgetc(in)) != EOF)
fputc((ch ^ rand()) & 0xFF,out);
of course, without using the default rand() but some other
*good* random number generator...
wouldn't a random number generator make more sense since
most good ones have been statistically analyzed, and generate
statistically good random numbers, etc... ?
--
Particle
[EMAIL PROTECTED]
http://www.geocities.com/SiliconValley/Way/7650
Home of the Java Data Structures 2nd Edition.
------------------------------
** 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
******************************
