Cryptography-Digest Digest #878, Volume #8 Sun, 10 Jan 99 20:13:04 EST
Contents:
Key-Active Encryption (daAvatar)
Re: Practical True Random Number Generator (daAvatar)
Re: Practical True Random Number Generator (Jim Dunnett)
Re: What is left to invent? (David A Molnar)
Re: What is left to invent? (R. Knauer)
Re: Chosen-Signature Steganography (Bill Stewart)
Re: SCOTT19U ENTROPY (Tim Redburn)
Re: RSA source code? (Bill Stewart)
Re: RSA source code? (Bill Stewart)
ANNOUNCE: Bay Area Cypherpunks Meeting, Jan.16th 1999, San Jose (Bill Stewart)
Re: On the Generation of Pseudo-OTP (R. Knauer)
Re: SCOTT19U ENTROPY ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: daAvatar <[EMAIL PROTECTED]>
Subject: Key-Active Encryption
Date: Sun, 10 Jan 1999 15:12:21 -0500
Reply-To: [EMAIL PROTECTED]
Hi,
I thought of an key-active encryption method (in no point related with
microsoft active-stuff). This is simple : The key is not only the key
but some kind of interpreted code which will encode the data. Of course,
you can add a layer of secure encryption before and after the key-active
encryption to provide more security.
BlowFish(k1,KAE(k2,BlowFish(k3)))
I would like to have some comments on this.
dA
------------------------------
From: daAvatar <[EMAIL PROTECTED]>
Subject: Re: Practical True Random Number Generator
Date: Sun, 10 Jan 1999 14:40:47 -0500
Reply-To: [EMAIL PROTECTED]
"Trevor Jackson, III" wrote:
> hapticz wrote:
>
> > or point it at a
> > body of water
> > sampled over periods of extended lengths to build a composite database.
>
> Err, waves are BY DEFINITION periodic phenomena.
Humm well, imagine a closed room with a cooled ceiling and an heated floor and
some water on it. Condensation of the water on the ceiling will create small
water drops which will create different waves in the water which is on the
floor. I guess that the waves will be random. You could after a certain amount
of time, rotate the room on one axis to change the heated / cooled side.
Another random generator could be based on quantum theory, by reading the
state of a photon a several amount of time. Of course, when we'll discover how
to predict the after-reading state of a photon this will not be random
anymore.
I guess that every random number isn't really random, since everything in the
world can be calculated or predicted (chaos theory). Almost-perfect random
numbers are generated by systems with a lot of factors and a low rate of
collisions between those factors. Real random numbers are only theorical.
dA
------------------------------
From: [EMAIL PROTECTED] (Jim Dunnett)
Subject: Re: Practical True Random Number Generator
Date: Sun, 10 Jan 1999 20:30:57 GMT
Reply-To: Jim Dunnett
On Sat, 09 Jan 1999 20:15:36 GMT, [EMAIL PROTECTED] (R. Knauer) wrote:
>On Sat, 09 Jan 1999 09:03:44 -0800, Anthony Stephen Szopa
><[EMAIL PROTECTED]> wrote:
>
>>Practical True Random Number Generator
>>
>>I think I have just come up with a practical device to generate true
>>random numbers.
>
>Why go to all that trouble when you could sample the noise from an
>open input on 20 buck sound card?
>
>Also, keep in mind that any electronics is very susceptible to ambient
>electromagnetic pickup such as 50-60 Hz line current.
Another useful one is a VHF radio switched to FM
with a screened dummy antenna and the squelch open.
Use the random noise to produce a digital stream.
--
Regards, Jim. | MPs, ministers or otherwise do not resign
olympus%jimdee.prestel.co.uk | because of their integrity. They do so
dynastic%cwcom.net | because they have been found out.
nordland%aol.com |
marula%zdnetmail.com | - A letter in the Daily Torygraph.
Pgp key: wwwkeys.uk.pgp.net:11371
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: What is left to invent?
Date: 10 Jan 1999 23:37:25 GMT
R. Knauer <[EMAIL PROTECTED]> wrote:
[very nice explanation of random oracles]
> Is there anything written on this subject, on the Web possibly? I
> can't seem to find anything in Schneier's main book about it.
I'm not that surprised - I think random oracles are of comparatively
recent invention, and motivated by the need to provide some kind of
security model with practical results for crypto algorithms. at least, I
hadn't heard of it until middle of last year (though that proves
_less than nothing_!)
OK - short web search reveals Mihir Bellare and Phillip Rogaway as
possible suspects, with
"Random oracles are practical : a paradigm for desigining efficient
protocols" in Proceedings of First Annual Conf on Computer and
Communications Security, ACM, 1993
as an interesting-looking read. Both of them seem to have web pages, too.
and, elsewhere, a paper I really wish I could get right about now :
from http://www.nada.kth.se/nada/theory/sciout89-.html
15. Chang, R., Chor, B., Goldreich, O., Hartmanis, J., H�stad, J.,
Ranjan, D., Rohatgi, P., The random oracle hypothesis is false, J.
Comput. System Sci. 49:1 (1994), 24-39.
I seem to remember stumbling across an overview article by Goldwasser(??)
on "The Random Oracle Paradigm", but can't find it now, sorry. :-\
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: What is left to invent?
Date: Mon, 11 Jan 1999 00:18:00 GMT
Reply-To: [EMAIL PROTECTED]
On 10 Jan 1999 23:37:25 GMT, David A Molnar <[EMAIL PROTECTED]>
wrote:
>I'm not that surprised - I think random oracles are of comparatively
>recent invention, and motivated by the need to provide some kind of
>security model with practical results for crypto algorithms. at least, I
>hadn't heard of it until middle of last year (though that proves
>_less than nothing_!)
>OK - short web search reveals Mihir Bellare and Phillip Rogaway as
>possible suspects, with
>
>"Random oracles are practical : a paradigm for desigining efficient
>protocols" in Proceedings of First Annual Conf on Computer and
>Communications Security, ACM, 1993
>
>as an interesting-looking read. Both of them seem to have web pages, too.
>
>and, elsewhere, a paper I really wish I could get right about now :
>
>from http://www.nada.kth.se/nada/theory/sciout89-.html
>
>15. Chang, R., Chor, B., Goldreich, O., Hartmanis, J., H�stad, J.,
>Ranjan, D., Rohatgi, P., The random oracle hypothesis is false, J.
> Comput. System Sci. 49:1 (1994), 24-39.
>
>I seem to remember stumbling across an overview article by Goldwasser(??)
>on "The Random Oracle Paradigm", but can't find it now, sorry. :-\
Keep us informed by all means.
Bob Knauer
"We hold that each man is the best judge of his own interest."
--John Adams
------------------------------
From: Bill Stewart <[EMAIL PROTECTED]>
Subject: Re: Chosen-Signature Steganography
Date: Sun, 10 Jan 1999 15:34:00 -0800
David A Molnar wrote:
> > The idea here was spotted by Gus Simmons while working on
> > equipment to verify the Strategic Arms Limitation Treaty (SALT).
> > He called this sort of steganography a "Subliminal Channel".
....
> I was wondering if anyone had thought of something useful to
> shove into 'em (software failure modes, anyone ?)
Unfortunately, there _is_ something very useful to shove in them.
One of the prime users of DSA is expected to be the government,
since they're the main group interested in promoting signature algorithms
which can't also be used for encryption, so as digital signatures evolve
for government/citizen interactions, such as Drivers' Licenses, Tax
Smartcards,
Heath-Care Consumers' Licenses (er, insurance cards), etc., they'll probably
use DSA.
This provides an opportunity to add subliminal data only visible to the
government,
e.g. your driver's license signature may indicate your political status as a
licensed firearm holder, or drug user, or gay, or Jewish, or a government
worker,
or your passport indicating you're a member of a political group interesting
to the FBI...
It's nothing they can't easily do in database lookups using your ID number,
especially as police cars become more wired, but it's portable and
potentially secret.
Lurking...
------------------------------
From: [EMAIL PROTECTED] (Tim Redburn)
Subject: Re: SCOTT19U ENTROPY
Date: Mon, 11 Jan 1999 00:34:43 GMT
On Sun, 10 Jan 1999 10:02:04 -1000, Horst Ossifrage
<[EMAIL PROTECTED]> wrote:
<snip>
>When I wrote David's documentation page I wrote the following description
>of the S-Box generation method for scott16u.zip which has a DECREASING
>MOD operation So The modulus starts at 2^16 and linearly decreases to mod
>1 :
>
>
>Here is how the S-Box is formed for scott16u.zip:
>
<snip>
I wasn't referring to scott16u. Because of David's statement that
he would not agree with what you wrote, I have since referred only
to the source code of scott19u.
I agree that the mod operation decreases. The formula I wrote
is for the entropy of a single mod operation. The code I wrote
uses this formula for the entropy of each entry and keeps a running
total of the entropy so far.
The code uses the mod operation in a decreasing order exactly the same
as scott19u.
>Step 1: Create a memory array of 64K words (FFFF words in hexadecimal
>terminology).
>Call this array List1[i]. These words will have addresses i from 0 to
>FFFF hex. The values
>initially stored in these locations are simply 0, 1, 2, 3, 4, 5, 6, 7, 8,
>9, a, b, c, d, e, f, 10, 11,
>12, ... etc. up to FFFF hex. Each of these values will be selected only
>once by the
>algorithm, and the value will be put in a location of the S-Box memory
>array that is chosen
>by Rules defined below. After a value from location i is put in the
>S-Box, location i is
>written with a new value, according to the Rules defined below.
>
>Step 2: Use the keyraw.key file with location pointed to by j. This
>keyraw.key file may have
>less than 64K words. Call each word key[j]. Start at location j=0 and use
>the value at that
>location according to the Rules defined below to make an entry in the
>S-Box. Then j will be
>incremented through the whole keyraw.key file, and j will wrap around as
>many times as
>needed to finish making the S-Box.
>
>Step 3: Set x=1. Take the key value at j=0, add 1 to it, mod ((2^16)-1-x)
>and put that
>number in S-Box location 0. Place key[j]+1 in List1[S-Box[j]].
>
>Step 4: Set x=2. Take the key value at j=1, add 1+j to it, mod
>((2^16)-1-x) , and place that
>value in S-Box[S-Box[j-1]]. Place key[j]+1 in List1[S-Box[j]].
>
>Step 5: Set x=3. Take the key value at j=2, add 1+j to it, mod
>((2^16)-1-x) , and place that
>value in S-Box[S-Box[j-1]]. Place key[j]+1 in List1[S-Box[j]].
>.
>.
>.
>Step Y: Increment x and j. Take key[j], add 1+j to it, mod ((2^16)-1-x),
>and place that value
>in S-Box[S-Box[j-1]]. Place key[j]+1 in List1[S-Box[j]].
>
Scott19u uses a different method .....................
//////////////////////////////<snip from the source code>
for (i = 0; i < T19L-2 ; i++) {
j = (un32)get19( prtb, i) % (T19L-i-1); // mod before +1+j
put19( j, prtb, i); /* just to make keyout.key a specail form
can be dropped */
k = get19( pw, i+j+1); // +1+j AFTER the mod operation.
:
: <snipped for clarity>
:
}
///////////////////////////////<snip from the source code>
>---------------------------------------------
>
>so you see the line where it has :
>
>mod ((2^16)-1-x)
>
>it is a decreasing modulus, so it decreases the modulus to near zero for
>the last entries of the S-Box.
Your point being ? If you look at my code, it works exactly the same
way as scott19u ..........
1. The for loop is exactly the same form as his, only with the
addition of the word 'int'.
Davids line :
for (i = 0; i < T19L-2 ; i++) {
My line :
for (int i = 0; i < T19L-2 ; i++)
2. I simply changed the line that performs the mod, to calculate the
entropy instead :
Davids line :
j = (un32)get19( prtb, i) % (T19L-i-1);
My line :
sum += entropy(T19L, T19L-i-1);
Where the entropy function
entropy (x, n)
calculates the entropy of the result of the operation y mod n, where y
is a perfectly random number between 0 and x.
For small values of n, the entropy of y mod n, will be accordingly
small.
I made a point of using Davids T19L - i - 1 so
it would be obvious that I haven't changed this, and it means
my code is also using a decreasing modulus as i increases,
exactly the same as scott19u.
There is one error in my code : I used T19L as the
maximum value for a 19 bit word, but it should be T19L - 1.
I've re-run the program with the correction but it makes
no difference to the answer I get.
(my line for the entropy should therefore be :
sum += entropy(T19L - 1, T19L-i-1); )
>
>This reduces the entropy for scott19u.zip . Half of the S-Box entries
>use less than mod 2^10 and half use more than more than mod 2^9 . This
>linearly changing moduls can be used to re-calculate an entropy ESTIMATE.
My number is NOT an estimate. If my maths and coding are correct, then
9187574 bits is a precise* maximum effective key length. With the
emphasis on maximum, because other parts of the scott19u algorithm may
reduce it still further.
- Tim.
*rounded to the nearest whole number.
------------------------------
From: Bill Stewart <[EMAIL PROTECTED]>
Subject: Re: RSA source code?
Date: Sun, 10 Jan 1999 16:38:40 -0800
Ask your favorite web search engine where to find RSAREF or RSAEURO.
RSAREF is a reference edition put out by RSA Inc. for non-commercial use,
though it has some unfortunate limitations and isn't permitted to be exported
from the US and Canada (which of course was done immediately :-) and
therefore may
have copyright issues if used in Berne Convention countries.
RSAEURO is a version that claims to have been compatibly re-implemented in
Europe,
and therefore has no copyright problems, but can't be used in the US for
patent reasons.
Also, Adam Back has a page describing lots of short implementations,
such as the 3-line Perl versions and their relatives.
Antonio ROMEO wrote:
> I need the RSA C source code.
> Can anyone help me?
------------------------------
From: Bill Stewart <[EMAIL PROTECTED]>
Subject: Re: RSA source code?
Date: Sun, 10 Jan 1999 16:40:08 -0800
Ask your favorite web search engine where to find RSAREF or RSAEURO.
RSAREF is a reference edition put out by RSA Inc. for non-commercial use,
though it has some unfortunate limitations and isn't permitted to be exported
from the US and Canada (which of course was done immediately :-) and
therefore may
have copyright issues if used in Berne Convention countries.
RSAEURO is a version that claims to have been compatibly re-implemented in
Europe,
and therefore has no copyright problems, but can't be used in the US for
patent reasons.
Also, Adam Back has a page describing lots of short implementations,
such as the 3-line Perl versions and their relatives.
Antonio ROMEO wrote:
> I need the RSA C source code.
> Can anyone help me?
------------------------------
From: Bill Stewart <[EMAIL PROTECTED]>
Crossposted-To: alt.2600
Subject: ANNOUNCE: Bay Area Cypherpunks Meeting, Jan.16th 1999, San Jose
Date: Sun, 10 Jan 1999 16:49:33 -0800
The Bay Area Cypherpunks Meeting will be held Saturday January 16th, 12-6pm
at the San Jose Convention Center, Room B1-B2. This is the Saturday
just before the RSA Convention. http://www.rsa.com/conf99/
Current Agenda:
12-1 - Arrive
1-1:30 - Introductions, Work In Progress
1:30-2 - "ArcotSign", Doug Hoover of Arcot
2-3 - Cracking IPSEC, Rodney Thayer
3-4 - OpenSSL, Sameer Parekh
4 - Java iButton, Martin Minow
4-6 - More Work In Progress
Dinner will be at a nearby location afterwards, probably Gordon Biersch.
Logistics:
The Convention Center is located at 150 W. San Carlos St, San Jose
[Insert real map, directions, location of doors, Room B1-B2.]
A followon announcement will include correct directions.
The Convention Center is located near I-280 and Rt. 87 Guadeloupe
Expressway.
Parking inside usually costs about $5, and there are
competing parking lots and potential street parking nearby.
Additionally, the San Jose Light Rail is nearby,
and connects with CalTrain.
http://www.mapblast.com/yt.hm?FAM=mapblast&CMD=GEO&SEC=find&W=640&H=400&IC=0%3A0%3A5&IC%3A=Convention+Center&AD2=150+West+San+Carlos&AD3=San+Jose%2C+CA
Due to building security requirements (exhibit setups are that day)
you will have to enter through the door at [### TBD ###]
and pick up a badge to make the building people happy.
I'll put up signs indicating the correct door,
and you can contact my cellphone at +1-415-307-7119 if
nobody is at the door when you arrive.
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: On the Generation of Pseudo-OTP
Date: Mon, 11 Jan 1999 00:59:14 GMT
Reply-To: [EMAIL PROTECTED]
On Sun, 10 Jan 1999 22:46:00 +0000, [EMAIL PROTECTED] (Paul L.
Allen) wrote:
>You appear to have very little conception of the failure modes of a
>reasonably-well designed TRNG. There are a *lot* of them...
It is not my place to be aware, since I am not claiming to be the TRNG
designer. I set the specification, comment on some of the most trivial
malfunctions and leave it to the designer to certify that his design
meets the specification.
My personal interest is not in making actual physical devices, but in
trying to find a suitable software substitute, even if it is only
compliant with certain restrictions, or failing that, trying to
understand why such a software substitute is impossible to design.
There are those who maintain that a software substitute for physcial
TRNG can never be designed, because all software is algorithmic and
therefore cannot possible generate all possible sequences of a given
finite length equiprobably.
The closest I can come to as a candidate is digit expansion of
transcendental constants, after being presumably treated to remove
correlation. But that requires some kind of decorrelation function, as
yet specified. I thought strong mixing would have satisfied that
requirement (per RFC 1750) but there were critics a year ago who
claimed otherwise.
>I'd check. I'd check *thoroughly*. I'd be a lot more wary of bad design
>giving me numbers that look random but aren't than a long string of
>zeroes being the result of a fault.
I fully agree that there is every possibility of hardware snake oil,
just as there is software snake oil. Your point is well taken.
>At some point the signal has to get into the computer. That allows all
>the RF the computer generates to be picked up and travel down the output
>lead back to the generator.
If the link is digital, how could RF be a factor in the path from the
TRNG output to the computer input?
>Battery power is a naive fix - you have to
>*know* what you're doing and design things properly.
I would not characterize battery power as naive - it is used all the
time in sensitive circuits. I agree that the design must be audited
for improper design, regardless of such considerations as battery
power.
>Radioactive noise generators are expensive and rare. Far more common
>are noisy avalanche diodes and there is a gain stage needed to turn that
>noise into something you can make digital.
Regardless of whether radioactive TRNGs are expensive and rare, if
that is what is needed to meet the TRNG spec reliably, then that is
what is needed. You could say the same for airplanes in 1900.
BTW, there is a commercial radioactive TRNG available IIRC that is not
all that expensive. If someone needs the total security of the OTP
cryptosystem, then the cost of the TRBG should not be an obstacle.
>I would laugh at anyone who claimed it was possible to compensate for
>all possible failure modes.
I think that is a bit presumptous on your part.
There are good designers who can demonstrate sound design methodology.
The folks who design triple modular redundant (TMR) systems for
critical applications such as nuclear facilities aren't bumpkins.
>It's not physically possible in this type of circuit.
That is a very bold assertion, which requires you to provide proof.
>Even in nice simple digital circuitry you can't stop
>failures from happening, the best you can hope to achieve is to detect
>them and switch in a backup.
Or sound an alarm and shut down. So what is wrong with that design
criterion for a TRNG being used to generate an OTP? After all, it
meets the specification.
>And the extra circuitry you need to do
>that detection itself can fail and even if designed well (so a failure
>of the detection circuitry registers as a failure of the system, which it
>is) it decreases the mean time between failures of the system as a whole.
>The system becomes *less* reliable (because there's more to go wrong)
>but you can detect the failures better.
You are apparently not all that well versed on TMR design methodoligy.
TMR designers put traps in for *every* component failure. And their
fail safe philosophy guarantees that there is no possible malfunction
that can go undetected.
It may not be necessary to go the full TMR route - that is for real
time systems. But it illustrates that there is adesign methodology
that prevents component failures from causing problems, and that
addresses your concerns adequately.
>I'm always interested in earning money, but I'd refuse a contract to
>design a TRNG where all possible failure modes led to the output being
>all zeroes (or any other detectable condition you care to specify) no
>matter how much you offered - I don't accept contracts which I know I can't
>meet.
TMR designs will meet that specification in real time.
>> You would set it at some realistic value which takes into account the
>> size of your output buffer. I would imagine that if you looked at
>> 20,000 bits, you would have sufficient reason to shut the TRNG off
>You might think that's a reasonable number. I'm not sure I'd agree.
I never said I agreed - that specifcation came from FIPS 140-1.
A TRNG that puts out 20,000 zeros is a piece of crap for use with the
OTP cryptosystem. Only a cryptanalyst who smokes large quantites of
incredibly bad dope would be so zonked to overlook a ciphertext that
was completely intelligible for a run of 20,000 bits.
>When you get somebody to design you a TRNG like that, where all possible
>failure modes get magically turned into an all-0s output or even a
>fail flag, ask him if you can borrow his philosopher's stone for a while
>then get yourself a lot of lead...
Consult TMR design.
>If you think those are the only two common malfunctions of digital
>circuits, you're very much mistaken.
I think you have made your point, a very valid point - that a shorted
output or open output are not the only significant modes of failure.
>From now on all TRNGs must meet single point to point conditions of
failure, with full alarm and shutdown at a minimum, and if they are
used in a real time application, they must meet TMR specifications.
I can live with that.
Bob Knauer
"We hold that each man is the best judge of his own interest."
--John Adams
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: SCOTT19U ENTROPY
Date: Sun, 10 Jan 1999 23:18:13 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Tim Redburn) wrote:
> I've been looking at the source for
> scott19u and at first glance I can see where
> the value 9205076 could come from.
>
> Scott19u takes each 19bit word in turn and then
> mod's it with it's position. If you take the entropy of this result
> to simply be the entropy of log<base 2>(position) then
> you get an entropy of 9205076.
>
> However, when performing x mod n, unless n is a factor
> of x, then the resulting entropy will be slightly less than
> log<base 2>(n).
>
> If I've worked it out correctly then the entropy of y mod n, where
> y is a perfectly random number between 0 and x, can be
> calculated as follows :
>
> assumptions : x is the maximum number that is going to be used -
> (in the case of scott19u this
> is 524288 ( = 2^19) the value in T19L in the
>
> source)
>
> a = x mod n
> b = (x - a) / n
>
> entropy = (n - a) * ((b/x) log<base2> (b/x))
> + a * (((b+1)/x) log<base2>((b+1)/x))
>
> using this formula in the code below, I get a value of 9187574 bits
> for the entropy of the key before being used for the generation
> of the S-Box, so I beleive that (assuming my maths is correct) this
> value is a maximum for the S-Box entropy.
>
> Please note that I have only checked as far as the key setup -
> i.e. what happens to the key before it is used to generate the
> permutation. I have not yet checked if the generation of the
> permutation removes any more entropy.
>
> Also I haven't checked either the formula or the code properly, so
> corrections greatly appreciated. I derived the formula from shannons
> paper - page 11. (the numbers seem reasonable though).
>
> So in answer to the question, yes 8000000+ bits is probably correct,
> but I think you need to be more precise, to give people
> confidence in your algorithm. I suggest 9187574 bits.
>
If Horst does not have heart burn with this and if no one
else comes up with a reasonable alternative I will use
the nubmber that is honest but not precise. Because I like
the ring of 8,000,00+ bits or "one million plus bytes"
After all did you ever have a Rubic's cube. The add discribing
the number of combintions was a gross under estimate
of the actaul number of combinations. And since the average
person would not belive the real number they picked a more
belive able number.
It kind of made it more fun. But I am glad you agree that
it seems to be more than 8,000,000+ bits
> ////////////////////////////////////////////////////////////
> #include <math.h>
> #include <iostream.h>
>
> #define T19LL (1245184)
> #define T19L (0x80000)
>
> double entropy(unsigned x, unsigned n)
> {
> double a = x % n;
> double b = (x - a) / n; // = the whole number of times, n goes in x.
>
> return (n - a) * ((b / x) * log (b / x)) / log (2)
> + a * (((b+1)/x) * log ((b+1)/x)) / log (2);
> }
>
> int main()
> {
> long double sum = 0;
>
> for (int i = 0; i < T19L-2 ; i++)
> sum += entropy(T19L, T19L-i-1);
>
> cout<<(unsigned)(-sum)<<endl;
>
> return 0;
> }
> //////////////////////////////////////////////////////////////
>
> On Sat, 09 Jan 1999 14:19:12 GMT, [EMAIL PROTECTED] wrote:
>
> > The entidy that prodded me into getting a web page that
> >goes by name "Horst O.." (can't spell rest of name).
> >Has finally realized that its calculaation of Entopy bits
> >H(D) is wrong. He wants it changed. So I am willing to do
> >this the question is what should I replace it with. I
> >would really like a honest valid one. There was a theard
> >on this topic several months ago but at that time I refused
> >to change it since wanted to leave his work untouched even
> >if wrong. However I have received Email that is from Horst
> >and he did not give what I wanted for a change since if I
> >bother to change it I want it RIGHT.
> > He came up with one number that he said was based on
> >work of "Sandy Harris" as an approximate number which
> >I think is low. Then he came up with
> > log( (2**19)! ) and got a number I did not agree with.
> >I read Shannons paper and felt that it should be
> >
> > log<base2>( ((2**19)-1)! ) which is same as
> >
> > log( ((2**19)-1)! )/( log(2) )
> >
> > which is 9,205,076.12815.... This is based on a uniformily
> >random key. But if one uses a uniformly random remainder table
> >the keyraw.key file. it would be reduced by at most 1.00 so
> >I would like to flat state it is above
> >
> >entropy is 8,000,000+ bits
> >
> >does anyone have heart burn or a different anwser.
> >
> >Also made the scott19u contest files. Sent them to
> >Joe P. He has stated he would look for obvious errors
> >and write a user friendly "read.me" file for it since
> >my english not the best. But have yet to hear from
> >him so hopefully soon the contest which one only needs
> >to solve for 64 bits max is almost ready. I KNOW
> >64 BITS IS LESS THAN 8,000,000+ BITS but I want to
> >show it is strong and a hope it takes at least 3 months
> >for some one to grind out this unsecure contest. The
> >NSA will have anwser in an hour. I just hope they don't
> >give it to one of there stooges to make contest end
> >quickly. Also if method is weak some one may actually
> >use there brain to vastly short cut this so a full 64 bit
> >search is not necessisary. I am sure that problem is reduced
> >in such a way that many such short cuts exisit. I have thought
> >of several that reduce it to close to 56 bits.
> > So people like Paul Onions may come up with something quite
> >fast.
> >
> >David A. Scott
> >
> > P.S. as they so on the prono sites "ENJOY"
> >
> >http://cryptography.org/cgi-bin/crypto.cgi/Misc/scott19u.zip
> >http://members.xoom.com/ecil/index.htm
> >
> >-----------== Posted via Deja News, The Discussion Network ==----------
> >http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
>
>
http://cryptography.org/cgi-bin/crypto.cgi/Misc/scott19u.zip
http://members.xoom.com/ecil/index.htm
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
** 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
******************************
