Cryptography-Digest Digest #549, Volume #12 Sun, 27 Aug 00 16:13:01 EDT
Contents:
Thanks for your comments! ("Slava K.")
Re: PGP 6.5.8 test: That's NOT enough !!! (SCOTT19U.ZIP_GUY)
My (New) New algorithm ("Slava K.")
Re: R: Test on pseudorandom number generator. (Terry Ritter)
Re: 4x4 s-boxes (Mack)
Re: PGP ADK Bug: What we expect from N.A.I. (Mok-Kong Shen)
Re: Destruction of CDs (Mack)
Re: DeCSS ruling -- More (Mack)
Re: The DeCSS ruling and the big shots (Mack)
Re: My (New) New algorithm ([EMAIL PROTECTED])
Re: 4x4 s-boxes ([EMAIL PROTECTED])
Re: 4x4 s-boxes (Mok-Kong Shen)
CD Steganography ("Paul Pires")
Re: My (New) New algorithm (Mok-Kong Shen)
Re: PRNG Test Theory (Tim Tyler)
Re: On pseudo-random permutation (Tim Tyler)
Encryption tool (No User)
CAST-Cipher / CAST-Algorithm ("Patrick Harenberg")
Re: R: Test on pseudorandom number generator. ("Douglas A. Gwyn")
Re: On pseudo-random permutation (Terry Ritter)
Re: My (New) New algorithm ([EMAIL PROTECTED])
Re: CAST-Cipher / CAST-Algorithm ([EMAIL PROTECTED])
Re: RSA Security Conference for 2001 (Quisquater)
----------------------------------------------------------------------------
From: "Slava K." <[EMAIL PROTECTED]>
Subject: Thanks for your comments!
Date: Sun, 27 Aug 2000 18:38:03 +0200
Thanks to everyone who sent me their comments!
After taking a little more time to review the algorithm, I found the
pattern.
No further replies are necessary.
Thanks!
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: PGP 6.5.8 test: That's NOT enough !!!
Date: 27 Aug 2000 16:43:07 GMT
[EMAIL PROTECTED] (David Sternlight) wrote in
<HY1q5.1460$[EMAIL PROTECTED]>:
>The dancing, fast footwork, and apologetics of PGP die-hards here is
>truly sad. PGP has, after all the hubris of the past, acquired a fatal
>error. If you can't detect a forged key, it's all over.
>
>The only reliable solution is a "new" PGP which is deliberately
>incompatible with all previous versions but classical PGP. This is the
>ONLY way to restore trust on the part of the general (non-specialist)
>user.
>
Could you in this NEW PGP please don't have checks built into the
code that immeditaly tell if the KEY is bad. Nothing like should be part
of the encrypted text. Also make sure it use a fully bijective compressor.
I have no heart burn if they add a CRC outside of the encrypted blocks
but even there one should have the option to turn it off.
>Does NA have the guts to do this? Will they absorb the cost of a
>complete product (recall and) replacement. Will "pay" PGP users be
>willing to replace much of their PGP infrastructure? If not, I say game
>over.
>
>And if something like this had happened to Netscape/Microsoft S/MIME
>X.509, honest PGP die-hards here will concede they would be among the
>first to say what I am saying (about PGP) about S/MIME. When the
>ordinary user loses control over his cryptosystem and cannot detect
>forged keys, no amount of apologetics will sweep that under the rug.
>
>David
>
>P.S. For the ad hominem types here who think this is some anti-PGP
>crusade on my part, I too have now had to suspend use of a good part of
>my crypto infrastructure (PGP 6.x) and any number of PGP certificates
>from Thawte.
>
>David
>
>
>
>"Michel Bouissou" <[EMAIL PROTECTED]> wrote in message
>news:8o87bf$p7m$[EMAIL PROTECTED]...
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> I've just tested the "ADK-bug-fixed" PGP 6.5.8 against Ralf's B1
>> forged key that holds a faked ADK.
>>
>> Where previous versions would show this key as having an ADK, and use
>> the forged ADK, the "fixed" PGP 6.5.8 shows the forged key as being a
>> normal, valid key, without any ADK.
>>
>> PGP 6.5.8 will not use the forged ADK for encryption, and will just
>> behave as for a normal key.
>>
>> Well, okay, it "fixes" the bug.
>>
>> BUT IT DOESN'T WARN YOU IN ANY WAY THAT THE KEY YOU'RE USING HAS BEEN
>> FORGED. You just see a valid key and the forged ADK is ignored.
>>
>> So:
>>
>> - - You don't know the recipient's key has been victim of an attack;
>> - - You don't know that this key remains a potential danger for users
>> that still have previous versions of PGP.
>>
>> Actually with PGP 6.5.8, you have LESS CHANCES to ever detect that a
>> key was forged, than you had with previous vulnerable versions.
>>
>> That's no good folks.
>>
>> Waiting for 6.5.9 that will display a BIG WARNING that an ADK sits
>> where it shouldn't on a given key.
>>
>> - --
>> [EMAIL PROTECTED]
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>
>> Comment: Corrigez le bug PG ADK. Installez PGP 6.5.8 ou plus recent.
>>
>> iQA/AwUBOaeSnY7YarFcK+6PEQJUCACdFPt9KmCr+ImmCdpYt8i6XUlcmYUAnRRj
>> +OXfvsBkFugPmzNIlCaVO2N5
>> =iGL6
>> -----END PGP SIGNATURE-----
>>
>>
>>
>>
>
>
>
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
"The road to tyranny, we must never forget, begins with the destruction
of the truth."
------------------------------
From: "Slava K." <[EMAIL PROTECTED]>
Subject: My (New) New algorithm
Date: Sun, 27 Aug 2000 20:03:21 +0200
I have thought of another encryption algorithm. Please tell me what you
think
(Again, the algorithm is described in generalized programming terms):
1. A password of length n is entered (Passwords of 2 bytes of smaller make
the
algorithm inadequate, so using them should not be allowed).
2. Two random values are generated: r1 and r2.
3. Two copies of the password are saved in memory: p1 and p2.
4. p1 is advanced by r1 characters for each byte/bit it encrypts.
p2 is advanced by r2 characters for each byte/bit it encrypts.
5. A byte/bit is read from the input file. It is then encrypted like so:
c = p (XOR p1[r1] XOR p2[r2])
The obviouse problem with this algorithm is that the entire password is not
used. This means that another password could generate the same results.
However, if the password is long enough, the possibility of the program
selecting the same random numbers when a password with the exact same bytes
in the exact same locations is entered is negligible.
- NOTE - In order to enable the decryption of the file, r1 and r2 should be
saved along with the file.
<EMail me your comments to [EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: R: Test on pseudorandom number generator.
Date: Sun, 27 Aug 2000 17:13:53 GMT
On Sat, 26 Aug 2000 23:38:52 +0200, in <8o9c1s$o8r$[EMAIL PROTECTED]>,
in sci.crypt "Cristiano" <[EMAIL PROTECTED]> wrote:
>> Is it right that each call of the generators gives you a 5*8=40 bit
>integer?
>
>No. Each call of the generators gives 1 byte (unsigned char), so I need to
>collect 5 bytes before continue with the test.
The normal way to use a LCG is to convert the entire internal state
into a float, or even to use the state itself as an integer. Since
using the entire state is "normal," that is the way statistical tests
must be applied to get the "normal" results.
It is easy to hide a characteristic from a general statistical test by
chopping the sequence. We can see the chopping as an additional
operation *beyond* the normal generator itself. What we measure is
the combination of the generator plus the chopping; we thus measure
the effect of chopping on general statistical tests.
Similarly, Diehard expects to see 32-bit integers, not 40 (unless it
has been modified). If we expect tests to have some meaning, we must
give the test the data in a format it expects. Then each test can
tell us about the particular characteristics it detects.
No statistical tests of any sort can certify a crypto generator: Even
very predictable (thus weak) generators can have good statistical
results. Statistical tests can, however, expose particular defects
and then show when those defects are resolved. But to expose problems
we want to get as clear a picture as we can, and so would put nothing
between the generator and the test. By attempting to use statistical
tests to *certify* a more complex generator, we exceed what one can
expect from such tests.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: 4x4 s-boxes
Date: 27 Aug 2000 17:26:03 GMT
>In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Mack) wrote:
>> Has anyone analyzed the number of s-boxes
>> that could be used for Serpent?
>>
>> more specifically, serpent s-boxes don't appear
>> to have particularly good avalanche characteristics.
>>
>> The criteria seem logic but is it possible that
>> the serpent s-boxes might have been chosen
>> using stricter criteria?
>
>My "serpent_sboxes" on my website are good candidates for replacement
>sboxes if needed.
>
>Tom
>--
>http://www.geocities.com/tomstdenis/
>
I have looked at your program to produce s-boxes.
My question is of a more general nature. ie. how many
s-boxes actually meet th Serpent criteria and could
we add additional criteria to the given ones that would
improve the characteristics without producing a null
set of s-boxes.
for example. 4x4 s-boxes having the forward and
inverse both maximum non-linearity and meeting
sac are rare at best and non-existent at worst.
Does anyone know if such s-boxes exist?
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: PGP ADK Bug: What we expect from N.A.I.
Date: Sun, 27 Aug 2000 19:42:11 +0200
John Berger wrote:
>
[snip]
> it's encryption, it's probably the hardest thing to perfect next to
[snip]
The problem is that there are often terms being used that
suggest to the unwary as if there were perfection, in
practice, e.g. 'provable security' etc.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: Destruction of CDs
Date: 27 Aug 2000 17:32:34 GMT
>
>Thomas W. Barr wrote:
>>
>>How about CD-Rs, is there any equipment of software to roast the disc,
>>by flipping ALL the data are along the ttrack to its burnt state, not
>>its blank state? This would add yet another layer of security to the
>>data and you could then use some of the methods shown earlier in this
>>thread.
>>
>>I, for one, would use a CD-RW for my one-time-pads and then go through
>>an erase cycle, write 650mb of junk data (make sure you overwrite the
>>FAT), and erase that. This would remove ALL remnants of data that could
>>be left behind in the walls of the tracks.
>
>Unless your tracking is perfect (it isn't), I can recover most of
>the original data (laborously, one bit at a time) with an Atomic
>Force Microscope. My particular setup (which is for investigating
>the physics of DVD-RW, not for crypto) would fail to recover anything
>if you were to repeat your write random/erase cycle 8 or 10 times on
>the same drive that wrote the original data.
>
>It bwould be cheaper and more secure to use a CR-R and burn it
>(I mean in a fire pit, not a drive!) afterwards.
>
Since you are investigating RW disks maybe you can answer a question.
What temperature (in an oven) should a R or RW CD be heated to to
effectively destroy the data contained? ie.if you overwrite it once and
then bake at say 400F for 1 hour or something like that?
This has been a recurring topic and it would be nice to get a definitive
answer.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: DeCSS ruling -- More
Date: 27 Aug 2000 17:34:59 GMT
You could repost it periodically
with diferent topics and slight
changes in the code. Ie.
different variable names
and routine names.
Force em to root it out by
hand.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: The DeCSS ruling and the big shots
Date: 27 Aug 2000 17:39:30 GMT
>The arguments about the expressivness of software have already been
>made and won, in 2 different Federal Court districts. The cases
>regarded
>crypto. The argument about binary failed, example was what if the
>language was interperted.
>
But the current judge made an oppisite
ruling. This is likely to take a while to
resolve. The wheels of the supreme
court grind slowly.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: My (New) New algorithm
Date: Sun, 27 Aug 2000 17:26:09 GMT
In article <8oaf1l$kkd$[EMAIL PROTECTED]>,
"Slava K." <[EMAIL PROTECTED]> wrote:
> I have thought of another encryption algorithm. Please tell me what
you
> think
> (Again, the algorithm is described in generalized programming terms):
>
> 1. A password of length n is entered (Passwords of 2 bytes of smaller
make
> the
> algorithm inadequate, so using them should not be allowed).
> 2. Two random values are generated: r1 and r2.
> 3. Two copies of the password are saved in memory: p1 and p2.
> 4. p1 is advanced by r1 characters for each byte/bit it encrypts.
> p2 is advanced by r2 characters for each byte/bit it encrypts.
> 5. A byte/bit is read from the input file. It is then encrypted like
so:
> c = p (XOR p1[r1] XOR p2[r2])
>
> The obviouse problem with this algorithm is that the entire password
is not
> used. This means that another password could generate the same
results.
> However, if the password is long enough, the possibility of the
program
> selecting the same random numbers when a password with the exact same
bytes
> in the exact same locations is entered is negligible.
>
> - NOTE - In order to enable the decryption of the file, r1 and r2
should be
> saved along with the file.
>
This seems like an example of a Maurer stream cipher.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: 4x4 s-boxes
Date: Sun, 27 Aug 2000 17:47:03 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Mack) wrote:
> >In article <[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED] (Mack) wrote:
> >> Has anyone analyzed the number of s-boxes
> >> that could be used for Serpent?
> >>
> >> more specifically, serpent s-boxes don't appear
> >> to have particularly good avalanche characteristics.
> >>
> >> The criteria seem logic but is it possible that
> >> the serpent s-boxes might have been chosen
> >> using stricter criteria?
> >
> >My "serpent_sboxes" on my website are good candidates for replacement
> >sboxes if needed.
> >
> >Tom
> >--
> >http://www.geocities.com/tomstdenis/
> >
>
> I have looked at your program to produce s-boxes.
>
> My question is of a more general nature. ie. how many
> s-boxes actually meet th Serpent criteria and could
> we add additional criteria to the given ones that would
> improve the characteristics without producing a null
> set of s-boxes.
>
> for example. 4x4 s-boxes having the forward and
> inverse both maximum non-linearity and meeting
> sac are rare at best and non-existent at worst.
> Does anyone know if such s-boxes exist?
The sboxes I made have are completely non-linear i.e their "bent", they
fullfil SAC and BIC to the order-3. Other then a DPmax of four they
are perfect sboxes.
Finding them is hard, it took about 8 hours of random searching with
sboxgen. I am in the middle of making another set right now actually.
Overall about 1 in 100 million are ok. This is really rough since I
didn't keep track of the totals. This means about 1 in 2^27 are ok,
and since there are only 2^44 possible sboxes, about 2^17 should exist.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: 4x4 s-boxes
Date: Sun, 27 Aug 2000 20:44:35 +0200
Mack wrote:
>
> My question is of a more general nature. ie. how many
> s-boxes actually meet th Serpent criteria and could
> we add additional criteria to the given ones that would
> improve the characteristics without producing a null
> set of s-boxes.
I know too little in the issue. However, it seems to me to
be certain, in view of the existence of several (instead of
one) criteria, that there is generally no (one single) best
S-box, but there are a number of S-boxes that are deemed to
be satisfactory according to an evaluation that accords a
chosen set of weights to the criteria. It would be
interesting to know for a given block cipher what these
weights are and the computed values pertaining to the
individual criteria, I suppose. What I still believe to be
disadvantageous (despite some counter-arguments I know of)
is the commonly observed fact that there are too few number
of S-boxes being used and the same set of S-boxes (and in
the same ordering) is used for all rounds of the cipher.
M. K. Shen
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: CD Steganography
Date: Sun, 27 Aug 2000 11:32:15 -0700
Weird thought on how to stash information in an
undetectable way by using CD ROM error correction.
1, Encrypt the desired secret information to produce a random
looking output.
2, Mangle the data when writhing to a "normal" CD
to produce correctable errors where the XOR of the
Non-corrected read (Mangled value) and the correction
is the hidden message value. I guess you'd have
to have special hardware to read and write this stuff.
In effect this uses the extra data on a CD for error
correction as hidden message storage capacity. But, If
a requirement of stenography is keeping the method
secret, I just blew it, right? Oh well.
Paul
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: My (New) New algorithm
Date: Sun, 27 Aug 2000 20:48:10 +0200
[EMAIL PROTECTED] wrote:
>
> This seems like an example of a Maurer stream cipher.
What is a 'Maurer stream cipher'?
M. K. Shen
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: PRNG Test Theory
Reply-To: [EMAIL PROTECTED]
Date: Sun, 27 Aug 2000 18:55:49 GMT
[EMAIL PROTECTED] wrote:
: What tests should I put in it? The Fips 140-2 tests? (I think that's
: the #)? Any references? I would love to try it out.
Docs: http://www.cerberussystems.com/INFOSEC/stds/fip140-1.htm
FIPS140-1 and DRAFT FIPS140-2 code: http://quartus.net/files/Misc/
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Namaste.
------------------------------
Crossposted-To: comp.programming
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: On pseudo-random permutation
Reply-To: [EMAIL PROTECTED]
Date: Sun, 27 Aug 2000 19:06:29 GMT
In sci.crypt Tim Tyler <[EMAIL PROTECTED]> wrote:
: In sci.crypt Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
: : Mok-Kong Shen wrote:
: :> Tim Tyler wrote:
: :> > Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
: :> > : Tim Tyler schrieb:
: :> > :> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
: :> > :> I observe that you omit any form of detection of collisions between
: :> > :> the first components of B. Without such a check the result does
: :> > :> not form a truly unbiased random permutation [...]
: :> >
: :> > : That collision is to be resolved by the sorting process.
: :> > : One has to decide on a resolution rule, though.
: :> >
: :> > No resolution in the sort routine can possibly produce an unbiased
: :> > sequence.
: :> >
: :> > You can see this by a counting arument, after observing that n! doesn't
: :> > usually divide exactly into 2^(n * x) very well [x is the width of the
: :> > RNG output in bits].
: :>
: :> I am not yet convinced. You have to consider from a probabilistic
: :> point of view, i.e. consider a large number of occurences
: :> and the average effects [...]
: : If the collision resolution is chosen such that the first
: : element of the pair is always considered less than the
: : second, then indeed there is a bias. The effect is [usually small].
: : One can on the other hand use a random choice rule to resolve
: : collision, in which case no bias can occur.
: Yes. It was not correct for me to have written: "No resolution
: in the sort routine can possibly produce an unbiased sequence."
: As you say, use of a rule based on bits from the random stream
: would be likely to provide a possible way of removing the bias.
Thinking further about this, resolving collisions between more than one
object would probably need to be dealt with.
If you have three objects all with the same value in their sort field,
you need to make sure each of the six possible orderings is equally
likely.
If you just resolve 2-way collisions by tossing a coin, this effect
will not be produced.
While I'm sure this would be possible to implement, it seems unfortunate
that such code is required when going down this route while maintaining
the output as an unbiased permutation.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Namaste.
------------------------------
Date: Sun, 27 Aug 2000 13:21:51 -0500
From: No User <[EMAIL PROTECTED]>
Subject: Encryption tool
Put your own encrption algorithm in here:
http://homepages.go.com/~psychlcentral/cipher.html
(source is completely viewable)
------------------------------
From: "Patrick Harenberg" <[EMAIL PROTECTED]>
Subject: CAST-Cipher / CAST-Algorithm
Date: Sun, 27 Aug 2000 21:21:53 +0200
Hi,
can anyone of you send or tell me where to get a good description of the
(function of the) CAST-Cypher / CAST-Algorithm (256-bit version pereferred).
It would also be great if you coud send me or tell me where to get an
implementation (C++-source-code preferred) of said cipher / algorithm.
It would be great if you could help me.
Please send your answers to: [EMAIL PROTECTED]
CU
Patrick Harenberg
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: R: Test on pseudorandom number generator.
Date: Sun, 27 Aug 2000 15:39:06 -0400
Cristiano wrote:
> >So the expected number of matches is approximately 10^8*10^6*2^-40, which
> is about 91.
> OK. But if URAND pass all statistical test I think is better, for
> cryptographics applications, to have few duplicated keys!
The point is that URAND miserably fails the statistical test.
If you just want unique numbers, use a simple counter.
If you want numbers that cannot be distinguished from a
random sequence, then you have to accept occasional
duplication.
> >The expected variance is roughly the square root of that (rule of thumb for
> rare [Poisson] events): 9.5.
> I don't know this rule, but if 9.5 is the expected variance, then URAND is
> the better because the variance is the square of the standard deviation, so
> 3.66^2=13.3956 is the best!
Sorry, I meant variation (standard deviation), not variance.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Crossposted-To: comp.programming
Subject: Re: On pseudo-random permutation
Date: Sun, 27 Aug 2000 19:53:38 GMT
On Sun, 27 Aug 2000 19:06:29 GMT, in <[EMAIL PROTECTED]>, in
sci.crypt Tim Tyler <[EMAIL PROTECTED]> wrote:
>In sci.crypt Tim Tyler <[EMAIL PROTECTED]> wrote:
>: In sci.crypt Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>: : Mok-Kong Shen wrote:
>: :> Tim Tyler wrote:
>: :> > Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>: :> > : Tim Tyler schrieb:
>: :> > :> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>: :> > :> I observe that you omit any form of detection of collisions between
>: :> > :> the first components of B. Without such a check the result does
>: :> > :> not form a truly unbiased random permutation [...]
>: :> >
>: :> > : That collision is to be resolved by the sorting process.
>: :> > : One has to decide on a resolution rule, though.
>: :> >
>: :> > No resolution in the sort routine can possibly produce an unbiased
>: :> > sequence.
>: :> >
>: :> > You can see this by a counting arument, after observing that n! doesn't
>: :> > usually divide exactly into 2^(n * x) very well [x is the width of the
>: :> > RNG output in bits].
>: :>
>: :> I am not yet convinced. You have to consider from a probabilistic
>: :> point of view, i.e. consider a large number of occurences
>: :> and the average effects [...]
>
>: : If the collision resolution is chosen such that the first
>: : element of the pair is always considered less than the
>: : second, then indeed there is a bias. The effect is [usually small].
>: : One can on the other hand use a random choice rule to resolve
>: : collision, in which case no bias can occur.
>
>: Yes. It was not correct for me to have written: "No resolution
>: in the sort routine can possibly produce an unbiased sequence."
>
>: As you say, use of a rule based on bits from the random stream
>: would be likely to provide a possible way of removing the bias.
>
>Thinking further about this, resolving collisions between more than one
>object would probably need to be dealt with.
When we have a random function, it can produce exactly the same value
every time it is called, and *still* be a valid random sequence. We
would not expect that outcome, of course, and that is the problem:
Absent a guarantee that such will not occur, the software must handle
what might happen, or be incorrect and unreliable.
>If you have three objects all with the same value in their sort field,
>you need to make sure each of the six possible orderings is equally
>likely.
>
>If you just resolve 2-way collisions by tossing a coin, this effect
>will not be produced.
>
>While I'm sure this would be possible to implement, it seems unfortunate
>that such code is required when going down this route while maintaining
>the output as an unbiased permutation.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: My (New) New algorithm
Date: Sun, 27 Aug 2000 19:48:01 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>
> [EMAIL PROTECTED] wrote:
> >
>
> > This seems like an example of a Maurer stream cipher.
>
> What is a 'Maurer stream cipher'?
Look on the web.
http://www.counterpane.com/labs.html
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: CAST-Cipher / CAST-Algorithm
Date: Sun, 27 Aug 2000 19:54:52 GMT
In article <8obpr9$r75$[EMAIL PROTECTED]>,
"Patrick Harenberg" <[EMAIL PROTECTED]> wrote:
> Hi,
>
> can anyone of you send or tell me where to get a good description of
the
> (function of the) CAST-Cypher / CAST-Algorithm (256-bit version
pereferred).
> It would also be great if you coud send me or tell me where to get an
> implementation (C++-source-code preferred) of said cipher / algorithm.
>
> It would be great if you could help me.
>
> Please send your answers to: [EMAIL PROTECTED]
Nah, ask in a ng get a response in a ng.
BTW Cast-256 is just a 128-bit block cipher with a 256-bit key.
The Cast-128 is a 64-bit block cipher with a 128-bit key. CAST-128 is
a better cipher IIRC.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Quisquater <[EMAIL PROTECTED]>
Subject: Re: RSA Security Conference for 2001
Date: Sun, 27 Aug 2000 18:18:03 +0200
David A Molnar wrote:
>
> Paul Rubin <[EMAIL PROTECTED]> wrote:
> > Cryptographers track not withstanding, RSA Security isn't a good
> > conference for this type of paper. It's mostly a security industry
> > trade show. I recommend looking for a more research-oriented type of
> > conference, like Fast Software Encryption or one of the IACR
> > conferences. Unfortunately you just missed SAC 2000 (Selected Areas
> > in Cryptography) in Waterloo, Ontario, which I think is kind of near
> > you; and anyway, the submission deadline was May 1. You might try for
> > next year though.
>
> With that in mind, this link may be helpful :
> http://www.dice.ucl.ac.be/crypto/call_for_papers.html
>
> Important deadline to note is FSE '01 papers due December 29.
>
> Thanks to the UCL crypto group for collecting these calls for papers!
>
> -David
Did you see there the following link ?
http://www.rsasecurity.com/conference/rsa2001/cryptotrack.html
A good program committee, proceedings by Springer-Verlag, ...
what a change for the next RSA conference!
Jean-Jacques Quisquater,
PS: Anyway thanks for the comment: http://www.uclcrypto.org gives you access
to the main page.
------------------------------
** 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
******************************
