Cryptography-Digest Digest #28, Volume #13 Sat, 28 Oct 00 17:13:00 EDT
Contents:
Re: Rings of prime order (Was: Q: Computations in a Galois Field) ("Peter L.
Montgomery")
Re: Psuedo-random number generator ("slak-")
Re: how i decode this?? ("slak-")
DMCA bans fair use (Roger Schlafly)
Re: ciphertext smaller than blocksize (Benjamin Goldberg)
Re: Q: Computations in a Galois Field (Benjamin Goldberg)
Re: Q: Computations in a Galois Field (Benjamin Goldberg)
Re: Psuedo-random number generator (David Schwartz)
Re: Hardware RNGs (David Schwartz)
Re: ciphertext smaller than blocksize (SCOTT19U.ZIP_GUY)
Re: Is OPT the only encryption system that can be proved secure? (Richard Heathfield)
Re: ring homomorphic signature and encryption (David Wagner)
Re: Psuedo-random number generator (Eric Lee Green)
Re: Psuedo-random number generator (Eric Lee Green)
Re: Is OPT the only encryption system that can be proved secure? (SCOTT19U.ZIP_GUY)
Re: Psuedo-random number generator (Eric Lee Green)
Re: Psuedo-random number generator (Terry Ritter)
----------------------------------------------------------------------------
From: "Peter L. Montgomery" <[EMAIL PROTECTED]>
Subject: Re: Rings of prime order (Was: Q: Computations in a Galois Field)
Date: Sat, 28 Oct 2000 18:27:13 GMT
In article <8tb8u9$is$[EMAIL PROTECTED]>
"kihdip" <[EMAIL PROTECTED]> writes:
>> If anybody has problems with or suggestions for any of these or any
>> other topics, please let me know.
>
>I looked into your glossary and just wondered about one thing:
>
>Field:
>In abstract algebra, a commutative ring in which all non-zero elements have
>a multiplicative inverse. (This means we can divide.)
>- If the order of a ring is a prime, would it always be a field ??
If your definition of ring requires a multiplicative identity, then
all rings of prime order are fields. If not, there are counterexamples.
Let p be a prime. If no identity is required, the integers
divisble by p form a ring using arithmetic modulo p^2.
All products are zero. You get the same ring from the 2 x 2 matrices
( 0 x )
( 0 0 )
with arithmetic modulo p.
Now suppose R is a (not necessarily commutative)
ring of prime order p with multiplicative identity e.
I'll assume this is a right identity -- the left identity case is similar.
It is easy to show e <> 0 -- if e = 0 then
x = x * e = x * 0 = x * (e - e) = x * e - x * e = 0
for all x in the ring, so the ring would have only one element.
The additive group <e> generated by e has order
greater than 1, but this order divides p -- hence its order is p.
In particular, every element x in R has the form n(x) * e
for some integer n(x). If x, y in R, then
x * y = (n(x) * e) * (n(y) * e) = (n(x) * n(y)) * e
= (n(y) * n(x)) * e = y * x
so multiplication is commutative.
Furthermore, if x <> 0, then n(x) <> 0 (mod p).
We can find n' with n' * n(x) == 1 (mod p).
Then y = n' * e is a multiplicative inverse of x.
--
E = m c^2. Einstein = Man of the Century. Why the squaring?
[EMAIL PROTECTED] Home: San Rafael, California
Microsoft Research and CWI
------------------------------
From: "slak-" <[EMAIL PROTECTED]>
Subject: Re: Psuedo-random number generator
Date: Sat, 28 Oct 2000 12:01:02 -0700
exactly, everything is bound by mathematics and phsyics. If the sun were
random it would not be in the form is it now. However, we have no way of
predicting what the sun will do, or any other solar objects that generate
high radio waves and so it's nearly as random as we'll get.
Tom St Denis <[EMAIL PROTECTED]> wrote in message
news:8tej7q$j0j$[EMAIL PROTECTED]...
> In article <8tecqo$bjr$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Paul Schlyter) wrote:
> > In article <E4yK5.3$[EMAIL PROTECTED]>,
> > Nick Field <[EMAIL PROTECTED]> wrote:
> > >Hi All,
> > > why go to all this trouble when standard itterative formulae can
> > > generate absolutely random numbers.
> >
> > Because such formulae cannot generate "absolutely random numbers". NO
> > formula can do that -- you'll need some external unpredictable event
> > (such as radiactive decay of atoms, or noise from some hardware noise
> > source) to get anywhere near "absolutely random numbers".
>
> I would argue that even real life events are not totally random. The
> decay of an atom is not predictable because we can't properly observe
> it. Simple as that.
>
> Tom
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: "slak-" <[EMAIL PROTECTED]>
Subject: Re: how i decode this??
Date: Sat, 28 Oct 2000 12:10:44 -0700
idiot, stop posting garbage.
Eduardo Hernandez <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> how i decode or decrypt this kind of messages???
>
> eg.
>
> MQ'(E<H8.=8"AKS*7C$$KTGXXF_-D:M+&![;'PY61C0<B$-?E1B.^XKPMT,:T
> MI38V9-JN7+H/[C2^9*R1&X`4;HUTLE$7D4D].B7JPZMTA2Z?;U9,^N$C8_C8
> ME?!/K?>7ZBM]H\OAPIPI+OR<S>::]>K<ESP$9RULS>)*[[@DAV:#LU\;+:'C
> MQH#&RZW06I'F7I^>QHD[!(_\_?DPX%&I`Y@NV9MZ!\%JD)8#%&YML5L>VG[6
> MCL^M[2!5+;[U\[?&[R%KO^T/&=V9,OV6-VI7G`K-Z&<-,.6_$VJZ&[#XE"6`
> M`:G/;Q3+T]+K8Q3^+KYQGEU-.2@A\IM6_E9Y)+&G!QO<];U:5P4/OC,E$TU]
> M`*@:H4DZVY?`B!&5%^OL_'O039X;>T[&K/U^7;E"&QPS$[.8R:[R:NI&)>/>
>
>
>
>
>
>
>
>
>
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: DMCA bans fair use
Date: Sat, 28 Oct 2000 12:16:18 -0700
The Digital Millennium Copyright Act (DMCA) is a US law that
attempts to ban fair use of copyrighted materials if it involves
the circumvention of snake-oil crypto. This is the law that banned
links to DeCSS, the DVD circumvention code. The criminal aspect
of the law is about to kick in, with the Copyright Office
authorized to list some exemptions. There was some hope that there
would be a number of exemptions, such as crypto research.
The Copyright Office just declared that only two classes
of works are exempted from prohibition against circumvention.
They are:
(1) Compilations consisting of lists of websites blocked by
filtering software applications; and
(2) Literary works, including computer programs and databases,
protected by access control mechanisms that fail to permit access
because of malfunction, damage or obsoleteness.
For full details, see:
http://www.loc.gov/copyright/1201/anticirc.html
(Please restrict political follow-ups to talk.politics.crypto.)
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: ciphertext smaller than blocksize
Date: Sat, 28 Oct 2000 19:54:22 GMT
Marc wrote:
>
> >Do look up "ciphertext stealing". It's even in the section
> >"Terminating Block Cipher Use" on my page
>
> Ciphertext stealing is a nice method for keeping the ciphertext
> size identical to plaintext size, when the plaintext is larger
> or equal to the blocksize of the algorithm.
>
> Does anyone know a similarily clever method for handling plaintexts
> *smaller* than the blocksize? The only that comes to my mind is
> to pad the plaintext with zeros, encrypt it, and crop it to the
> plaintext size. Then the ciphertext can be built by XOR with
> the plaintext.
>
> This method will make the ciphertext unreadable, but not near as
> secure as the real thing. The attacker can flip bits at will.
>
> Are there any other ideas?
Use either OFB (output feedback mode) or CFB (cipher feedback mode).
The problem with these, is if you're not using an IV, there are
weaknesses. Assume for a moment that we always use an IV of 0. With
OFB, it's simply a stream cipher; the attacker can take two ciphertexts,
XOR them, and get the XOR of the plaintexts. With CFB, it's less weak,
but if the first N bytes of two plaintexts are identical, then the first
N bytes of the ciphertexts will be identical. Also, the XOR of the
first byte of two ciphertexts is the XOR of the first byte of the two
plaintexts (not alot of info there, but who wants *any* data to leak?).
If the length of the IV plus the length of the message is >= blocksize,
you can do ciphertext stealing. With a shorter IV, or no IV, I would
advise either using CFB mode, or better yet, a block cipher with
user-specifyable blocksize, like the hasty pudding cipher, or lja1.
If you're using a variable-blocksize cipher, it's still a good idea to
have an IV (even a short one), if possible. To encrypt or decrypt, pad
the IV if necessary to get it at least as long as the message, encrypt
it, XOR it with the message, and encrypt the result.
--
"Mulder, do you remember when I was missing -- that time that you
*still* insist I was being held aboard a UFO?"
"How could I forget?"
"Well, I'm beginning to wonder if maybe I wouldn't have been
better off staying abo-- I mean, wherever it was that I was
being held." [from an untitled spamfic by [EMAIL PROTECTED]]
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Q: Computations in a Galois Field
Date: Sat, 28 Oct 2000 19:54:32 GMT
Bob Silverman wrote:
>
> In article <8t9t5f$tf2$[EMAIL PROTECTED]>,
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> >
> > No polynomial is "better" then another. There are about 25
> > polynomials of nine bits (8-bit fields).
> >
> > I suggest you read the Rijndael paper about manipulating the
> > elements. If you have any specific questions please ask.
>
> Yes. Please ask. But don't ask Tom.
>
> Once again Tom finds it necessary to make assertions based upon his
> ignorance. Do us all a favor, Tom, and stop misleading others.
>
> Some polynomials most certainly ARE better than others. In particular
> a finite field is isomorphic to the quotient ring Z_p[x]/(g(X))
> where p is the field characteristic and (g(x)) is an ideal generated
> by a primitive polynomial. This is the polynomial you are looking
> for. It is much faster to choose a polynomial of low Hamming weight
> when choosing g(x) as this can make the arithmetic quite a bit
> faster.
Although it's true that some polynomials are faster than others, that
does not necessarily make them better -- especially since, in most
cases, the polynomial is only used to create some global variables, or
in the key setup (to make tables of some kind). Suppose that Rijndael
used a different poly than 0x11B. After all the long term tables are
created (which may be done before the main compile, and stuck into an
include file), how much speed difference is there because of the
different poly? Unless I'm mistaken, 0. How much security difference?
Well, assuming that you used the same criteria of irreducability and
primitiveness, 0 difference in security, also. Suppose Tom Denis's TC6
cipher used a different non-sparse irreducible poly? It would make the
key setup a bit faster or slower, but wouldn't change encryption speed,
nor security.
--
"Mulder, do you remember when I was missing -- that time that you
*still* insist I was being held aboard a UFO?"
"How could I forget?"
"Well, I'm beginning to wonder if maybe I wouldn't have been
better off staying abo-- I mean, wherever it was that I was
being held." [from an untitled spamfic by [EMAIL PROTECTED]]
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Q: Computations in a Galois Field
Date: Sat, 28 Oct 2000 19:54:34 GMT
Brian McKeever wrote:
>
> "kihdip" <[EMAIL PROTECTED]> wrote in message
> news:8tb8u9$is$[EMAIL PROTECTED]...
> > I looked into your glossary and just wondered about one thing:
> >
> > Field:
> > In abstract algebra, a commutative ring in which all non-zero
> > elements have a multiplicative inverse. (This means we can divide.)
> >
> > - If the order of a ring is a prime, would it always be a field ??
>
> No. It is easy to come up with examples of rings where some elements
> lack inverses.
Could you give us an example of a non-invertable element in a ring with
prime order?
--
"Mulder, do you remember when I was missing -- that time that you
*still* insist I was being held aboard a UFO?"
"How could I forget?"
"Well, I'm beginning to wonder if maybe I wouldn't have been
better off staying abo-- I mean, wherever it was that I was
being held." [from an untitled spamfic by [EMAIL PROTECTED]]
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Psuedo-random number generator
Date: Sat, 28 Oct 2000 12:52:06 -0700
Herman Rubin wrote:
>
> In article <E4yK5.3$[EMAIL PROTECTED]>,
> Nick Field <[EMAIL PROTECTED]> wrote:
> >Hi All,
> > why go to all this trouble when standard itterative formulae can
> >generate absolutely random numbers.
>
> There is NO way that ANY computer program can generate
> "absolutely random numbers". They will fail the test
> that they are generated by the formula; random numbers
> have the property that no rule not observing the actual
> numbers after some point does better than chance at
> predicting anything after that point. Computing is not
> the same as observing.
This may be true for some theoretical definition of computer, but it is
certainly not true for real computers. As a trivial counterexample,
remember that all computers are subject to quantum effects and have
small but finite probabilities of making unpredictable errors. For a
more realistic counterexample, consider true quantum randomness in the
offsets between the CPU oscillator and the clock oscillator on a network
card. This can be measured in software.
DS
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Hardware RNGs
Date: Sat, 28 Oct 2000 12:56:48 -0700
zapzing wrote:
> Indeed. I didn't bother to do the
> math, I just thought of it this way:
> if an eight dbit byte has exactly one
> "1" and seven "0"s , then it would take
> three bits to describe the position of
> the "1". As a matter of fact, this could
> yield an improvenet in the Von Neumann
> compensator, by examining eight bits at
> a time instead of two. You would only have
> to throw out the cases where you got
> eight "1"s or eight "0"s. Cases with
> exactly one "1" or "0" would yield
> three bits, but it gets a little more
> complex from there.
At first I didn't do the math either, but I reasoned as follows:
Each '1' clearly contains three bits of entropy because, since there's
only a one-in-eight chance of a '1', a perfect encoder could output
'000' every time a '1' came in if it wanted to. Thus one out of every
eight bits contains three bits of entropy. So you can get 160 bits of
entropy out of 426 bits of input. This ignores the entropy in the '0'
bits, which is much less anyway.
Interestingly, when you compute the entropy exactly, you do so by
computing the entropy of a '1' bit and the entropy of a '0' bit, then
multiplying each entropy value by its probability of occurring and
summing. This gives you the average entropy per input but.
For networked Pentium-class computers, however, the best source of
entropy I've found is grabbing least-significant bits of the TSC
(instruction cycle counter) every time you receive a packet over the
network. This exploits entropy in the offset between the network card's
oscillator and the motherboard's processor multiplier PLL.
DS
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: ciphertext smaller than blocksize
Date: 28 Oct 2000 20:02:59 GMT
[EMAIL PROTECTED] (Benjamin Goldberg) wrote in
<[EMAIL PROTECTED]>:
>Marc wrote:
>>
>> >Do look up "ciphertext stealing". It's even in the section
>> >"Terminating Block Cipher Use" on my page
>>
>> Ciphertext stealing is a nice method for keeping the ciphertext
>> size identical to plaintext size, when the plaintext is larger
>> or equal to the blocksize of the algorithm.
>>
>> Does anyone know a similarily clever method for handling plaintexts
>> *smaller* than the blocksize? The only that comes to my mind is
>> to pad the plaintext with zeros, encrypt it, and crop it to the
>> plaintext size. Then the ciphertext can be built by XOR with
>> the plaintext.
>>
>> This method will make the ciphertext unreadable, but not near as
>> secure as the real thing. The attacker can flip bits at will.
>>
>> Are there any other ideas?
>
>Use either OFB (output feedback mode) or CFB (cipher feedback mode).
>The problem with these, is if you're not using an IV, there are
>weaknesses. Assume for a moment that we always use an IV of 0. With
>OFB, it's simply a stream cipher; the attacker can take two ciphertexts,
>XOR them, and get the XOR of the plaintexts. With CFB, it's less weak,
>but if the first N bytes of two plaintexts are identical, then the first
>N bytes of the ciphertexts will be identical. Also, the XOR of the
>first byte of two ciphertexts is the XOR of the first byte of the two
>plaintexts (not alot of info there, but who wants *any* data to leak?).
>
Actually you can use standard CBC with optimal end handling
as in Matts Rijndael program. No problem check it out.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
Date: Sat, 28 Oct 2000 21:12:50 +0100
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: Is OPT the only encryption system that can be proved secure?
[various snippages]
"SCOTT19U.ZIP_GUY" wrote:
>
> [EMAIL PROTECTED] (Richard Heathfield) wrote in
> <[EMAIL PROTECTED]>:
>
> >"SCOTT19U.ZIP_GUY" wrote:
> >>
> >> but you have not shown that converting the whole program is protable.
> >
> >No, I haven't, but
[...]
> >
> >I have shown that it should now be relatively trivial to
> >write a portable version of your algorithm.
> >
>
> The point is its not done till the fat lady sings. What I mean
> the least 10% of doing anything in software take 90% of the time
> or have you heard that before.
Yes, I've heard that before, and I'm not trying to make light of the
workload involved in changing your program into something usable. All
I'm saying is that I have eased the process for you considerably. What
you do with the program is your business, and how long it takes you to
do it is your business too.
> >> I did have mnay macros that tested while on an individual
> >> basis but when I but them all together the complier went into never
> >> never land. I think some interal stack overflowed.
> >
> >Or it could have been undefined behaviour because of your use of void
> >main(). Strictly speaking, you can't be sure that it wasn't.
>
> I have seen comments affect the running of code in old
> Fortan compliers.
C compilers never even /see/ comments, because they're stripped out by
the preprocessor.
> Almost anything is possible, Mayve dropping void
> might make it fail. Who knows.
That's the marvellous thing about the ISO C Standard. If you write your
programs as ISO C conforming programs, you can be /sure/ of one of two
things:
a) your program will port correctly to another ISO C conforming
implementation, even on a completely different operating system, or
b) if it doesn't, you have a valid complaint against the compiler
vendor.
I've never had to resort to b).
> >> >No, don't do that. These functions belong in C files, not H files. They
> >> >are source code, not type definitions.
> >>
> >> THere are no rules about not having function in include files.
> >
> >No, you're right. In the same way, there's no rule about wearing your
> >underwear /underneath/ your jeans. But this is sci.crypt, not a language
> >newsgroup, so I won't press the point.
>
> You mean I won a point. I'm surprised.
Yes, you have won the right to do the C programming equivalent of
wearing your underwear over your jeans. Well done.
--
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: [EMAIL PROTECTED] (David Wagner)
Subject: Re: ring homomorphic signature and encryption
Date: 28 Oct 2000 20:21:50 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
John A. Malley wrote:
>I thought Z_p and Z_p^* ARE already homomorphic to each other when p is
>a prime.
No, they're not. You're probably getting confused about what the
group operation is; under traditional conventions, when you say
"the group Z_p" this is typically taken to refer to addition as
the group operation, whereas the group operation in Z_p^* is
multiplication.
(There _is_ a group homomorphism, in fact isomorphism, between
(Z_p^*,*) and (Z_{p-1},+), namely f : Z_p^* -> Z_{p-1} given by
f(x) = log x. However, you need to be able to compute the discrete
log in Z_p to compute f, so it is unlikely to be useful.)
And I suspect what David Molnar is asking for is a ring homomorphism
on Z_N, i.e., a map which is simultaneously a group homomorphism with
respect to both (Z_N,+) and (Z_N^*,*).
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Psuedo-random number generator
Date: Sat, 28 Oct 2000 13:39:40 -0700
slak- wrote:
> Would it not be feesable to use your sound blaster to scan a number of
> radio-frequencies and do a series of calculations based on the results to
> generate a seed?
This assumes that radio "noise" is random. It isn't necessarily so. In
addition, the Sound Blaster does not scan "radio frequencies". It detects
audio frequency noise, which is much lower frequency than "radio frequencies".
Inside a computer, such noise is usually inductive currents generated by the
60hz hum of the power supply (or slightly higher hum of its switching
components), and thus is not really "noise", it is actually quite predictable.
This is not to say that this hum is not useful. For example, the bit skew
between this hum and some other (non-power-supply-dependent) data source may
be useful as a source of entropy. But as a source in and of itself, it's
useless.
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer "The BRU Guys"
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Psuedo-random number generator
Date: Sat, 28 Oct 2000 13:42:59 -0700
Nick Field wrote:
> Hi All,
> why go to all this trouble when standard itterative formulae can
> generate absolutely random numbers.
Err, for cryptography, we're interested in UNPREDICTABLE numbers. Which by
definition do fit a random distribution curve, but iterative formulae are, by
nature, predictable, whether or not their output fits a random distribution
curve.
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer "The BRU Guys"
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Is OPT the only encryption system that can be proved secure?
Date: 28 Oct 2000 20:26:38 GMT
[EMAIL PROTECTED] (Richard Heathfield) wrote in
<[EMAIL PROTECTED]>:
>[various snippages]
>
>"SCOTT19U.ZIP_GUY" wrote:
>>
>> [EMAIL PROTECTED] (Richard Heathfield) wrote in
>> <[EMAIL PROTECTED]>:
>>
>> >"SCOTT19U.ZIP_GUY" wrote:
>> >>
>> >> but you have not shown that converting the whole program is
>> >> protable.
>> >
>> >No, I haven't, but
>
>[...]
>> >
>> >I have shown that it should now be relatively trivial to
>> >write a portable version of your algorithm.
>> >
>>
>> The point is its not done till the fat lady sings. What I mean
>> the least 10% of doing anything in software take 90% of the time
>> or have you heard that before.
>
>Yes, I've heard that before, and I'm not trying to make light of the
>workload involved in changing your program into something usable. All
>I'm saying is that I have eased the process for you considerably. What
>you do with the program is your business, and how long it takes you to
>do it is your business too.
Not necisarrily.
>
>> >> I did have mnay macros that tested while on an individual
>> >> basis but when I but them all together the complier went into never
>> >> never land. I think some interal stack overflowed.
>> >
>> >Or it could have been undefined behaviour because of your use of void
>> >main(). Strictly speaking, you can't be sure that it wasn't.
>>
>> I have seen comments affect the running of code in old
>> Fortan compliers.
>
>C compilers never even /see/ comments, because they're stripped out by
>the preprocessor.
Hopefully
>> Almost anything is possible, Mayve dropping void
>> might make it fail. Who knows.
>
>That's the marvellous thing about the ISO C Standard. If you write your
>programs as ISO C conforming programs, you can be /sure/ of one of two
>things:
>
>a) your program will port correctly to another ISO C conforming
>implementation, even on a completely different operating system, or
>b) if it doesn't, you have a valid complaint against the compiler
>vendor.
>
>I've never had to resort to b).
Why are the bug reporsts even in gcc errors are being found
and correct all the time.
>
>
>> >> >No, don't do that. These functions belong in C files, not H files.
>> >> >They are source code, not type definitions.
>> >>
>> >> THere are no rules about not having function in include files.
>> >
>> >No, you're right. In the same way, there's no rule about wearing your
>> >underwear /underneath/ your jeans. But this is sci.crypt, not a
>> >language newsgroup, so I won't press the point.
>>
>> You mean I won a point. I'm surprised.
>
>Yes, you have won the right to do the C programming equivalent of
>wearing your underwear over your jeans. Well done.
>
>
The problem is I seldom wear underwear. But I guess not wearing
it at all inside kind of counts the same as not wearing it outside.
SHall we let this threas die too. Or do you always have to have the
last word.
Surprise me don't reply to this thread anymore and I wont reply
to yours in this thread.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Psuedo-random number generator
Date: Sat, 28 Oct 2000 13:44:46 -0700
slak- wrote:
>
> exactly, everything is bound by mathematics and phsyics. If the sun were
> random it would not be in the form is it now. However, we have no way of
> predicting what the sun will do,
And for cryptography, that's what we're interested in -- unpredictability. If
an attacker can predict what values our "randomly-generated" keys will be,
there's no point in having keys.
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer "The BRU Guys"
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Psuedo-random number generator
Date: Sat, 28 Oct 2000 21:02:19 GMT
On Sat, 28 Oct 2000 12:52:06 -0700, in
<[EMAIL PROTECTED]>, in sci.crypt David Schwartz
<[EMAIL PROTECTED]> wrote:
>Herman Rubin wrote:
>>
>> In article <E4yK5.3$[EMAIL PROTECTED]>,
>> Nick Field <[EMAIL PROTECTED]> wrote:
>> >Hi All,
>> > why go to all this trouble when standard itterative formulae can
>> >generate absolutely random numbers.
>>
>> There is NO way that ANY computer program can generate
>> "absolutely random numbers". They will fail the test
>> that they are generated by the formula; random numbers
>> have the property that no rule not observing the actual
>> numbers after some point does better than chance at
>> predicting anything after that point. Computing is not
>> the same as observing.
>
> This may be true for some theoretical definition of computer, but it is
>certainly not true for real computers. As a trivial counterexample,
>remember that all computers are subject to quantum effects and have
>small but finite probabilities of making unpredictable errors. For a
>more realistic counterexample, consider true quantum randomness in the
>offsets between the CPU oscillator and the clock oscillator on a network
>card. This can be measured in software.
I deny that any software-detectable "true quantum randomness" exists
between crystal oscillators. Almost the only unpredictable thing
about crystal oscillators is their phase with respect to some absolute
reference after power-on. Subsequently, excepting minor and generally
predictable thermal drift effects, there is no phase change. That is
the whole point of having a crystal oscillator.
Asynchronous clock signals, especially of different frequency, may
produce a random-like interaction, but most of that is not random at
all, but is instead deterministic based on starting phase and
frequency, thus giving predictable results.
In general, crystal oscillators are one of the worst possible choices
for exposing quantum effects.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
** 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
******************************
