Cryptography-Digest Digest #884, Volume #8 Mon, 11 Jan 99 16:13:03 EST
Contents:
Re: On the Generation of Pseudo-OTP (R. Knauer)
Can anyone recommend a good export attorney? ("Warren Johnson")
Re: On the Generation of Pseudo-OTP (R. Knauer)
Differential Cryptanalysis??? ("Michael A. Greenly")
Re: Edu sources for an amateur (Mike Morrow)
Re: Practical True Random Number Generator ("John Feth")
Re: On the Generation of Pseudo-OTP ("John Feth")
Re: Practical True Random Number Generator (R. Knauer)
Re: Practical True Random Number Generator (R. Knauer)
Re: On the Generation of Pseudo-OTP (R. Knauer)
Re: On the Generation of Pseudo-OTP (R. Knauer)
Re: On the Generation of Pseudo-OTP (Patrick Juola)
Re: SCOTT19U ENTROPY ([EMAIL PROTECTED])
Re: On the Generation of Pseudo-OTP (R. Knauer)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: On the Generation of Pseudo-OTP
Date: Mon, 11 Jan 1999 18:09:40 GMT
Reply-To: [EMAIL PROTECTED]
On Mon, 11 Jan 1999 17:35:45 +0100, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>> Does that convince you that I can PROVE what I said?
>It is NOT a rigorous proof in the mathematical sense.
Who says that only mathematical proofs are valid?
>It is a 'plausible' proof.
No, it is a rigorous proof.
If the physcial process, such as radioactive decay, is completely
random, and the TRGN is properly constructed, then the output is
suitable for a totally secure OTP.
Of course the designer has to certify that the TRNG behaves as
advertised, but that can be done. The radioactive source can be
certified to follow a first order rate law to within an arbirtary
level of precision. The electronics can be designed to withstand any
single point of failure. The entire system can be subjected to
multiple Bayesian Attacks.
You can be the hotline between Washington and Moscow, rumored to be an
OTP link, was certified with at least that much rigor. One thing you
can say for the NSA is that they do not fool around when it comes to
crypto security.
And thank God they do too - we give away enough vital secret
information to our foreign enemies as it is, much less opening our
entire defense system to casual perusal.
>I never argued that hardware noises were bad.
And I have never considered using them for a TRNG.
>I believe they are mostly excellent.
On what do you base that assertion?
>But perfect are they NOT, nonetheless.
So what? They can be certified to meet a certain level of practical
perfomance which for all effects and purposes is the same as total
security. Just because a TRNG creates a pad that leaks a bit or two of
information now and then isn't going to detract from their practical
value as generators of totally secure pads.
>But we don't (never) need perfectness in practice, so
>they (assuming that bias are sufficiently reduced) can for all
>practical purposes be substitutes for the (practically unobtainable)
>ideal OTP.
Each case must be considered separately. I have proven that from
direct experimentation certain kinds of radioactive decay meet the
specifications for a TRNG. I have not seen an analysis for electronic
noise in general. I would expect that the analysis would depend
crucially on the source of the noise.
The problem I forsee with electronic noise generators is that they
have a finite spectral response, which in principle could limit them
as TRNGs, in the sense that not all possible sequences would be
capable of being output equiprobably. That is not a problem with a
digital device like a properly designed radioactive decay TRNG.
>But the justification of using these has ultimately to come
>from a risk and cost analysis of the user.
Not if it is being used for the OTP. In that instance, only the best
TRNG will suffice - best in the practical sense.
>Since software made
>'intended approximations of ideal OTP' presumably can also attain
>negligible correlations,
That is what remains to be shown. Can one construct a procedure to
remove correlation from calculated or natural language or music
bitstreams?
>they have also a chance of substituting
>the hardware noises in certain applications, IF this can be
>justified from a risk and cost analysis.
There is no risk with the OTP system. It either works or it doesn't.
And cost is irrelevant if you must have a proveably (in the practical
sense) secure system.
Bob Knauer
"Anyone that can get elected, is not qualified to serve."
--Lance Bledsoe
------------------------------
From: "Warren Johnson" <[EMAIL PROTECTED]>
Subject: Can anyone recommend a good export attorney?
Date: Mon, 11 Jan 1999 11:22:08 -0600
Re all,
I'm looking for a recommendation as to a good Attorney to handle the
submission of an application to export encryption....
Thanks in advance!
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: On the Generation of Pseudo-OTP
Date: Mon, 11 Jan 1999 17:49:53 GMT
Reply-To: [EMAIL PROTECTED]
On 11 Jan 1999 16:34:46 GMT, [EMAIL PROTECTED] (John Briggs)
wrote:
>>>Which compression algorithm would you recommend?
>>The one which reduces the plaintext the most in size.
>Which plaintext?
>Please specify clearly whether the plaintext is selected before or after
>the compression algorithm. And specify how the recipient knows which
>decompression algorithm to use.
This discussion was an offshoot of a comment I made about Greg
Chaitin's algorithmic complexity theory, and why I did not think it
was applicable to crypto-grade random numbers suitable for the OTP
cryptosystem.
Since then someone has pointed out that compressed text has enough
information in it to disqualify them from being maximally reduced.
Bob Knauer
"Anyone that can get elected, is not qualified to serve."
--Lance Bledsoe
------------------------------
From: "Michael A. Greenly" <[EMAIL PROTECTED]>
Subject: Differential Cryptanalysis???
Date: Mon, 11 Jan 1999 11:38:18 -0600
I've been trying to get a handle on differential crytptanalysis for
the last week or two but seem to have run into a road block of sorts. I
think I understand most of it but there's one part the seems to elude
me. I don't understand how a right pair suggests a key?
Here is the cipher which I have been trying to apply it to. Its a
very simple 3 round fiestel network with an 8 bit block. I've labeled
it EC1 for educational cipher 1.
Here's the cipher: http://www.pinenet.com/~mgreenly/twisted.gif
Here's it's f-function: http://www.pinenet.com/~mgreenly/ffunction.gif
Here's it's substitution table:
http://www.pinenet.com/~mgreenly/stable.gif
As soon as I can I will put together a web page describing the
cipher, and my attack on it.
--
Mike Greenly
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Mike Morrow)
Subject: Re: Edu sources for an amateur
Date: Mon, 11 Jan 1999 17:51:42 GMT
I searched for "Applied Cryptography" in amazon.com and came up with
many book with that in the name. Could you give an ISBN or some other
specification to help me narrow it down to the correct book. I want a
intro course, too.
Thanks,
Mike
On 5 Jan 1999 23:29:14 GMT, [EMAIL PROTECTED] (Colin G. St. John)
wrote:
>In article <[EMAIL PROTECTED]>,
>[EMAIL PROTECTED] says...
>>
>>Hello All:
>>
>>I just stumbled on to this group. I am very interested in cryptography
>>as a concept. The closest I've got to it is reading the "Puzzle Palace"
>>and writing some simple hieroglyphic codes for amusement (inspired by
>>Sherlock Holmes' "The case of the dancing men").
>>
>>Can you experts out there recommend good sources of info to educate
>>myself (say from a public library) on cryptography ? I'd like to know
>>what 56 bit vs 128 bit encryption means, what is PGP, RCA kinda lingo.
>>
>>Thanks in advance.
>>
>>--
>>[EMAIL PROTECTED]
>>
>>
>
> Buy "Applied Cryptography" by Bruce Schneier. It has
>758 pages of modern cryptography. Highly recommended for
>an interested amateur who wants to study up. It also
>has a large bibliography for further research.
>
> Colin
============= Posted via Newsfeeds.Com, Uncensored Usenet News ============
http://www.newsfeeds.com/ The Largest Usenet Servers in the World!
============= Over 66,000 Groups, Plus a Dedicated Binaries Server ============
------------------------------
From: "John Feth" <[EMAIL PROTECTED]>
Subject: Re: Practical True Random Number Generator
Date: 11 Jan 1999 18:47:45 GMT
A good way to generate a random number string, c, is with the encrypting
alogrithm:
c= MOD(m^e, pq)
find primes p and q so that the product has, say, 1,500 digits; use e as,
say, 23, and input m with a few digits less than the product pq. A good
way to start would be by using the first 1495 digits in pi (or e, or sqrt
2, or any other irrational) as the first m to calculate the first c.
Simply changing even a single digit in the first m to create the second m
gives yet another vastly different second c. Repeat this process until you
have enough digits for your considered use. I use DeriveXM (a math
program) and it takes only a few milliseconds to obtain c from m (or put
another way only about a microsecond per random digit).
By the way, I think these number strings can be legitimately called random
numbers. First because I've run an Allan Variance on lots of these strings
and found them to be quite random, and second because there is a very
strong argument that even with the inclination, no one with out the above
algorithm could reproduce the same string. So we have a random number
generator (RNG), not a pseudo-random number generator (PRNG).
Note that it is NOT necessary to find d such that:
m=MOD(c^d,pq)
as is done to decrypt .
Regards,
John Feth
hapticz <[EMAIL PROTECTED]> wrote in article
<ePpsruJP#GA.132@upnetnews05>...
> random?? hmm, hows about a laser pointed into the sky and reflected
> atmospheric refractions detected with small photo-sensor? or point it at
a
> body of water
> sampled over periods of extended lengths to build a composite database.
>
> or maybe rather than random, perhaps a completely ordered world where
> everyone is not trying to deceive each other? ;-))
>
> --
> best regards
> [EMAIL PROTECTED]
>
>
>
>
>
------------------------------
From: "John Feth" <[EMAIL PROTECTED]>
Subject: Re: On the Generation of Pseudo-OTP
Date: 11 Jan 1999 19:00:05 GMT
A good way to generate a random number string, c, is with the encrypting
alogrithm:
c= MOD(m^e, pq)
find primes p and q so that the product has, say, 1,500 digits; use e as,
say, 23, and input m with a few digits less than the product pq. A good
way to start would be by using the first 1495 digits in pi (or e, or sqrt
2, or any other irrational) as the first m to calculate the first c.
Simply changing even a single digit in the first m to create the second m
gives yet another vastly different second c. Repeat this process until you
have enough digits for your considered use. I use DeriveXM (a math
program) and it takes only a few milliseconds to obtain c from m (or put
another way only about a microsecond per random digit).
By the way, I think these number strings can be legitimately called random
numbers. First because I've run an Allan Variance on lots of these strings
and found them to be quite random, and second because there is a very
strong argument that even with the inclination, no one without the above
algorithm could reproduce the same string. So we have a random number
generator (RNG), not a pseudo-random number generator (PRNG).
Note that it is NOT necessary to find d such that:
m=MOD(c^d,pq)
as is done to decrypt
Regards,
John Feth
PS I am unaware that the order of digits in Pi is anything but random.
Any references?
R. Knauer <[EMAIL PROTECTED]> wrote in article
<[EMAIL PROTECTED]>...
> On Mon, 11 Jan 1999 14:26:33 +0100, fungus
> <[EMAIL PROTECTED]> wrote:
>
> >> 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.
>
> >I think we've already been through this thousands of times here
> >on sci.crypt, but here goes:
>
> Aha! An Oldtimer from years past. I thought everyone who had
> participated in those long-winded discussions a year ago had moved on.
>
> >> 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.
>
> >Correct.
>
> >However, if you design a PRNG with a massive number of possible
> >seeds then it can be useful for cryptography. Such algorithms
> >*already exist*, and are commonly called
>
> ><SHOUT> **** STREAM CIPHERS **** </SHOUT>
>
> This gets to the crux of the quandry I am trying to expose. There are
> two opposing hypotheses. One states the following. The other follows
> after it.
>
> Hypothesis One:
>
> Is having a "massive number of seeds" sufficient to make a given
> stream cipher practically secure? Can such a cipher withstand a
> Bayesian Attack?
>
> The problem with such a stream cipher is that the number of possible
> sequences is limited to the number of seeds that can be constructed.
> By definition, a seed is much smaller than the length of the resulting
> bitstream.
>
> If one used such a bitstream, then there would be only one possible
> intelligible plaintext message contained in the ciphertext, since all
> other intelligible plaintexts would not be possible due to the limited
> number of sequences output by a seeded bitstream generator.
>
> IOW, if the cryptanalyst determines that you are using a seeded
> bitstream generator where the seed length is considerably smaller than
> the length of your ciphertext, and he comes across an intelligible
> plaintext message in your ciphertext that is consistent with his
> probablistic analysis, then it is the only possible intelligible
> message because it exceeds the unicity distance considerably.
>
> This is not the case with an OTP, because the key is as long as the
> plaintext.
>
> Hypothesis Two:
>
> The problems states above can be circumvented by certain kinds of
> streams obtained from the digit expansions of transcendental
> constants, suitably mixed to remove correlations, because those
> sources are not subjected to the limitations of seeded bitstreams.
>
> All possible bitstreams are capable of being output equiprobably
> because there is no inherent limitation when several of them are
> strongly mixed.
>
> [More comments on Hypothesis Two are below.]
>
> >Nope, definitely not a good idea. Numbers like pi are infinitely
> >long but are not random.
>
> Define what you mean by random in the context of finite digit
> expansions. Then prove, or at least defend, your assertion using that
> definition in that context.
>
> If you mean non-random because such digit expansions are calculable,
> then I fully agree. That is why further refinement is in order. The
> only reason to consider digit expansions of transcendental numbers is
> that they are purportedly not periodic nor biased. That leaves only
> correlation to deal with (not that bias is all that difficult to
> handle).
>
> If one were to generate several digit expansions using different
> offsets for various transcendental constants and strongly mix them (as
> in FIPS 140-1), would your statement still be valid? If so, why?
>
> Put another way, why would such a method of producing bitstreams limit
> the number of possible sequences from its maximum for a given finite
> length and/or why would such sequences not be equiprobable?
>
> Is there a reason to believe that if I chose an arbitrary offset into
> the digit expansion of Pi, that the sequence that is generated from
> that offset is not one of all possible sequences of that length, and
> that it is equiprobable with all of those other possible sequences? If
> not, what is it about the digit expansion of Pi that causes such
> limitations?
>
> Bob Knauer
>
> "Anyone that can get elected, is not qualified to serve."
> --Lance Bledsoe
>
>
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Practical True Random Number Generator
Date: Mon, 11 Jan 1999 19:46:53 GMT
Reply-To: [EMAIL PROTECTED]
On Mon, 11 Jan 1999 12:20:14 -0600, Medical Electronics Lab
<[EMAIL PROTECTED]> wrote:
>it's pretty damn hard for a real random
>number generator to pass something like DIEHARD without using a
>hash function.
Does that include one based on radioactive decay?
Bob Knauer
"Anyone that can get elected, is not qualified to serve."
--Lance Bledsoe
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Practical True Random Number Generator
Date: Mon, 11 Jan 1999 19:50:00 GMT
Reply-To: [EMAIL PROTECTED]
On 11 Jan 1999 18:47:45 GMT, "John Feth" <[EMAIL PROTECTED]>
wrote:
>By the way, I think these number strings can be legitimately called random
>numbers. First because I've run an Allan Variance on lots of these strings
>and found them to be quite random, and second because there is a very
>strong argument that even with the inclination, no one with out the above
>algorithm could reproduce the same string. So we have a random number
>generator (RNG), not a pseudo-random number generator (PRNG).
Unless the ciphers created from the pads can withstand a Bayesian
Attack, the random number generator you propose is not verified to be
crypto-grade secure.
Bob Knauer
"Anyone that can get elected, is not qualified to serve."
--Lance Bledsoe
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: On the Generation of Pseudo-OTP
Date: Mon, 11 Jan 1999 19:51:19 GMT
Reply-To: [EMAIL PROTECTED]
On 11 Jan 1999 19:00:05 GMT, "John Feth" <[EMAIL PROTECTED]>
wrote:
>By the way, I think these number strings can be legitimately called random
>numbers.
Unless the ciphers created from the pads can withstand a Bayesian
Attack, the random number generator you propose is not verified to be
crypto-grade secure.
Bob Knauer
"Anyone that can get elected, is not qualified to serve."
--Lance Bledsoe
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: On the Generation of Pseudo-OTP
Date: Mon, 11 Jan 1999 20:24:27 GMT
Reply-To: [EMAIL PROTECTED]
On Mon, 11 Jan 1999 18:49:55 +0000, [EMAIL PROTECTED] (Paul L.
Allen) wrote:
>Then take it from me that parts of your specification are ridiculous.
Aha! An ad-hominem.
Must mean you do not have the confidence necessary to present your
points reasonably.
Bob Knauer
"Anyone that can get elected, is not qualified to serve."
--Lance Bledsoe
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: On the Generation of Pseudo-OTP
Date: 11 Jan 1999 10:03:05 -0500
In article <[EMAIL PROTECTED]>,
R. Knauer <[EMAIL PROTECTED]> wrote:
>On Mon, 11 Jan 1999 14:26:33 +0100, fungus
><[EMAIL PROTECTED]> wrote:
>
>>> 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.
>
>>I think we've already been through this thousands of times here
>>on sci.crypt, but here goes:
>
>Aha! An Oldtimer from years past. I thought everyone who had
>participated in those long-winded discussions a year ago had moved on.
>
>>> 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.
>
>>Correct.
>
>>However, if you design a PRNG with a massive number of possible
>>seeds then it can be useful for cryptography. Such algorithms
>>*already exist*, and are commonly called
>
>><SHOUT> **** STREAM CIPHERS **** </SHOUT>
>
>This gets to the crux of the quandry I am trying to expose. There are
>two opposing hypotheses. One states the following. The other follows
>after it.
>
>Hypothesis One:
>
>Is having a "massive number of seeds" sufficient to make a given
>stream cipher practically secure? Can such a cipher withstand a
>Bayesian Attack?
Rather obviously not. For example, if my PRNG (based on a seed of
N) produces a stream of N zeros followed by a one (repeatedly), then
increasing the number of seeds does not add very much if anything to
the miniscule security. In fact, this stream cypher can probably
be cracked without reference at all to the generator.
>The problem with such a stream cipher is that the number of possible
>sequences is limited to the number of seeds that can be constructed.
>By definition, a seed is much smaller than the length of the resulting
>bitstream.
>Hypothesis Two:
>
>The problems states above can be circumvented by certain kinds of
>streams obtained from the digit expansions of transcendental
>constants, suitably mixed to remove correlations, because those
>sources are not subjected to the limitations of seeded bitstreams.
>
>All possible bitstreams are capable of being output equiprobably
>because there is no inherent limitation when several of them are
>strongly mixed.
[snip]
>If you mean non-random because such digit expansions are calculable,
>then I fully agree. That is why further refinement is in order. The
>only reason to consider digit expansions of transcendental numbers is
>that they are purportedly not periodic nor biased. That leaves only
>correlation to deal with (not that bias is all that difficult to
>handle).
>
>If one were to generate several digit expansions using different
>offsets for various transcendental constants and strongly mix them (as
>in FIPS 140-1), would your statement still be valid? If so, why?
>
>Put another way, why would such a method of producing bitstreams limit
>the number of possible sequences from its maximum for a given finite
>length and/or why would such sequences not be equiprobable?
First, there's no demonstration or proof that any given trancendental
number is suitable for use as a stream cypher. The numbers
0.1234567891011121314151617181920...
0.1010010001000010000010000001000...
and
0.1100010000000000000000010000000...
are all trancendental and cryptographically worthless. (The last one,
where the Nth digit is 1 iff N == K! for some K, is, incidentally, the
first proven trancendental numer).
Second, just because a given stream is believed random (such a pi)
does *NOT* imply that it's useful for a stream cypher. In particular,
if you've only got a finite number of starting points, then you'll only
generate a finite number of streams and you're back to breaking the
cypher by seed enumeration. Just think of each possible starting
position as a seed. And if you *don't* accept that there are only
a finite number of possible starting points.... well, just how much
work are you willing to do to compute the 2^128'th digit of pi as
the first bit of your stream cypher?
>Is there a reason to believe that if I chose an arbitrary offset into
>the digit expansion of Pi, that the sequence that is generated from
>that offset is not one of all possible sequences of that length, and
>that it is equiprobable with all of those other possible sequences? If
>not, what is it about the digit expansion of Pi that causes such
>limitations?
There is, actually. There's a known closed form solution for the
digits of pi (in base 16) that I find troublesome. But more troublesome
than that is the fact that I rather doubt you'll use a truly
arbitrary output.
-kitten
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: SCOTT19U ENTROPY
Date: Mon, 11 Jan 1999 13:09:29 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Tim Redburn) wrote:
> 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.
>
snip ...
> 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); )
>
snip...
> 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.
>
I have two questions and then I may agree completely with you
please write formula not just numer anwser.
1. what is entropy of 8 states each occurring with 1/8 probabolity?
2. what is entropy of 8 states with the following probabilites
1/10 1/10 1/10 1/10 1/10 1/10 2/10 2/10 ?
Thank You for taking the time to look at code. Also the methods
in scott19u and scott16u are the same it is just the the code
looks totally different do to 19 bit packed array harder to work
with than the 2 byte 16 arrays used in scott16u and the used a
different amount of shit on the looping since 1 byte shift 8 bits
in scott16u but 9 bits for scott19u. Other than that basically
everything is exactly the same.
David Scott
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
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: On the Generation of Pseudo-OTP
Date: Mon, 11 Jan 1999 20:40:15 GMT
Reply-To: [EMAIL PROTECTED]
On 11 Jan 1999 19:52:01 GMT, [EMAIL PROTECTED] (John Briggs)
wrote:
>But that ducks the question of what constitutes a maximum reduction.
I am not trying to duck any question. The comment is no longer
relevant since it is now clear that Chaitin's definition of randomness
is not applicable to crypto. You are coming in on this a bit late.
His concept of randomness is that it represents the irreducibility of
a number algorithmically. IOW, if there is no way to reduce the size
of a number further, then it contains no further information and is
therefore random, sicne the smallest algorithm needed to reproduce it
is of the same complexity as the number itself.
But that is not a suitable definition for a crypto-grade random
number, since a TRNG outputs all possible numbers including those that
can be algorithmically reduced - and as we all know, if one attempts
to filter those "non-random" numbers out of the OTP, it will ruin the
total security of the OTP ciphers.
>Do you judge one particular plaintext?
>Or the average across some distribution of plaintexts?
Chaitin's theory applies to any number, therefore if it had any
applicability to crypto, it would presumably apply to all plaintexts.
>I know my answer. Unfortunately, I think yours is different.
I don't have an answer. However, I would like to hear your comments.
Bob Knauer
"Anyone that can get elected, is not qualified to serve."
--Lance Bledsoe
------------------------------
** 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
******************************
