Cryptography-Digest Digest #982, Volume #13 Fri, 23 Mar 01 18:13:00 EST
Contents:
How to do it? ("Dobs")
Re: the classified seminal 1940 work of Alan Turing? (Frank Gerlach)
Re: ECC rather than PGP ? ("Ryan M. McConahy")
Re: Verisign and Microsoft - oops (Ichinin)
Re: AES - which block/key size to use? ("Henrick Hellstr�m")
Re: Input desired. (Frank Gerlach)
Re: the classified seminal 1940 work of Alan Turing? ("Henrick Hellstr�m")
Re: Pike stream cipher (Terry Ritter)
Re: on-card key generation for smart card (Erwann ABALEA)
Re: Open Source Implementations of PGP ("Henrick Hellstr�m")
Re: Crack it! (Jeffrey Williams)
Re: on-card key generation for smart card (Anne & Lynn Wheeler)
Re: the classified seminal 1940 work of Alan Turing? (Mok-Kong Shen)
Re: Crack it! (Frank Gerlach)
Re: How to do it? (Frank Gerlach)
Re: Crack it! (amateur)
Re: Pike stream cipher (Mok-Kong Shen)
Same sender : "amateur" and "br" (amateur)
----------------------------------------------------------------------------
From: "Dobs" <[EMAIL PROTECTED]>
Subject: How to do it?
Date: Fri, 23 Mar 2001 22:17:07 +0100
Can somebody tell me how should I do the following thing:
I need 2 large primes ( 512 bits each) p and q for my BBS generator. However
AFAIK in C language integer can have only 32 bits. So how can I take for q
and q such a large number in my implementation. How to do it???Thanks
Regards, Michal
------------------------------
From: Frank Gerlach <[EMAIL PROTECTED]>
Subject: Re: the classified seminal 1940 work of Alan Turing?
Date: Fri, 23 Mar 2001 23:27:49 +0100
John Savard wrote:
> On Fri, 23 Mar 2001 14:26:11 +0100, Frank Gerlach
> <[EMAIL PROTECTED]> wrote, in part:
>
> >Is it that Schneier is referring to ? Seems to be more an analysis of
> >Enigma and not a general theory...
>
> I would suspect that what is referred to is something that relates to
> the work of Claude Shannon as well; work that unifies the concepts
> behind cryptography with the fundamentals of mathematics.
There is no such thing as "fundamentals of mathematics". Check
Goedel,Turing and Chaitin.
In a nutshell, they state that most mathematical theories (a theory is a
set of axioms) *cannot* be reconciled. If this is true, then there cannot
be a "fundament of mathematics".
Although rather trivial, its philosophical implications are most
important. For example, just because *you* cannot come up with an
efficient way of breaking DES (2^56 is not efficient), this does not mean
there is no way to do it. Just based on the theories available to *you*
(but maybe not me) there is no efficient attack. That is essentially the
reason the NSA is the biggest employer of mathematicians - you need to
maximize the "frequency of theory generation" (of course, a little focus
is critical, too).
Regarding Shannon & Turing you might be right. Any references on the net
? (I have to admit that I haven't visited a university library for quite
some time :-( )
BTW, you might call Shannon fundamental to information theory, but
unfortunately his Bandwith/SNR formula uses the frequency domain. As you
know, there are plenty of other domains, such as the ones used by Wavelet
Transformation. Who knows what kind of interesting relationships can be
discovered in those domains ? Or in a domain, which you come up with ?
Forget that cartesian crap of "fundamentals", it just blocks the
incredible power of *human phantasy*.
>
> John Savard
> http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "Ryan M. McConahy" <[EMAIL PROTECTED]>
Subject: Re: ECC rather than PGP ?
Date: Fri, 23 Mar 2001 16:35:20 -0500
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
I've heard of it, but I am sooo much happier with PGP. If I didn't
like PGP, I'd switch to GPG. If I felt PGP was insecure, I'd examine
the 2.6.2 source, compile it, and make my own shell. Tell us why we
would want to switch to this.
Ryan M. McConahy
Anonymous wrote in message
<[EMAIL PROTECTED]>...
>I have just downloaded Greg Ofiesh's ECC public key encryption
>program (Hidden Point Conceal 3.1).
>I think that it is a viable alternative to PGP at this point, and
>the executable is only 120kb in size (BIG GRIN).
>Any Caveats ??.
>
=====BEGIN PGP SIGNATURE=====
Version: 6.5.8ckt http://www.ipgpp.com/
Comment: KeyID: 0xA167F326A5BE3536
Comment: Fingerprint: 838C 815E 5147 2168 5A76 16F1 A167 F326 A5BE 3536
iQA/AwUBOrvBlqFn8yalvjU2EQIoNQCg2a/wybuwFEWDKnfwGAd+f9D1eHUAoIyo
gIH9p2mJe8HyaIE2U1X/YHOJ
=SmcQ
=====END PGP SIGNATURE=====
------------------------------
From: Ichinin <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Verisign and Microsoft - oops
Date: Sat, 17 Mar 2001 04:08:47 +0100
Mathew Hendry wrote:
<SNIP>
Obviously it is too much of an effort to call MS and verify that
the person in question actually IS an employee before issuing the
certificate.
/Ichinin
------------------------------
From: "Henrick Hellstr�m" <[EMAIL PROTECTED]>
Subject: Re: AES - which block/key size to use?
Date: Fri, 23 Mar 2001 22:51:28 +0100
"David Wagner" <[EMAIL PROTECTED]> skrev i meddelandet
news:99gckq$jni$[EMAIL PROTECTED]...
> Henrick Hellstr�m wrote:
> >"DJohn37050" <[EMAIL PROTECTED]> wrote
> >> The point is one should not assume that ENCRYPTION provides ANY MESSAGE
> >> AUTHENTICATION.
> >
> >No, the point is that when you flip a bit of a CFB cipher text anywhere
but
> >in the last block, the plain text output of the next block will be
obscured.
>
> No, Don Johnson is absolutely correct. CFB should not be relied
> upon to provide protection against modifications or tampering, no
> matter which block you're talking about.
I did not question the truth of what Don Johnson wrote, but only the
relevance.
I didn't think Don Johnsons statement was an entirely relevant inference
from Scott Fluhrer's description of the rather particular bit flipping
property of the last block. Just because something is true does not make it
the crux of the matter in every possible context. I'm sure we all agree on
the facts, though.
--
Henrick Hellstr�m [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
------------------------------
From: Frank Gerlach <[EMAIL PROTECTED]>
Subject: Re: Input desired.
Date: Fri, 23 Mar 2001 23:49:20 +0100
YACC - Yet Another Crappy Crypto
------------------------------
From: "Henrick Hellstr�m" <[EMAIL PROTECTED]>
Subject: Re: the classified seminal 1940 work of Alan Turing?
Date: Fri, 23 Mar 2001 23:00:18 +0100
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> skrev i meddelandet
news:[EMAIL PROTECTED]...
> >The first thing that came into my mind was not really something
> >"twisted", but a simple monoalphabetic substitution cipher: 26! <
> >26**19, so a message longer than 18 characters is longer than the key,
> >and if it is shorter than 25 characters, then by the pigeon hole
> >principle it can't be brute forced even if the plain text is known.
> >
>
> But this is not really the case you should not think of the
> character as being 8 bits.
[snip]
I didn't. You did just now.
However, my numbers disregarded the fact that you can use frequency analysis
to easily crack a monoalphabetic substitution cipher. It was just an
illustration of the mathematical possibility of a cipher system with the
said property.
--
Henrick Hellstr�m [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Pike stream cipher
Date: Fri, 23 Mar 2001 22:03:00 GMT
On Fri, 23 Mar 2001 20:16:14 +0100, in
<[EMAIL PROTECTED]>, in sci.crypt Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>Terry Ritter wrote:
>>
>> Mok-Kong Shen<[EMAIL PROTECTED]> wrote:
>>
>> >Terry Ritter wrote:
>> >>
>> >[snip]
>> >> Based on this evidence -- as opposed to hearsay, wishes, hopes or
>> >> claims -- we see the MacLaren-Marsaglia mixing process not producing
>> >> significant (e.g., exponential) additional cryptographic strength.
>> >
>> >I think that Knuth mentioned that it is difficult to
>> >investigate this shuffling theoretically. On the other
>> >hand, I guess that the effect depends on the materials
>> >that are being shuffled and that its contribution
>> >as a component to a whole system may under circumstances
>> >not merely be 'additive'/'multiplicative'.
>>
>> Maybe, maybe not. The referenced literature gives us more evidence
>> than we have for most cryptographic constructions, and it is not
>> encouraging.
>>
>> The whole point to using the MacLaren-Marsaglia construction in this
>> case is to add strength. If we must have a strong sequence generator
>> before that will work, one might think there really is no point in
>> using that mixing. A requirement for a strong sequence generator
>> would not help anyway, because we cannot guarantee such strength.
>>
>> If we have to know the strength of the generator before we can
>> understand the contribution of the mixing, we are already out of our
>> depth. We generally don't know these values even to orders of
>> magnitude. The only time we need the mixing is when the generator
>> isn't strong, and the evidence we have is precisely about what can
>> happen in that case.
>
>What the algorithm normally does is actually a permutation
>of the values from one PRNG using the output from another,
No, it does not. Actually, the algorithm delays the output from one
PRNG by various amounts as controlled by the other PRNG. This is not
a permutation.
>though differing from what one would do with the algorithm
>of Dustenfeld. If the values being permuted are real values
>in [0,1) (like those one could get from a congruential
>generator), it confounds the output ordering, thus poses
>some difficulty of inprediction.
Such was the claim. And that claim was refuted by practical and real
(not simply academic) breaks of no less than two ciphers using that
"confounding."
>But one can also permute
>(shuffle) bits that are obtained from these real values in
>some appropriate way (e.g. through getting the parity bit).
One can do a lot of things. Even weak constructions can be hidden
inside strong ciphers, but if they don't add strength somehow, it's
kind of a waste. From the point of view that we can use anything, no
matter how weak, no construction is useless, and the only thing we can
discuss is complete ciphers, for which we generally have no measure of
strength. That is no way to analyze cipher strength.
Here is a relatively unique opportunity to judge the strength of a
particular construction based on real cryptanalysis.
The issue is what MacLaren-Marsaglia brings to the party. The answer
we get from the literature seems to be: "far less than one might
hope." As we see, however, hope springs eternal.
>In that case the prediction gets comparatively more
>difficult. (Compare also your proposed scheme DT.)
The closer scheme is Dynamic Substitution. Inspection of the problems
in MacLaren-Marsaglia eventually produced Dynamic Substitution.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: Erwann ABALEA <[EMAIL PROTECTED]>
Subject: Re: on-card key generation for smart card
Date: Fri, 23 Mar 2001 23:07:30 +0100
On 23 Mar 2001, Paul Rubin wrote:
> Chenghuai Lu <[EMAIL PROTECTED]> writes:
> > Could anybody tell me the average time of on-card 1024-bit RSA key
> > generation for the best smartcard application.
> >
> > Thanks.
>
> The cards I've been using can do it in under a minute, and I doubt
> those are the fastest. 8 minutes is ridiculous.
I use smartcards from Gemplus (GPK8000) that can generate a 1024bits RSA
keypair in less than 30 seconds most of the time...
8 minutes is really a nightmare... I bet they're not using any crypto
accelerator at all ;-)
--
Erwann ABALEA
[EMAIL PROTECTED]
- RSA PGP Key ID: 0x2D0EABD5 -
------------------------------
From: "Henrick Hellstr�m" <[EMAIL PROTECTED]>
Subject: Re: Open Source Implementations of PGP
Date: Fri, 23 Mar 2001 23:12:10 +0100
"Tony L. Svanstrom" <[EMAIL PROTECTED]> skrev i meddelandet
news:[EMAIL PROTECTED]...
> Peter Harrison <[EMAIL PROTECTED]> wrote:
>
> > I am looking for people interested in writing or adapting open source
> > implementations of PGP in
> >
> > - Delphi
> > - C
> > - Java
> >
> > to be part of an Open Source business document exchange system.
> >
> > My Open Source project pages are at
> > http://idtrans.sourceforge.net
>
> Took a look at your pages and... well... it's basically the same as I've
> been working on, and... well... messing with PGP will just slow you
> down. Do like me and create a good from scratch-solution (BTW, I'll
> release this as open source too, when I have the time).
I agree. Messing with other peoples code might be educational and perhaps an
evil bad if you want your software to be compatible with others. Otherwise
it is best to start from scratch.
--
Henrick Hellstr�m [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
------------------------------
From: Jeffrey Williams <[EMAIL PROTECTED]>
Subject: Re: Crack it!
Date: Fri, 23 Mar 2001 16:13:53 -0600
You might want to consider reposting your challenge with a description of
the algorithm. Better still (**arguably**) would be the well-commented
source code of the program you used to encrypt (NB: if the source code is
long, put it on a web page and give us a link to it). You've talked about
several algorithms, or several permutations of an algorithm, so it's
uncertain what you used to encrypt.
As others have noted, if it's the type of thing that would take lots of
time (to break it the ***first*** time), you may not get any responses -
most people have other priorities. Keep in mind that an algorithm may
take hundreds (or more) of man-hours to break the first time. Thereafter,
regardless of the key, breaking encryption could conceivably take mere
seconds.
amateur wrote:
> Thank you for your message. I received it in my valid email.
> I read it.
> Your post is talking about encrypting goups of bits not a single bit.
> So it's not the same.
> I encrypted every bit without scrambling group of bits.
> Even if the grammatical structure of the plain-text is not changed,
> using for every character a specific encryption hide this structure.
> I'm using substitution only without permutation.
> I replace every bit by random values owning one property.(i.e. odd and
> even etc...).
> I mask with a simple key when sending my message.
>
>
>
> Mok-Kong Shen wrote:
> >
> > amateur wrote:
> > >
> > > I used what I had proposed in posts "Idea" and "fast and easy".
> > > I hope you decrypt it, if it's easy and useless.
> > [snip]
> >
> > In a recent thread posted by someone else, the following
> > questions were raised:
> >
> > Is this a workable cipher system?
> > How could you ever break it?
> >
> > To that I replied with the following comment, which I guess
> > could also apply to the current thread with respect to your
> > challenge above:
> >
> > I my humble view answering questions like your last one is
> > in general difficult. For breaking a given cipher (that
> > is susceptible to be broken by the current state of
> > knowledge) may often require much thoughts/intuitions and
> > experimentations/work/time. Thus it is always easy to put
> > up a challenge but hard to take it up. If nobody answers
> > that question of yours, it doesn't follow at all that your
> > cipher is strong. An analogy: In mathematics it is easy to
> > put up problems that are hard to get worked out. Some may
> > need much work to be solved, others may be not solvable
> > but the non-solvability is rather difficult to prove (e.g.
> > the trisection of an angle). But this is all opionions of
> > a humble non-expert like me. I don't exclude that some
> > experts would at once give a very easy break of your scheme
> > or prove the opposite.
> >
> > BTW, please avoid repeatedly post virtually the same stuff.
> > It is good etiquette not to waste bandwidth of the group.
> >
> > M. K. Shen
------------------------------
Subject: Re: on-card key generation for smart card
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Fri, 23 Mar 2001 22:20:42 GMT
Paul Rubin <[EMAIL PROTECTED]> writes:
> Chenghuai Lu <[EMAIL PROTECTED]> writes:
> > Could anybody tell me the average time of on-card 1024-bit RSA key
> > generation for the best smartcard application.
> >
> > Thanks.
>
> The cards I've been using can do it in under a minute, and I doubt
> those are the fastest. 8 minutes is ridiculous.
crypto accelerator are suppose to speed things up by a factor of 10
... so that may be about right. there is also a big difference between
8bit chips and 16bit chips ... and what kind of random number
generator is available in the card (I've heard of tests done on a lot
of the 8bit cards where they are power-cycled several thousand times
and the operation performed again and the results recorded ... and
possibly 30% of the results on the same).
--
Anne & Lynn Wheeler | [EMAIL PROTECTED] - http://www.garlic.com/~lynn/
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: the classified seminal 1940 work of Alan Turing?
Date: Fri, 23 Mar 2001 23:17:20 +0100
Frank Gerlach wrote:
>
> There is no such thing as "fundamentals of mathematics". Check
> Goedel,Turing and Chaitin.
> In a nutshell, they state that most mathematical theories (a theory is a
> set of axioms) *cannot* be reconciled. If this is true, then there cannot
> be a "fundament of mathematics".
> Although rather trivial, its philosophical implications are most
> important. For example, just because *you* cannot come up with an
> efficient way of breaking DES (2^56 is not efficient), this does not mean
> there is no way to do it. Just based on the theories available to *you*
> (but maybe not me) there is no efficient attack. That is essentially the
> reason the NSA is the biggest employer of mathematicians - you need to
> maximize the "frequency of theory generation" (of course, a little focus
> is critical, too).
My knowledge of mathematical logic is too meager to argue.
But isn't it that Goedel's imcompleteness theorem puts up
only a rather (in meaning) 'restricted' statement
concerning predicate calculi of higher order and as such
probably could not be applied (generalized) to deals with
matters like 'efficiency'? (I mean it deals only with
'possibility'/'impossibility'.) Are you claiming that
people e.g. in NSA are employing a different kind of
mathematics than is employed (or understood/known) by the
public? Thanks.
M. K. Shen
------------------------------
From: Frank Gerlach <[EMAIL PROTECTED]>
Subject: Re: Crack it!
Date: Fri, 23 Mar 2001 23:52:33 +0100
PLEASE STOP JAMMING THIS NEWSGROUP. THANK YOU.
IF THIS IS A STEGANOGRAM, PLEASE POST SOMEWHERE ELSE.
amateur wrote:
> I used what I had proposed in posts "Idea" and "fast and easy".
> I hope you decrypt it, if it's easy and useless.
>
> First communication I sent via network this encrypted message :
>
> 1300443387025
> 1131639164190
> 1466401443136
> 1159155876122
> 1351377516458
> 1106628398377
> 1027751582638
> 1593542128406
>
> and you intercept it
> _______________________
>
> Second communication I sent via network this encrypted message :
>
> 1516273460338
> 1142553801552
> 1269821319190
> 1422764977616
> 0899310400137
> 1527607877779
> 1412907062933
> 1207246427960
>
> _________________________
>
> I used very pseudo-random short key : 12 digits
> I used the same key in the two communications.
> I used two categories other than odds and even.
> I'm just an amateur.
>
> Good luck.
------------------------------
From: Frank Gerlach <[EMAIL PROTECTED]>
Subject: Re: How to do it?
Date: Fri, 23 Mar 2001 23:55:09 +0100
Dobs wrote:
> Can somebody tell me how should I do the following thing:
> I need 2 large primes ( 512 bits each) p and q for my BBS generator. However
> AFAIK in C language integer can have only 32 bits. So how can I take for q
> and q such a large number in my implementation. How to do it???Thanks
> Regards, Michal
Implementing your own big integer math library ?
By doing that you will learn a lot. The lesser way is to check google.com for
"big integer" libs.
------------------------------
From: amateur <[EMAIL PROTECTED]>
Subject: Re: Crack it!
Date: Fri, 23 Mar 2001 17:23:32 -0400
I did it before. You may read post "idea" and "fast and easy" signed by
"br". I changed the name because "br" is the name of brother.
"br" and "amateur" are the same person.
Jeffrey Williams wrote:
>
> You might want to consider reposting your challenge with a description of
> the algorithm. Better still (**arguably**) would be the well-commented
> source code of the program you used to encrypt (NB: if the source code is
> long, put it on a web page and give us a link to it). You've talked about
> several algorithms, or several permutations of an algorithm, so it's
> uncertain what you used to encrypt.
>
> As others have noted, if it's the type of thing that would take lots of
> time (to break it the ***first*** time), you may not get any responses -
> most people have other priorities. Keep in mind that an algorithm may
> take hundreds (or more) of man-hours to break the first time. Thereafter,
> regardless of the key, breaking encryption could conceivably take mere
> seconds.
>
> amateur wrote:
>
> > Thank you for your message. I received it in my valid email.
> > I read it.
> > Your post is talking about encrypting goups of bits not a single bit.
> > So it's not the same.
> > I encrypted every bit without scrambling group of bits.
> > Even if the grammatical structure of the plain-text is not changed,
> > using for every character a specific encryption hide this structure.
> > I'm using substitution only without permutation.
> > I replace every bit by random values owning one property.(i.e. odd and
> > even etc...).
> > I mask with a simple key when sending my message.
> >
> >
> >
> > Mok-Kong Shen wrote:
> > >
> > > amateur wrote:
> > > >
> > > > I used what I had proposed in posts "Idea" and "fast and easy".
> > > > I hope you decrypt it, if it's easy and useless.
> > > [snip]
> > >
> > > In a recent thread posted by someone else, the following
> > > questions were raised:
> > >
> > > Is this a workable cipher system?
> > > How could you ever break it?
> > >
> > > To that I replied with the following comment, which I guess
> > > could also apply to the current thread with respect to your
> > > challenge above:
> > >
> > > I my humble view answering questions like your last one is
> > > in general difficult. For breaking a given cipher (that
> > > is susceptible to be broken by the current state of
> > > knowledge) may often require much thoughts/intuitions and
> > > experimentations/work/time. Thus it is always easy to put
> > > up a challenge but hard to take it up. If nobody answers
> > > that question of yours, it doesn't follow at all that your
> > > cipher is strong. An analogy: In mathematics it is easy to
> > > put up problems that are hard to get worked out. Some may
> > > need much work to be solved, others may be not solvable
> > > but the non-solvability is rather difficult to prove (e.g.
> > > the trisection of an angle). But this is all opionions of
> > > a humble non-expert like me. I don't exclude that some
> > > experts would at once give a very easy break of your scheme
> > > or prove the opposite.
> > >
> > > BTW, please avoid repeatedly post virtually the same stuff.
> > > It is good etiquette not to waste bandwidth of the group.
> > >
> > > M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Pike stream cipher
Date: Fri, 23 Mar 2001 23:28:31 +0100
Terry Ritter wrote:
>
> Mok-Kong Shen<[EMAIL PROTECTED]> wrote:
>
> >Terry Ritter wrote:
> >>
> >> Mok-Kong Shen<[EMAIL PROTECTED]> wrote:
> >>
> >> >Terry Ritter wrote:
> >> >>
> >> >[snip]
> >> >> Based on this evidence -- as opposed to hearsay, wishes, hopes or
> >> >> claims -- we see the MacLaren-Marsaglia mixing process not producing
> >> >> significant (e.g., exponential) additional cryptographic strength.
> >> >
> >> >I think that Knuth mentioned that it is difficult to
> >> >investigate this shuffling theoretically. On the other
> >> >hand, I guess that the effect depends on the materials
> >> >that are being shuffled and that its contribution
> >> >as a component to a whole system may under circumstances
> >> >not merely be 'additive'/'multiplicative'.
> >>
> >> Maybe, maybe not. The referenced literature gives us more evidence
> >> than we have for most cryptographic constructions, and it is not
> >> encouraging.
> >>
> >> The whole point to using the MacLaren-Marsaglia construction in this
> >> case is to add strength. If we must have a strong sequence generator
> >> before that will work, one might think there really is no point in
> >> using that mixing. A requirement for a strong sequence generator
> >> would not help anyway, because we cannot guarantee such strength.
> >>
> >> If we have to know the strength of the generator before we can
> >> understand the contribution of the mixing, we are already out of our
> >> depth. We generally don't know these values even to orders of
> >> magnitude. The only time we need the mixing is when the generator
> >> isn't strong, and the evidence we have is precisely about what can
> >> happen in that case.
> >
> >What the algorithm normally does is actually a permutation
> >of the values from one PRNG using the output from another,
>
> No, it does not. Actually, the algorithm delays the output from one
> PRNG by various amounts as controlled by the other PRNG. This is not
> a permutation.
Any change of order is a permutation, isn't it? Even no
change is a permutation (the identity). If you want to be
exact, you can the the end flush the buffer. This way
one sees that a total of n elements get processed into
a different order.
>
> >though differing from what one would do with the algorithm
> >of Dustenfeld. If the values being permuted are real values
> >in [0,1) (like those one could get from a congruential
> >generator), it confounds the output ordering, thus poses
> >some difficulty of inprediction.
>
> Such was the claim. And that claim was refuted by practical and real
> (not simply academic) breaks of no less than two ciphers using that
> "confounding."
>
> >But one can also permute
> >(shuffle) bits that are obtained from these real values in
> >some appropriate way (e.g. through getting the parity bit).
>
> One can do a lot of things. Even weak constructions can be hidden
> inside strong ciphers, but if they don't add strength somehow, it's
> kind of a waste. From the point of view that we can use anything, no
> matter how weak, no construction is useless, and the only thing we can
> discuss is complete ciphers, for which we generally have no measure of
> strength. That is no way to analyze cipher strength.
>
> Here is a relatively unique opportunity to judge the strength of a
> particular construction based on real cryptanalysis.
>
> The issue is what MacLaren-Marsaglia brings to the party. The answer
> we get from the literature seems to be: "far less than one might
> hope." As we see, however, hope springs eternal.
>
> >In that case the prediction gets comparatively more
> >difficult. (Compare also your proposed scheme DT.)
>
> The closer scheme is Dynamic Substitution. Inspection of the problems
> in MacLaren-Marsaglia eventually produced Dynamic Substitution.
In my view, DT faces also the problem of being not
'exactly' treatable in theory (in the same sense that
Knuth mentioned about shuffling). There is no rigorous
proof that it is strong, though it is plausible to be so,
as far as I could understand in previous discussions
about DT.
M. K. Shen
M. K. Shen
------------------------------
From: amateur <[EMAIL PROTECTED]>
Subject: Same sender : "amateur" and "br"
Date: Fri, 23 Mar 2001 17:27:36 -0400
I'm very sorry if If I changed my name.
"br" is the name of my brother.
So "br" and "amateur" are one sender.
My initials are B.M.
Thank you.
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
