Cryptography-Digest Digest #846, Volume #9 Thu, 8 Jul 99 00:13:02 EDT
Contents:
Re: optimizations (for feedback PRNGs...) ([EMAIL PROTECTED])
Re: Is it possible to combine brute-force and ciphertext-only in an attack?
([EMAIL PROTECTED])
Re: Impossible to decrypt files encrypted with attached program - encrypt.exe [0/1]
([EMAIL PROTECTED])
Re: optimizations (for feedback PRNGs...) ([EMAIL PROTECTED])
Re: optimizations (for feedback PRNGs...) (Greg Ofiesh)
On the MD5 ("Joe")
Re: Summary of 2 threads on legal ways of exporting strong crypto (Isaac)
Re: I don't trust my sysadmin (Vernon Schryver)
Weakness of MLCG style encryption ("Greg Keogh")
Re: Summary of 2 threads on legal ways of exporting strong crypto (Isaac)
Re: Is it possible to combine brute-force and ciphertext-only in an ("Douglas A.
Gwyn")
Re: Weakness of MLCG style encryption ([EMAIL PROTECTED])
Re: Properties of Chain Addition? ("Douglas A. Gwyn")
Is Stenography legal? ([EMAIL PROTECTED])
Re: Properties of Chain Addition? ([EMAIL PROTECTED])
Analysis of DDARNG ([EMAIL PROTECTED])
Re: On the MD5 ([EMAIL PROTECTED])
Re: Crack of CIA'KRYPTOS N3 ("Douglas A. Gwyn")
Re: Weakness of MLCG style encryption (David A Molnar)
Re: Properties of Chain Addition? ([EMAIL PROTECTED])
Re: Properties of Chain Addition? ([EMAIL PROTECTED])
Re: Properties of Chain Addition? ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: optimizations (for feedback PRNGs...)
Date: Thu, 08 Jul 1999 01:05:18 GMT
In article <7m0t4a$st0$[EMAIL PROTECTED]>,
Greg Ofiesh <[EMAIL PROTECTED]> wrote:
> Yes, but software is more pure - no wires to hassle with. Great
> simulator to find the best approach.
>
> By the way, is posting the code fragments a violation of export
> regulations?
Nope. To the best of my knowledge the code has to work (they really
jump on packages or binaries, i.e Bernstein...) (protect yourself....
can we say typo?)
Who really cares about EAR anyways? Are they gonna arrest me (a 17
year old Canadian) for the crime of 'use of a brain?'.
They let people design bombs, rockets, and really fast and dangerous
cars. Somehow crypto software is the same as a sidewinder...
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Is it possible to combine brute-force and ciphertext-only in an attack?
Date: Thu, 08 Jul 1999 00:48:44 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
> If one's plaintext were so well compressed as to be indistinguishable
> from random data, it would not be possible to be confident of any
> decipherment. (Of course, the possible decipherments would still be
> limited to those which could be produced from the system used.)
Of course no compressed data is random. You can't decompress random
data (well in most coders you could...).
>
> This is one of the limiting cases of encryption deducible from
> information theory, just like the more famous case of the one-time
> pad.
>
Well the OTP is provably secure whereas as reverisble compression is
practically secure (big diff).
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Impossible to decrypt files encrypted with attached program - encrypt.exe
[0/1]
Date: Thu, 08 Jul 1999 01:06:53 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Bob) wrote:
> Can anyone decrypt files encrypted with the attached program?
>
Hmm.. Wow where is this magical file?
Look I will examine source code, papers and possibly even cocktail
napkins, but I think I speak for everyone when I say. 'Reverse
engineering code is not my idea of fun'. If you have the source for
the program and the ciphertext I will give it a try... otherwise spah!
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: optimizations (for feedback PRNGs...)
Date: Thu, 08 Jul 1999 00:52:16 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> There is no reason the size of the data storage must match the offset
> between feeback points. So, using the 521/32 LFSR you can store 1024
> words and update indexes without division or branching.
>
> #define BUFFSIZE 1024 /* power of two */
>
> int buffer[ BUFFSIZE ];
>
> int tap1 = 521
> , tap2 = 32
> , fill = 0
> ;
>
What is the period of THIS generator then? It is not the same as a 521
bit generator!!!
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Greg Ofiesh <[EMAIL PROTECTED]>
Subject: Re: optimizations (for feedback PRNGs...)
Date: Thu, 08 Jul 1999 00:58:56 GMT
> I might try that. Although parallel LFSRs are designed for
software...
Yes, but software is more pure - no wires to hassle with. Great
simulator to find the best approach.
By the way, is posting the code fragments a violation of export
regulations?
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "Joe" <[EMAIL PROTECTED]>
Subject: On the MD5
Date: Thu, 8 Jul 1999 11:37:58 +1000
Dear sci.crypt
I've read a paper on the cryptanalysis of MD5 which was written by Dr.
Dobbertin in 1996.
I got a copy of this paper from
http://www.ph.tn.tudelft.nl/~visser/hashes.html.
I'm really wondering whether we can say MD5 is still collision-free or not.
Joe
------------------------------
From: [EMAIL PROTECTED] (Isaac)
Crossposted-To: talk.politics.crypto
Subject: Re: Summary of 2 threads on legal ways of exporting strong crypto
Date: 7 Jul 1999 20:39:45 GMT
On Wed, 07 Jul 1999 01:11:29 -0400, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
>Be careful here. If you export something that a judge or jury will not
>consider "speech", i.e., human->human communication, you may lose the
>first amendment protection and be back in trouble.
>
The legal export of PGP as printed material does not rely directly on
the first amendment, but rather on the explicit provision in EAR that
export of printed source code is not restricted. If this limitation
is adhered to, I don't see any reason for a judge or jury to be
considering anything. No case will even be brought.
Isaac
------------------------------
From: [EMAIL PROTECTED] (Vernon Schryver)
Subject: Re: I don't trust my sysadmin
Date: 7 Jul 1999 18:40:00 -0600
In article <7m0a8l$c1f$[EMAIL PROTECTED]>,
Patrick Juola <[EMAIL PROTECTED]> wrote:
> ...
>because the folks at the DoD &c. don't believe that a million
>bazillion ifdefs are an acceptable way to write secure, reliable
>code.
>
>A sentiment I (and you, apparently) also share.
I'll go farther than that. I think that such security games make (mostly
'made') sense for $M systems in glass houses, but are silly for almost all
real systems. Today, except for a few special, unsually expensive boxes,
if you need real security, it's almost always cheaper, more reliable, and
far more secure to buy a complete computer and dedicate it to a single
task. Physical compartmentalization yields far better proofs of security
in the standard mathematical sense of a semi-formal arguments that convince
people with appropriate mathematical maturity. Formal (i.e. mechanical)
proofs of correctness have their familiar old problems. Evaluations by
hired code readers cannot convince anyone who has fought mundane security
problems.
> ...
>I strongly suspect it was B1; B1 is essentially the highest level that
>can be retrofitted onto an existing OS.
Your suspicion is confirmed by the URL provided by another,
http://www.radium.ncsc.mil/tpep/epl/epl-by-class.html
In looking through the systems listed on that page, even I am surprised
by the old ages of all except the Wang systems. You'd have to care a lot
more about "government grade" security than price/performance or raw
performance to buy any of them.
It looks like the effort to commercialize goverment grade security
that I mentioned is at best not doing well and is probably moribund.
Not that I didn't predict that when I first heard the song and dance.
> ...
>My point is fairly simple -- and compatible with yours. UNIX by itself
>is C1, I recall correctly. You can hack it up, almost beyond recognition
>and usability, to achieve B1 security. If you want something better,
>they *are* available, but not as anything Unix-alike. Which means
>most people don't want them.
Yes, and unless the person with the original question wants to start
checking operators' home trash cans for changes in alcohol consumption,
giving surprise lie detector tests, searching all packages going into the
facility (forget taking anything out), armed guards, and the rest of the
drill, including disconnecting from any real network, even B1 systems are
irrelevant.
I think the answer for the original question is either
- if the data is sufficiently valuable, buy a separate computer,
find a trustworthy sysadmin (possibly yourself), and probably
disconnect from networks including modems on the PSTN.
- if not, exercise ordinary care in hiring people and vendors, and
"don't worry; by happy"
Vernon Schryver [EMAIL PROTECTED]
------------------------------
From: "Greg Keogh" <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Weakness of MLCG style encryption
Date: Thu, 8 Jul 1999 10:55:03 +1000
Hello from Melbourne Australia,
Back in the late 1980s I wrote a handy utility program to encrypt files for
safe keeping by XORing the file with an MLCG stream. I didn't use any old
MLCG, I used the combined one by Pierre L'Ecuyer with a period of about
10^18, thereby rendering my cipher unbreakable (so I thought <g>).
I'd almost forgotten about my old program until I purchased Bruce Schneier's
book (http://www.counterpane.com/applied.html) a couple of years ago and
read the introduction to his chapter on random numbers and related topics.
Without going into any technical details, Schneier describes how encryption
with MLCG streams was easily broken, then it's fancier variants were broken,
then polynomial generators of any degree were broken. Hence, pseudo-random
number generators are of no direct use for encryption.
I only follow encryption as a hobby, so without any deep maths background I'
m somewhat dumbfounded that these pseudo-random sequence generators that
seem so fantastically random are of no use for XORing streams. Can anyone
give me a potted summary of why this is so? How strong are they in practical
terms? What techniques are used to break them? Etc. Any general information
or web references would be most welcome.
Cheers,
Greg Keogh <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Isaac)
Crossposted-To: talk.politics.crypto
Subject: Re: Summary of 2 threads on legal ways of exporting strong crypto
Date: 8 Jul 1999 02:19:46 GMT
On Wed, 07 Jul 1999 19:43:17 +0200, Mok-Kong Shen
>
>Very detailed descriptions which one could translate one-to-one
>to codes have already been done. If I don't err, RSA has recently
>published a RFC on BSAFE just in that way. Someone conjectured
>that there RSA has a mechanism for automatically converting that to
>C and reciprocally.
>
Hey this looks a lot more interesting than some of the other ideas
I've seen in this thread. I see two forces at work here that make
this interesting with respect to EAR.
First, mechanical translation or not, such an RFC doesn't quite meet
any of the definitions of software as described in EAR. It's arguably
not source code, and definitely not object or executable code. I'm
not even sure that the government could argue that the RFC's primary
purpose was to become source code. What applicable EAR restrictions
are left for this RFC?
Secondly, it would seem easier to make the first amendment argument
for this RFC than it would be for ordinary source code. The
heightened expressiveness would seem to make "purely functional"
arguments quite silly, while the functionality is yet another step
removed from executable code. I'd guess that the argument isn't
so easy that all judges would find the desired conclusion inescapable,
but it works for me. Of course my opinion is not the most objective;
I found the "purely functional" argument silly when applied to source
code anyway.
Isaac
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Is it possible to combine brute-force and ciphertext-only in an
Date: Thu, 08 Jul 1999 02:46:46 GMT
John Savard wrote:
> If one's plaintext were so well compressed as to be indistinguishable
> from random data, it would not be possible to be confident of any
> decipherment.
That would require that *any* random ciphertext decode to meaningful
plaintext, with relative likelihoods identical to one's a priori
estimates of message probabilities. No compression scheme in common
use comes anywhere close to that.
If the attacker knows (or can guess) the decompression algorithm,
then that can be used in a brute-force attack (it just adds one
more step in the test for plaintext).
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: sci.math
Subject: Re: Weakness of MLCG style encryption
Date: Thu, 08 Jul 1999 02:39:42 GMT
<snip>
I did what you did as well. Alot of newbies do that (think that they
have awesome cool algorithms).
The problem with LCG systems is that they are easily solvable if you
have any known keystream. A LCG with 32-bit words can naively be
attacked in about O(2^31) effort in no time.
Other systems like LFSRS and Lagged Fibonacii while being statistically
sound, they are linear, which means they reveal their internal state as
part of the output. For example you can tell a random LFSR seed, it's
output from truly random output in n bits of output (n = LFSR size).
The BM algorithm can find the polynomial in 2n outputs.
The goal is to use the RNG and not reveal the current internal state.
Algorithm M is a good example of this (Also in AC just after
LFSRs...). In my PRNG C++ mini-lib I have two algorithms based on it.
You can check out my stuff at
http://mypage.goplay.com/tomstdenis/prng.html
Basically you want to throw the output of a RNG out of sequence making
it rather difficult to solve for. The two generators I am talking
about (in my C++ code) is DDARNG and DARNG. They are based on
Algorithm M but with a twist... :)
Anyways, why not read the rest of the chapter and see the various LFSRs
(non-linear ones) and some of the additive generators. They inspired
me a bit :)
Tom
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Properties of Chain Addition?
Date: Thu, 08 Jul 1999 02:41:13 GMT
[EMAIL PROTECTED] wrote:
> Well ALL stream ciphers are PRNGs....
No more so than all block ciphers.
------------------------------
From: [EMAIL PROTECTED]
Subject: Is Stenography legal?
Date: Thu, 08 Jul 1999 03:31:59 GMT
Is stenography legal? I mean what if I took a 100 byte message and
spread out the plaintext among 1024 bytes of random giblygook. It
would be hard to decrypt (how so is challenging)....
Is this against EAR?
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: sci.math
Subject: Re: Properties of Chain Addition?
Date: Thu, 08 Jul 1999 00:46:57 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
> I'm not surprised; LFSRs aren't secure, and chain addition is just a
> simple special case of that. But key schedules are often not secure
> stream ciphers, and I'm using a MacLaren-Marsaglia construct to
> further scramble the output in my block cipher.
Well normally you want to have as little correlation as possible in
round keys. LFSRS and lag fib. make bad key schedulers.
> There isn't too much on my site about pseudo-random numbers; there's a
> bit on computer stream ciphers, but it mostly just notes some of the
> techniques used to make LFSR-based devices secure, like using a
> nonlinear function of several stages or several shift register
> outputs, clocking them irregularly, and so on.
Well ALL stream ciphers are PRNGs.... For software based I would
suggest algorithm M or delayed feedback (my ddarng). They are quick
and have the effect of randomizing the order of the output (making it
hard to solve using the known stream...).
Normally in hardware they rely on some simple boolean mixing however in
software you can do so much.
However even my ddarng (in my C++ lib) is about 10 to 25% slower then
RC4 in C++. It could be done faster in software (the clocking is the
slowest part) so I think RC4 and ddarng could be brought on a par (?).
Anyways enough ranting (as you can tell I want people to check out my
C++ code... it has some merit!)
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Analysis of DDARNG
Date: Thu, 08 Jul 1999 02:52:00 GMT
If you haven't seen yet DDARNG is my additive 8-bit RNG. It is
designed to be secure (hopefully). I used a delay to throw the outputs
out of sequence (to twart analysis). The delay is large enough to hold
5 times the state (of the output RNG).
Currently it is about 10 to 25% slower then RC4 but I bet in ASM it
could be on a par with (or kick but too) RC4 speed wise.
To show that I am keenly investigating this RNG, I performed a Order-1
Analysis of the output of RC4 and DDARNG. The test was 8MB of output
where I tested for (with each unique byte) a) count and b) distance.
After 1KB the outputs looked somewhat bias for both RNGS (1KB is not
alot to look at).
After 1MB the outputs looked somewhat normalized (+- 7%).
After 8MB the outputs were essentially normalized (+- 2%). Both RC4
and DDARNG perform the same on this test (well in the same margin).
The average count was around 32768 (+- 1024) and the distance about
256.0 (+- 2).
I can send the test output and test program if anyone is interested.
(In C). It does nicely for simple analysis of RNGS. I tried it
against .ZIP files (of about 8MB) and they failed (when compared to
RC4/DDARNG) so it seems there output is not as 'random' as could be...
Anyways my RNG in C++ are FREELY available from
http://mypage.goplay.com/tomstdenis/prng.html
Thanks for your time,
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: On the MD5
Date: Thu, 08 Jul 1999 02:45:15 GMT
In article <7m0vgm$n4t$[EMAIL PROTECTED]>,
"Joe" <[EMAIL PROTECTED]> wrote:
> I've read a paper on the cryptanalysis of MD5 which was written by Dr.
> Dobbertin in 1996.
> I got a copy of this paper from
> http://www.ph.tn.tudelft.nl/~visser/hashes.html.
>
> I'm really wondering whether we can say MD5 is still collision-free
or not.
I just got the paper. I must say that it doesn't appear to be an
effective collision. He has the message as X(i < 16) which is fixed?
Well of course some messages (>128 bits) will have collisions.
I think a real colision would be a class (group?) where a structured
input will find a collision. In this sense it's possible the class
could cover a wide range of inputs.
I don't quite understand the attack... Hmm..
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Crack of CIA'KRYPTOS N3
Date: Thu, 08 Jul 1999 02:56:10 GMT
collomb wrote:
> CRACK OF CIA ' KRYPTOS
> Today : The decyphering makes appear the image of a long snake
> See also at : http://calvaweb.calvacom.fr/collomb/
I couldn't find anything at all about Kryptos at that Web site.
In any event, all of Kryptos except the final 97 characters has
already been correctly deciphered, with results different from
the ones you seem to be claiming.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Weakness of MLCG style encryption
Date: 8 Jul 1999 01:53:11 GMT
In sci.crypt Greg Keogh <[EMAIL PROTECTED]> wrote:
> I only follow encryption as a hobby, so without any deep maths background I'
> m somewhat dumbfounded that these pseudo-random sequence generators that
> seem so fantastically random are of no use for XORing streams. Can anyone
> give me a potted summary of why this is so?
A single LCG by itself is very predictable. This makes sense when
you think of it as the equation of a line, just with a mod thrown in.
There's a lot of "structure" there.
It turns out that single LCGs are predictable from their output
alone, even without any of the parameters known. Klaus Pommering
posted a link to a program which demonstrates this using methods
developed by Joan Boyar.
They are even predictable if only part of the output is used - it
only means a few more messages need to be examined by the adversary.
I haven't looked up the references given in _Applied Cryptography_
on multiple LCGs yet, but since single generators are so easy
to predict even from _partial outputs_, I imagine it's something
like separating out which bits came from which generator and
then cracking them all that way. Please don't take my word for
it if you can help it, however.
> How strong are they in practical
> terms?
Systems which depend on LCGs can almost always be broken with
a number of messages polynomial in some reasonable measure of size.
The exact number depends on the system at hand. Still,
they generally aren't a good idea to use in any system which will
see general use.
> What techniques are used to break them? i
i
Every output of an LCG allows you to define an equation
value_i = ax_i + c mod n
where value_i is the output, which you know. x_i is the state
of the generator at that point. a and c and n may or may not
be known (depends on your implementation).
The more outputs you get, the more equations you have. These
equations can be considered as vectors, or as constraints
on a linear programming problem. You use these to build
a lattice with the property that knowing its shortest vector
gives you the seed value x_0 , or some value which producs
equivalent outputs to the LCG you have.
A "lattice" can be thought of as all the _integer_ linear
combinations of a particular set of vectors. So if I give
you a set of k vectors [v_1 ... v_k ], then the lattice
vectors are given by
L := n_1 * v_1 ... n_k * v_k, n_i \in Z
There's an algorithm known as LLL (after the inventors,
Lenstra, Lenstra, and Lova`s) which finds shortest vectors
in a lattice. It produces answers which are approximate
within a ball of exponential radius. That is, if it
finds a solution, you normally don't know that there
isn't a better solution "nearby".
For LCGs, it turns out that after "enough" equations,
where "enough" depends on how you set up the lattice,
you can show that the shortest vector is unique within
a radius greater than the approximation error of LLL.
In other words, LLL finds an answer, and you know by
the way the lattice is put together that it must be the
_right one_.
That's a not-very-detailed explanation. There are lots
of details in various papers, if you want them.
That's not the only way the problem has been thought of,
by the way. It's just the one I've looked at most.
Nor is it necessarily what _Applied Crypto_ referred to
when discussing MLCGs. It's just a fairly neat idea.
>Etc. Any general information
> or web references would be most welcome.
Terry Ritter posted a list of papers on predicting LCGs in a thread
a few months back; it should be on deja or your favorite sci.crypt
archive. His page has some interesting literature overviews and
archived discussions, too.
Knuth vol 2 has discussions of LCGs and some exercises which
may be of interest. Knuth also wrote one of the first papers
on predicting LCGs.
For an overview of how this lattice stuff works in practice,
try " 'Pseudo-random' number generation : the DSS Case"
at http://theory.lcs.mit.edu/~miccianc/papers/dss.ps
I don't think any of these much address multiple LCGs, but
they should prove illustrative of how unfortunate it is
as a crypto primitive.
-David
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: sci.math
Subject: Re: Properties of Chain Addition?
Date: Thu, 08 Jul 1999 03:48:12 GMT
In article <[EMAIL PROTECTED]>,
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > Well ALL stream ciphers are PRNGs....
>
> No more so than all block ciphers.
Only in counter mode. It is possible to have
x = EK(y) and y = EK(x)
(period = 2)
x = EK(y), y = EK(z) and z = EK(x)
(period = 3)
And so on. This requires for a SINGLE key to have des-weak keys, semi-
weak (and possibly quasi-weak)
However.... This limits the period to 2^64 (64-bit blocks) but the
entropy degrades as the outputs occur. In total for each output in
counter mode there is only log2(!2^64) instead of 2^70 possible
outputs. Basically the entropy degrades as the number of outputs
increases.
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: sci.math
Subject: Re: Properties of Chain Addition?
Date: Thu, 08 Jul 1999 03:48:41 GMT
In article <[EMAIL PROTECTED]>,
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > Well ALL stream ciphers are PRNGs....
>
> No more so than all block ciphers.
Only in counter mode. It is possible to have
x = EK(y) and y = EK(x)
(period = 2)
x = EK(y), y = EK(z) and z = EK(x)
(period = 3)
And so on. This requires for a SINGLE key to have des-weak keys, semi-
weak (and possibly quasi-weak)
However.... This limits the period to 2^64 (64-bit blocks) but the
entropy degrades as the outputs occur. In total for each output in
counter mode there is only log2(!2^64) instead of 2^70 possible
outputs. Basically the entropy degrades as the number of outputs
increases.
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: sci.math
Subject: Re: Properties of Chain Addition?
Date: Thu, 08 Jul 1999 03:48:23 GMT
In article <[EMAIL PROTECTED]>,
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > Well ALL stream ciphers are PRNGs....
>
> No more so than all block ciphers.
Only in counter mode. It is possible to have
x = EK(y) and y = EK(x)
(period = 2)
x = EK(y), y = EK(z) and z = EK(x)
(period = 3)
And so on. This requires for a SINGLE key to have des-weak keys, semi-
weak (and possibly quasi-weak)
However.... This limits the period to 2^64 (64-bit blocks) but the
entropy degrades as the outputs occur. In total for each output in
counter mode there is only log2(!2^64) instead of 2^70 possible
outputs. Basically the entropy degrades as the number of outputs
increases.
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
** 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
******************************
